streamline github dev process

[Daniel J. Luke]

On May 31, 2017, at 4:40 AM, Mojca Miklavec <mojca at macports.org> wrote:
> What I believe could help a bit would be to get some
> "mentors" assigned to new maintainers. Then those mentors would be
> kind of obliged to review submissions from them and keep track of
> their progress and vouch for commit rights once applicable. But this
> would need a bit more thought.

we used to do this (but maybe just for when someone was granted commit access, fkr was my mentor).

If there are experienced contributors who are willing to do this, then some focus on this would likely help us get the number of regular contributors up (which would help fix these kinds of issues).

> In theory GitHub's pull requests should allow to have *much less*
> committers. In theory doing the reviews and merging pull requests
> should be much easier that doing the same thing on Trac where the
> patches get outdated, cannot be reviewed on line-by-line basis etc. In
> practice I need to have a cheatsheet for merging pull requests and do
> some not-anywhere-easy-to-remember steps to be able to merge trivial
> PRs when some modifications are desired.

Streamlining the PR workflow is still maybe a good idea (I don't know enough to recommend any changes here, though).

One other (more radical) idea would be to split the ports tree into two - one where changes are auto-committed if they pass certain tests (lint ok, buildbot ok, test suite ok), and the 'curated' tree where someone has done a review and merged from the auto-committed one. I don't know if a universe where that exists is better, though (it would be pretty trivial to create a Portfile that could pass automated checks but do something bad if run on an end-user's machine).

-- 
Daniel J. Luke