Re: [Xen-devel] RFC: LTS and stable release scheme

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 07.10.15 at 19:56, <George.Dunlap@xxxxxxxxxxxxx> wrote:
> On Tue, Oct 6, 2015 at 2:38 PM, Jan Beulich <JBeulich@xxxxxxxx> wrote:
>>>>> On 06.10.15 at 13:07, <wei.liu2@xxxxxxxxxx> 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
>> particular, the major downside of stable releases - them being
>> "better" than others - hasn't even been mentioned in you mail. And
>> 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.
>>
>> 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.
> 
> So going back over this mail, I don't think I could restate your
> argument other than "releases are not equal".

And indeed I didn't try to make any other statement, but just tried
to explain where un-equality can come from and what undesirable
things can result from it.

> The first half of the first paragraph is how Linux ended up with
> multiple LTS maintainers.  So far we've been suggesting the xenproject
> team doing it, and choosing based on a regular cadence, so that's not
> relevant.

It's been suggest, not decided, so I think considering the alternative(s)
is relevant.

> The second half is about choosing a kernel version based on expected
> LTSes.  I don't quite see what the issue here is either; "is expected
> to become" may point to the idea that it's not clear ahead of time
> which release will become an LTS.  If that's the case, then it is
> addressed by having a regular cadence announced ahead of time.
> 
> The second paragraph is about even LTS releases being unequal.  That
> won't be an issue with our proposal, because the xenproject team is
> doing the maintenance, so quality is under our control.  (Or to put it
> another way -- it's not any different from recommending people to use
> 4.4 instead of 4.2, which are also stable releases.)
> 
> The final paragraph talks about handing over branches to "external"
> maintainers, but that's also still an available option to us -- if
> someone wants to take a non-LTS release and continue to support it, or
> take an LTS release and support it beyond our normal window, they can
> still do that.
> 
> So taking out everything that's been addressed or doesn't apply, I get:
> 
> "The major downside of stable releases -- them being 'better' than
> others -- hasn't been mentioned. ...Bottom line: I think the current
> model, with all releases being equal... is quite a bit better than any
> of the LTS  options I've seen proposed so far."
> 
> Which unfortunately doesn't help me understand where you're coming
> from.  Could you try to expand on that a bit?

I think the main misunderstanding is - as said above already - that you
take it that what has been suggested is the one and only option, while
my previous reply really was meant to put side by side the problems
of that model with the problems of other models. With the outcome
that in my opinion the current model has the smallest set of problems
when considering the equality aspect. I didn't mean to negate that the
LTS model also has (consumer side) benefits over the current one, but
I'm undecided whether those outweigh the problems.

Jan

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