On Tuesday, 9 September 2014 at 09:59:37 UTC, Dragos Carp wrote:
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.
This is not about happiness or zone of comfort - I am simply not
competent to judge even most trivial DMD pull request as opposed
to Phobos ones. Team separation exists for a reason - skills and
knowledge required are totally different. Some developers do both
but I doubt it is even the majority of active maintainers. By
merging repos you are likely to discourage me from paying
attention at all, not to invest huge amount of effort in
increasing DMD proficiency.
I am also not sure what what coordination you are speaking about.
Integrity of 3 repos is verified by auto-teser. Cross-repo issues
are rare and usually handled by those who has merge access to
both. Release manager shouldn't normally need any detailed
knowledge of repo internal development and just tag certain
branch heads. If this is not the case we have some hidden problem
I am not aware of.
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).
It feels like you have imagined some process that does not really
match reality :( Explicit tracking of matching version is never
needed - it is either branch head for all repos, or identically
named tags.
I have already explained above some of the real reasons that make
closer collaboration close to impossible.
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.
This all sounds like solving the problem that doesn't exist
instead of addressing the real ones (lack of clear documented
rules for release packaging and awkward cherry-pick based release
branch maintenance)
