Do the contributing rules apply just to non-committers?

[Rainer Müller]

On 2017-10-01 21:17, Leonardo Brondani Schenkel wrote:
> On 2017-10-01 19:53, Ryan Schmidt wrote:
>> Sorry about that.
>>
>> I did receive notification that you submitted a PR. Thanks for doing
>> that! I am not comfortable working with Git and pull requests, so I
>> usually leave them to someone else to do.
> 
> In that case, I fell it would make a world of difference for the
> submitter if you just wrote a quick reply with a one-liner stating this
> (you can just reply to the e-mail you received, you don't even need to
> use the GitHub website) compared to silence, so the submitter does not
> spend days waiting for a review that will not happen and can find
> another reviewer — or ask the list. Wouldn't you agree? Or do you really
> feel that this is asking too much? (Honest question.)

I agree. When I had the spare time to go through the list of pull
requests, I usually skip pull request assigned to the port maintainer
awaiting their comment...

When dealing with pull requests for other maintainers, I usually want to
add the fact that the maintainer timeout rule was invoked to the commit
message. Enabling the Squash & Merge option would allow to do so
directly on the web interface and reduce the overhead for merging pull
requests. Are there still strong objections against enabling that?

> Apologies for rehashing the point, but I really feel the need to
> reinforce it. In this specific case, I was annoyed not because of the
> change itself (which you rightfully stated that is within the spirit of
> openmaintainer) but because you used your commit rights to deliberately
> "jump the queue". I was more annoyed now than in the first time because
> on that time you probably didn't know (even though according to the
> guidelines you should have checked), but this time you *knew* I had a PR
> open with the exact same change, but you went there and committed to it
> anyway (which you also knew that would result in a conflict) instead of
> replying to me here, reviewing the PR, or at sent me a FYI one-liner
> that you were going to change/had changed it — any of which I would have
> found acceptable. And you did that in a few minutes and moved on while I
> have to wait many days for my changes to go through (and they still
> didn't), plus resolve conflicts. I hope that you can see how that can be
> frustrating, if you put yourself into my shoes, and sympathize with me
> venting.

My problem in the past was that I missed pull requests entirely. There
are just way too many GitHub notifications. Now I am filtering the
notifications by mail with To or Cc containing my mail address and that
works much better.

Assigning pull requests to the port maintainer instead of leaving a
mention in the comments would also help me. However, I am glad we got
the automatic notifications at all. We should rather look into getting
the same functionality for Trac tickets...

Also, I sometimes review patches in pull requests or tickets, but I do
not always come back to them after the author made changes. That is not
because I do not value the contribution, but sometimes that change just
falls off of my radar as I only picked it up by chance when looking
through open tickets. Sometimes I am also just not entirely comfortable
to push large changes or new ports without comments from others.

> I don't think I'm completely familiarized with the decision making
> process that led the whole migration from SVN to Git+GitHub, but I found
> it curious (honestly, not being sarcastic to you) that the project as a
> whole agreed and published a new process and new tooling but you, being
> of the project managers and one of the big contributors, are not
> comfortable with it. It's actually quite a surprise to me.

Well, lots of peer pressure from outsiders who stated they would
immediately start contributing if MacPorts was on GitHub... ;-)

> Regarding merging the PRs before making changes: no, you don't need to
> do that. However, you *could* quickly search the PRs in GitHub by the
> port name and see if there are any opened ones, and a simple visual
> inspection of the diff will suffice in virtually all cases to tell you
> if whatever you're going to do is going to conflict. I feel that this is
> important to be done out of politeness to avoid "destroying" other
> contributor's work, especially if they're waiting a long time to get
> their work merged. You may miss PRs that don't have the port name, but
> then they're not following the guidelines and it's not your fault if you
> missed them.
> 
> (There will be also other kinds of situations in which you may need to
> bypass the queue — security issues, urgent problems affecting many
> users, etc. That's complete different, of course.)

Hm, I have to admit that I am also not always doing this. When I am
about to update ports, I just go through my list and push the changes...

Ideally, changes that do not need discussion should be merged quickly.
If a discussion or revisions are necessary, that would be the reason why
other changes can be merged/pushed first.

Rainer