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
