Re: [Xen-devel] [URGENT RFC] Branching and reopening -unstable

[Lars Kurth <lars.kurth.xen@xxxxxxxxx>]

> On 11 Aug 2015, at 12:13, Ian Jackson <ian.jackson@xxxxxxxxxxxxx> 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.


What do other projects that are similar to us do? And how does it work for 
them? Any reference points?

> 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.
> 
> 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.

It may be helpful, to evaluate this proposal against a couple of the 
outstanding patch series which were close and didn't make it into 4.6. In other 
words, change sets which we reasonably expect to turn up in the next 4-8 weeks 
or so. 

Regards
Lars
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel