Re: [URGENT RFC] Branching and reopening -unstable

[Ian Campbell <ian.campbell@citrix.com>]

On Tue, 2015-08-11 at 12:13 +0100, Ian Jackson wrote:
> Wei Liu writes ("[URGENT RFC] Branching and reopening -unstable"):
> > Branching should be done at one of the RC tags. It might not be enough
> > time for us to reach consensus before tagging RC1, so I would say lets
> > branch at RC2 if we don't observe blocker bugs.
> > 
> > Maintainers should be responsible for both 4.6 branch and -unstable
> > branch.
> > 
> > As for bug fixes, here are two options.
> 
> I think this conflates the three questions which should be answered:
> 
>  Q1: What is the status of the newly branched -unstable ?  Should
>      we avoid (some or all) big sets of changes ?
>       (a) Don't branch
>       (b) Branch but don't allow /any/ big changes.
>           Seems to make branching rather pointless.
>       (c) Branch but allow /some/ big changes.
>           Tree is `half open', which is not ideal.
>       (d) Branch and allow /all/ changes.
> 
>  Q2: If we don't avoid such changes, and a bugfix has a conflict
>      with a change in the new unstable, who is responsible for fixing
>      it up ?  Options include:
>       (a) the relevant maintainers (double whammy for maintainers)
>       (b) the submitter of the bugfix (very undesirable)
>       (c) the submitter of the big set of changes (but what do
>             we do if they don't respond?)
>       (d) the stable tree maintainers (already ruled out, so included
>             in this list for completeness; out of the question IMO)
> 
>  Q3: What workflow should we use, for bugfixes for bugs in 4.6-pre ?
>     There are three options, not two:
> 
>       (a) Bugfixes go to 4.6 first, cherry pick to unstable
>           This keeps our focus on 4.6, which is good.
> 
>       (b) Bugfixes go to 4.6 first, merge 4.6 to unstable.
>           Not tenable if we have big changes in unstable.
> 
>       (c) Bugfixes to to unstable, cherry pick to 4.6.
>           Undesirable IMO because it shifts focus to unstable.

FWIW I think historically we have always done (c) here. That's not to say
we shouldn't change but thought it worth noting.

> Of these 2(c)/3(a) would be ideal but we don't have a good answer to
> the problem posted in Q2(c).  I think that leaves us with 2(a):
> maintainers have to deal with the fallout.
> 
> That makes 1(d) untenable in my view.  As a maintainer, I do not want
> that additional workload.  That leaves us with 1(a) or 1(c)/2(a)/3(a).
> 
> With 1(c), who should decide on a particular series ?  Well, who is
> taking the risk ?  The maintainer, who will have to pick up the
> pieces.  I therefore conclude, we have two options:
> 
> A "1(a)/-/-"
> 
>   Do not branch yet: defer divergence until the risk of bugfixes is
>   much lower.
> 
> B "1(c)(maintainer)/2(a)/3(a)"
> 
>   Branch.
> 
>   Maintainers may choose to defer patch series based on risk of
>   conflicts with bugfixes required for 4.6.  Clear communication with
>   submitters is required.
> 
>   Bugfixes for bugs in 4.6 will be accepted onto the 4.6 branch.
>   Maintainers are required to cherry pick them onto unstable.
> 
>   Bugfixes will not be accepted for unstable unless it is clear that
>   the bug was introduced in unstable since 4.6 branched.
> 
> I am happy with B because it gives the relevant maintainers the
> option.
> 
> Ian.