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'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. * 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. * 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. -- With best regards, Ivan Larionov. _______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
