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 _______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
