streamline github dev process

[Mojca Miklavec]

On 30 May 2017 at 20:23, Helmut K. C. Tessarek wrote:
> Hello,
>
> Maybe we can streamline the github process a bit. As Mojca mentioned
> earlier, the macports project is heavily understaffed.
>
> Is there a way to allow maintainers to set labels? (e.g. the
> 'maintainer' or 'update' label)

This is probably a question for GitHub developers.

On the other hand, Zero King just started working on a Summer of Code
project where one of the goals was to set those labels by a bot in an
automated way.

One of the problems with "maintainer" label is not that much setting
the label itself, but actually knowing that the person who previously
identified himself/herself with email is the same as the person with
that username who submitted a patch. The problem here is two-fold:

- For most of the ports we don't have the GitHub handle in the
Portfile yet (and the change that we want this is not documented at
all places and sample Portfiles yet)

- Even if the GitHub handle *is* in the Portfile, one still needs to
manually check the Portfile (or run 'port info') to see who the
maintainer is.

The new bot could solve some of those problems, but it's still a pity
that maintainers cannot have slightly higher permissions set.

Nonetheless, the biggest problem is still convincing someone to review
the code and merge it. The label alone doesn't help that much if
nobody is looking at PRs.

> Also you could block merges until 1 or 2 people have reviewed and
> approved the change.

We already have problems getting a single person to review the
changes, getting two people to agree would be an overkill at this
point.

> Maybe you could allow maintainers to review and approve other pull requests.

This would be ideal, but I don't know if there is any way to allow
that. This is again a question for the GitHub developers.

> This is git. It's very easy to revert a broken commit. Since almost all
> of these commits are not conflicting, it's even easier to do so.
> I believe that we need more committers, even if you just allow
> maintainers to commit their own ports.
>
> I do understand that a commit to this repo can affect a lot of people,
> but on the other hand we need more traction and if a maintainer breaks
> his port, he/she will have to fix it anyway.
>
> Does any of my suggestions make any sense?

Ryan explained most points here.

In reality we have a bit more "organisational" than "technical"
problems here. 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 have *a lot* of commits, but of course that's not enough when we
have to deal with tens of thousands of ports.

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.

Mojca