Lieutenant needed: build and release process

[Dicebot via Digitalmars-d]

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)