Re: RFC: Survey on release cycle

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

On Wed, Oct 14, 2015 at 01:21:11PM +0100, Ian Campbell wrote:
> On Mon, 2015-10-12 at 18:32 +0100, Wei Liu wrote:
> > 
> [...]
> > There are several general options on how to proceed that I summarise
> > from previous discussions. Note that because there are too many moving
> > parts I pick some of my preferences as a starting point for the
> > discussion.
> 
> I take it suggesting (and voting upon) other options is also acceptable?
> 

Yes, of course.

> Assuming so then:
> 
> > # 6 months release cycle + current stable release scheme
> > 
> > The same stable release scheme applies (18 months full support + 18
> > months security fixes). Encourage more people to step up to share the
> > maintenance burden if necessary. Automate part of the workflow to
> > maintain stable releases. Write down guideline for maintainers.
> 
> I think this "current stable release scheme" and "18 months full support",
> implies an increase in the number of supported stable releases at any given
> time.
> 

Yes, it is the case.

> I'd therefore like to also propose:
> 
> # 6 months release cycle + extended security support
> 
> The number of active stable branches remains constant (I think this is
> currently 2, implying a reducing from 18 months to 12 months) but the
> security support period is extended, such that the final cut off is the
> same 36 months (18+18 in the current scheme). So this becomes 12 months of
> full support + 24 months of security support.
> 

This is reasonable suggestions. I'm not quite sure about the number of
full support backports vs security backports though, so the actual
impact is not very clear to me. But I think it is safe to say with this
scheme the work is less.

> Aside: I'm a bit confused regarding whether our "stable release scheme" is
> defined in terms of number of concurrently supported releases or in terms
> of an absolute time. 
> http://wiki.xenproject.org/wiki/Xen_Project_Maintenance_Releases definitely
> says it is concurrent release based, but your proposal above suggests
> otherwise. Is the wiki wrong?
> 

Sorry about the confusion. I picked the time-based interpretation
because that's why I slightly preferred (again, note that all details
are merely my preferences). There is room for discussion of course.
Whether the stable releases based on absolute time or number of
concurrent releases, I won't argue for one over another.

I think it would be better if Jan or Ian J express their preference
since they have been doing this for a long time and have better ideas of
what works best, and if we need more helping hand in stable release
maintenance.

It's safe to say people expressed opinions so far care more about 6
months release cycle and are willing to comprise on how we manage
stable releases (or LTSes).

Wei.

> Ian.