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
