Re: RFC: LTS and stable release scheme

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

On Tue, Oct 06, 2015 at 07:38:30AM -0600, Jan Beulich wrote:
> >>> On 06.10.15 at 13:07, <wei.liu2@citrix.com> wrote:
> > A majority of developers express interests in trying a shorter release
> > cycle -- to change from 9 months to 6 months [0]. There are, however,
> > repercussions on how we manage stable and possible LTS releases.
> 
> I find it kind of odd to try to answer question 2 (cadence) without
> first having answered 1 (whether to have stable releases at all). In

Right, all my questions were based on one assumption that "we may need
LTS".

> particular, the major downside of stable releases - them being
> "better" than others - hasn't even been mentioned in you mail. And

Is that a particular downside? I don't see it that way. Different
releases are, in nature, different. I can see why you want to treat
every release equally, but with limited man power we sometimes have to
make a choice.

> afaict the reason for there being various LTS maintainers in Linux
> is mainly because almost anyone can propose to LTS-maintain a
> certain branch, and hence whenever an organization want a
> certain release to be long term maintained all they have to ask
> themselves is "Do we want to invest the resources for making it
> so?" Along with this question goes - as seen internally here - the
> question whether to instead align which kernel version to pick for
> a product with which kernel version is expected to become an LTS
> one.
> 

The proposed scheme doesn't preclude such arrangement.

> I'm not sure if it's still that way nowadays, but in the years after
> stable and long term releases got introduced in Linux even long
> term branches weren't all equal: The general stable tree maintainer
> actively argued against the use of certain branches (or certain
> releases on a branch after it changed ownership), due to it being
> of unknown (in the best case) quality.
> 
> Bottom line: I think the current model, with all releases being
> equal and there being the opportunity to hand over branches to
> "external" maintainers after the XenProject support ended
> (exercised exactly once to date), is quite a bit better than any
> of the LTS options I've seen proposed so far.
> 

Yes. I see your point.  But at least one user has asked for longer term
full support. Up till now the "hand over" hasn't happened that often
(only once). And keep in mind that downstream consumers are not only
commercial vendors that have engineers working old trees for a product,
they might also be a distributions that simply wishes to have full Xen
support longer than their own release cycle.

With unlimited manpower we can use the current model to equally treat
each release LTS. In reality this is not the case, so I see the need for
using LTS model to effectively direct limited resources.

Or do you have different view on how various downstream can expect from
Xen to make the current model good enough for them?

What do you propose when we regarding stable branches when we switch to
6 months cycle?

Wei.


> Jan