Do the contributing rules apply just to non-committers?

Leonardo Brondani Schenkel leonardo at schenkel.net
Sun Oct 1 19:17:35 UTC 2017


Hi Ryan,

First of all I would like to thank you for the graceful way you replied 
to my message, even though I was deliberately blunt (maybe more than I 
realize, a risk I run due to English not being my native language).

In the interest of having a conversation to smooth out some rough edges 
and improve the workflow for everybody involved, "big" and "small" 
contributors alike, I'm going to reply to some of your points inline.

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.)

> The port is openmaintainer, which means other developers are to feel free to make minor changes to the port, so I did so.

Right. That's a deliberate decision that I took for most (all?) the 
ports I maintain. I don't want to create any additional friction for 
other contributors who might want to update the port (or do other 
*minor* changes) before I have the chance to do so.

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.

> So I'm not sure what the solution is. Sounds like I either have to make myself comfortable with git and pull requests, and merge any existing pull requests before making my own commits (which means everytime I want to commit something to a port I have to first check if there are any PRs for it), or I just have to refrain from making commits to others' ports. I don't really like either of those options. The former is something I've not succeeded in doing all year, so I don't feel I'm likely to ever succeed at it. The latter means that when I notice a problem in a port that's not mine, instead of fixing it, I ignore it; that doesn't seem ideal.

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.

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.)

It looks like you're forcing a false dichotomy here: you either reduce 
your contribution or you should be allowed to completely ignore the 
guidelines that the project has put in place (it's literally on the 
checklist you have to fill in on every PR) and not attempt to 
communicate with others that might be doing competing work — even though 
it might antagonize some contributors. Well, you're such an important 
part of this project that I feel that if you're not willing to 
compromise in any way shape or form, then small volunteers like me have 
to just suck it up and accept that this is the way that things are run 
around here. (I would still stick around and contribute by the way.)

Since we're discussing this topic, I would like to seize this 
opportunity and ask the list for feedback regarding what is the best 
workflow moving forward for somebody with *my* profile. But this e-mail 
is already too long so I'm going to spawn a new thread.

// Leonardo.


More information about the macports-dev mailing list