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

[Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>]

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.

Ian.

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