Re: [URGENT RFC] Branching and reopening -unstable

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

On Tue, 2015-08-11 at 13:55 +0100, Andrew Cooper wrote:
> 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.

While I agree that people who have things to do for the release should
prioritise the release not all contributors have a stake in the stable
releases and even those that do may not have anything which they are able
to help with etc (or e.g. have other pressures which prevent them dropping
all development work to dedicate full time to the release).

Realistically even those with 4.6-ish tasks and responsibilities aren't
going to have enough such things to do to fill their time 100% between now
and the release.

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

A full freeze cycle is more like 6-8 weeks not a "couple", which is where
the tension arises between the stable release and other developers.

What seems to have been missed (or gotten a bit mislaid) in the current
analysis is _when_ to branch, the analysis assumes at rc1 while the status
quo for the last few releases has been just before release (or very late in
the rc cycle at least), which are two opposite ends of the spectrum.

There is of course plenty of middle ground between those two points. In
your use of "a couple of weeks" are you making a counter proposal to branch
at (say) rc3 or are you arguing to keep the development branch closed until
9 October?

Depending on where in the rc cycle we branch different options may have
different weights of up or down side.

Ian.

> 
> ~Andrew