Lieutenant needed: build and release process

[Dragos Carp via Digitalmars-d]

> ne important (in my opinion) disadvantage misssing: 
> considerably harder PR maintenance (missing automatic 
> categorization and separation between phobos / dmd teams). 
> Being forced to look ar DMD pull requests to do Phobos 
> maintenance will add lot of context overhead for me.

This kind of attitude worries me: every team works happily in its 
own cozy repository and it doesn't feel responsible about the 
other repos. The consequence is that, while breeding a new 
release, the release manager MUST take most of the burden about 
coordinating the teams and their work. This is a very complex 
task which requires insight knowledge in all 3 repos.

Having 3 repos, one team is not encouraged to help the other team 
to get the release out the door. This is because one team have a 
higher bar to help the other: it needs to checkout the right 
version of the foreign repo, manage own branches in the foreign 
repo, etc. Maybe this is the reason of multiple regression in the 
last release or the "virtual keyword surprise" (at least for some 
people).

I think that a 2 phase process similar to the Linux kernel 
release process [1] would work much better and motivates all the 
teams to help with the release:

Phase 1. Merge window: merge PRs containing new features
Phase 2. Test and stabilization: merge bugfix PRs only

Ideally the first phase is quite short (1 week for example) and 
it can be close supervised (or even executed??) by Walter and/or 
Andrei.

The second phase will continue until the acceptance criteria are 
met, the teams having a focus on the release (they get no new 
goodies till the test phase is done).

The normal development happens somehow offline by preparing 
quality PRs to be merged in phase 1.

>
> I also don't feel like it will help much for release 
> preparation. Bisection and history investigation - undoubtedly. 
> But for release management building stuff is one of the easier 
> parts.

Agree, the technical build steps of the release process are easy. 
Just the casual experimenting with D is somehow clumsy.

[1] - 
https://www.kernel.org/doc/Documentation/development-process/2.Process