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

[George Dunlap <George.Dunlap@xxxxxxxxxxxxx>]

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".

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.

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?

 -George

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