Epic
Major 1) Set the maintenance branches as "protected" on GitHub.
https://help.github.com/articles/about-protected-branches/
First version can focus on the main repository but we'll later have to automate the branch protection on a repository list extracted from the modules (see scripts.nxutils.Repository.eval_modules and scripts.nxutils.Repository.eval_addons)
2) Make the T&P create a Pull Request instead of pushing a merge/rebase when the target is a maintenance branch.
https://developer.github.com/v3/pulls/#create-a-pull-request
After PR is created, one can change the content of the source branch, the PR is updated and the status re-evaluated.
3) Run code review tools on the PR. Main candidates seems to be:
https://github.com/integrations/reviewninja
https://github.com/integrations/reviewable
4) Make the PR merge-ability dependent on some specific status corresponding to the code review results.
https://help.github.com/articles/enabling-required-status-checks/
For instance, with reviewninja, we would configure GitHub to require "two ninja stars" for the PR being merged. Ninja stars are granted by the reviewers.
Bonus:
3.1) as well as automated quality checks in the mean time. For instance:
https://github.com/integrations/codacy
https://github.com/integrations/codecov
https://github.com/integrations/versioneye
https://github.com/integrations/sideci
https://codeclimate.com/features
3.2) and Nuxeo long-time running tests (FT) which could be removed from the T&P first execution and delayed (and parallelized) since the branch is protected.
5) we may need to also setup a GitHub hook for executing some automated actions when the PR status changes to become merge-able, like... merging the pull-request, sending notifications...
That can also be done in the first place by a recurrent script like the one which cleans the old branches.
6) once that tooling is setup, we could make the T&P propose two options: Build, Test & create a PR, or Build, Test & get Code Review (+ all other checks) on my branch but don't (automatically) merge it yet.
7) or we can invert the process and start the workflow from the PR or even the branch push (on a given Git namespace), then create job, tests, status and so on. The T&P would mainly become dynamically instantiated job; still manually available on purpose.
