Re: RFC: change to 6 months release cycle

[Wei Liu <wei.liu2@citrix.com>]

On Mon, Oct 05, 2015 at 05:37:32AM -0600, Jan Beulich wrote:
> >>> On 05.10.15 at 13:23, <wei.liu2@citrix.com> wrote:
> > On Mon, Oct 05, 2015 at 05:04:19AM -0600, Jan Beulich wrote:
> >> >>> On 02.10.15 at 19:43, <wei.liu2@citrix.com> wrote:
> >> > The main objection from previous discussion seems to be that "shorter
> >> > release cycle creates burdens for downstream projects". I couldn't
> >> > quite get the idea, but I think we can figure out a way to sort that
> >> > out once we know what exactly the burdens are.
> >> 
> >> I don't recall it that way. My main objection remains the resulting
> >> higher burden of maintaining stable trees. Right now, most of the
> >> time we have two trees to maintain. A 6-month release cycle means
> >> three of them (shortening the time we maintain those trees doesn't
> >> seem a viable option to me).
> >> 
> >> Similar considerations apply to security maintenance of older trees.
> >> 
> > 
> > Sorry, my memory failed me. So the major objection is the maintenance
> > burden of stable releases.
> > 
> > What do you consider "must-have"s when it comes to stable releases?
> > 
> > The only "must-have" to me is that we need stable releases. This
> > doesn't preclude us from exploring other options to achieve that goal.
> > 
> > Just to throw around some ideas: we can have more stable tree
> > maintainers, we can pick a stable tree every X releases etc etc.
> 
> Both points we have been discussing before:
> 
> More stable tree maintainers means higher total cost (there's certainly
> some amortization if a single person maintains the same [parts of the]
> tree everywhere), plus an increased chance for certain backports
> ending up in only some of the trees (clearly bad if a newer one retains
> a bug that got fixed in an older one).
> 
> Picking a release (or a longer term maintained one) results in some
> releases being "better" than others.
> 

If this is not an option for you. We can work on a technical solution
for having more stable release maintainers. 

For example, we create an email alias for stable backport requests,
subscribe every stable tree maintainers to that list. This should make
it impossible to miss patches. The rest is subject to individual stable
tree maintainers' discretion if a certain patch goes in or not. This has
worked and scaled reasonably well for Linux.

Note that I'm not advocating one solution over another. Ian's suggestion
of 1/N LTS release is worth considering. I'm just saying there is a
technical solution for having more stable tree maintainers.

Wei.

> Jan