PR usage by people with commit access

[Clemens Lang]

Hi,

On Fri, Nov 04, 2016 at 10:10:44AM -0700, Ivan Larionov wrote:
> I think this is a good practice for port maintainers with write access
> to repository still use PRs instead of direct commits to master.

I agree, with some limitations:

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

It's more work. We're all doing this in our free time and clicking
through GitHub's Web UI a couple of times just for the searchability is
not worth the extra effort. If you want the full picture, you'll have to
search the history anyway, which luckily is now much faster than it used
to be with Subversion.

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

Absolutely agree.

> * Ability to get a feedback / review from other project members.

Agree for the cases where other people interested in the ports and
capable of reviewing exist, and those people have the time to review in
a timely fashion.

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

We do the same thing at my workplace, but this only works because there
are other people with an interest to review your changes (being paid to
do it). I'm not sure whether we have the manpower to review every commit
pushed into MacPorts.

-- 
Clemens