Do the contributing rules apply just to non-committers?

Christopher Jones jonesc at hep.phy.cam.ac.uk
Sun Oct 1 20:41:06 UTC 2017



> On 1 Oct 2017, at 6:53 pm, Ryan Schmidt <ryandesign at macports.org> wrote:
> 
> 
> On Oct 1, 2017, at 12:41, Leonardo Brondani Schenkel wrote:
> 
>> On 2017-09-27 20:36, Leonardo Brondani Schenkel wrote:
>>> On 2017-09-27 20:18, Ryan Schmidt wrote:
>>>> Most projects on SourceForge organize their files in folders. If dict is such a project, then you should specify here which folder the file is in, to avoid redirects. See https://trac.macports.org/wiki/howto/AvoidRedirects
>>>> Assuming LIBTOOL is the file to be run, it should be the absolute path (${prefix}/bin/glibtool).
>>>> The default mode for xinstall is 0755, i.e. executable. Conf files should not be executable, so you should specify mode 0644 (-m 0644).
>>>> 
>>>> Moreover, users are expected to edit conf files, but by installing the file in this way, it is registered to the port, which means any user customizations will be lost if the port is deactivated or upgraded. Instead, you should install a sample conf file, and print instructions telling the user how to copy that sample conf file to the real one. See https://trac.macports.org/wiki/PortfileRecipes#configfiles
>>> Thanks for the input. Will submit a PR.
>> 
>> After replying to your message (within minutes) that I was going to submit the PR (which I did the next day [1] since it was late on my time zone) you felt the need, one day after I opened the PR and explicitly notified you in the PR for review, to go ahead and commit directly to the port — which created a conflict that I'm the one that has to fix if I want to get the PR merged.
>> 
>> [1] https://github.com/macports/macports-ports/pull/842
>> 
>> I know this is a very small thing in isolation but it's also not the first time it happens [2]. It's just the attitude that rubs me off the wrong way, if you forgive me being totally honest. I know I'm just a nobody and a small-time contributor here, and I really hope that one day I can achieve 1% of the impact that you do because I have nothing but admiration for your work for MacPorts — but I really have to say that I was expecting a little bit more in the way of courtesy. It is not very encouraging to the "second tier" of contributors to be volunteering time to this project when they perceive that their time is not valued in the same way, and the rules they have to follow are different.
>> 
>> [2] https://github.com/macports/macports-ports/pull/415
>> 
>> The reason I'm posting this is because if I said nothing this would be a pattern that will keep repeating and frustrating me in the process, not because I want to personally attack you. This is a great project and I want to keep contributing, in case I'm welcome. Plus I want to figure out if I have completely wrong expectations about how things should work — in which case I will promptly apologize, shut up and try to educate myself.
> 
> 
> 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.
> 
> The port is openmaintainer, which means other developers are to feel free to make minor changes to the port, so I did so.
> 
> 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.

Actually the *last* thing you should do is manually merge open PRs into your own master checkout before submitting your changes, as all that will do is push those pull requests direct to master, by passing the review process. Any  PR (or commit) you make should be against a clean checkout of upstream master.

The minimum solution for is to just check if there is a open PR against a port you wish to make a change to, and if there is first review if that PR is fixing the same thing or something else. If the same thing, but you want to suggest a different change, just make a comment on the PR and discuss it there. If it is not related, well then it is best to wait until that PR is merged until making any new ones.

Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macports.org/pipermail/macports-dev/attachments/20171001/d798b889/attachment-0001.html>


More information about the macports-dev mailing list