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

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 11/08/15 12:13, 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.
>
> 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.

Very much A.

By definition, 1(c) will destabilise the tree and generate artificial
work for the maintainers and committers.

The most important action at this point is to stabilise 4.6 for release,
and peoples efforts are far better spent pursuing that, rather than
continuing work on unstable.

For the sake of a couple of weeks, contributors can keep their patches
for a little while longer.

~Andrew

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