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
