PR usage by people with commit access

Rainer Müller raimue at macports.org
Fri Nov 4 10:50:15 PDT 2016


On 2016-11-04 18:10, Ivan Larionov wrote:
> I'm not saying that you have to wait for review or something like
> this, but opening a PR from your branch and then merging it has some
> pros:
> 
> * Better visibility of changes. Instead of cloning full repository
> and digging through history I can search PRs by port name and see
> changes which were done by maintainers and contributors.

You cannot filter by portname in a reasonable way. GitHub search is just
too limited to support anything like that. That is one of the main
reasons we rejected GitHub Issues, which have the same problem.

Isn't it much easier to just view the history of the corresponding port
directory than a convoluted search? You can also do that on GitHub:

https://github.com/macports/macports-ports/commits/master/python/py-sqlparse

> * Using the same change methods as outside contributors may help to
> develop better PR flow. Currently I see some lack of the standard
> flow, maintainers commit contributors' changes in different ways, PRs
> marked as rejected while they're actually merged, people ask to
> enable "Allow edits from maintainers" for PR, etc.

They were "rejected" because GitHub does not have a way to mark them as
"merged" unless the exact same object was merged. In case the maintainer
had to make additional changes to the commit, GitHub will not recognize
them as merged.

The only solution we found so far is to push the modified commits back
to the pull request branch, which will mark the pull request as
"merged". However, that requires that pull request authors allow
modifications by maintainers.

> * Ability to get a feedback / review from other project members.
> 
> We use private github setup on my work and we have a rule that you
> shouldn't commit directly to master in a project with multiple
> contributors until it's very small change like fixing typo. Open PR,
> ask for review, merge. Or fix issues and merge if you got any useful
> comments on PR.

Who would be better to review the change then the maintainers of ports
themselves? I feel like this would unnecessary slow down the process of
getting the update out.

Rainer


More information about the macports-dev mailing list