Do the contributing rules apply just to non-committers?
Leonardo Brondani Schenkel
leonardo at schenkel.net
Sun Oct 1 19:17:35 UTC 2017
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
> 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
(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.
More information about the macports-dev