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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 08.10.15 at 12:39, <george.dunlap@xxxxxxxxxx> wrote:
> On 08/10/15 09:05, Jan Beulich wrote:
>>>>> On 07.10.15 at 19:45, <George.Dunlap@xxxxxxxxxxxxx> wrote:
>>> The steady state for "R9 S3 {18,36}" is to have 2 releases receiving
>>> bug fixes, and 2 releases receiving security fixes at any given time;
>>> and this happens every 3 months; total of 8 bug-fix and 8
>>> security-only ports per year.
>> 
>> Not sure what the latter 8 stands for - we don't currently do any
>> more releases from branches in security maintenance mode, all we
>> do is provide respective backports in XSAs and apply those to the
>> trees once the issues get published.
> 
> Maintenance release every 3 months -> 4 maintenance releases per year, *
> 2 outstanding bugfix relases = 8 total "bugfix" maintenance releases per
> year.

That explains the first 8, but I tried to point out that afaics there
is no second 8 (which however you had in your description as
"8 security-only ports per year").

>> Perhaps there's room for further automation here, yet as with
>> any automation the question is how quickly getting this in place
>> will amortize itself.
> 
> Aren't stable branches already tested with OSStest?  If they aren't they
> certainly could be made to be tested pretty trivially, I think.
> Wouldn't an osstest (which includes both build and functional tests)
> plus an RC be sufficient?

Yes, they are getting tested. Yet - as just said in a reply to Ian -
while it's a possible model to simply throw things in and wait for them
to break, I not only feel uneasy about doing so (we don't do that on
unstable after all), but I also dislike the idea of having to turn back
to the branch a day or so later (when the failure report arrives)
instead of (normally) being done once I hit enter on the "git push".

>>> Another thing which has been suggested is to treat releases
>>> differently; for instance, every 4 releases (24 months), release an
>>> "LTS" release that has longer support requirements.  If we chose to
>>> have LTS releases, we may then also choose to have normal releases get
>>> a shorter support window.  It's also been suggested that security
>>> fixes are really what downstreams need from an LTS release; once
>>> you've been using something for more than 2 years, you've probably
>>> already found all the bugs which bother you.
>> 
>> But wouldn't that mean that the current model of 3 years of security
>> support is (almost) what people want from an LTS branch?
> 
> Is there a specific proposal you are advocating here?

I'm rather asking whether, if security support is the main concern,
the current model really is that far from what is being wanted. E.g.
consider the option of just extending security support within the
current model.

> Here is my summary of your argument above (let me know if it's accurate):
> 
> ---
> We have two options WRT LTS releases: Either we make LTS releases known
> ahead of time, or we choose them afterwards.
> 
> There is no value to developers to getting features into non-LTS
> releases; and therefore, if the LTS releases are known ahead of time,
> then the LTS release will have exactly the same pressure as a normal
> release to get features in.  (And of course, if we move from a 9-month
> regular release to a 24-month LTS release, the pressure will be even
> greater than it is now.)

Well, not really "no value", but less.

> [I'm not sure if you're arguing the following or not.] In fact, in the
> time after an LTS release, many developers may completely stop
> developing until the next LTS release comes around.

And perhaps again not "completely", but slow down (perhaps
significantly).

> First of all, I completely agree that not announcing LTSes ahead of time
> has unacceptable effects on distributions and other downstreams.  I
> think LTSes, if we choose them, should happen on a regular, predictable
> basis.
> 
> However, I don't agree that getting features into non-LTS releases is of
> no value to developers.  Many users will use non-LTS releases (probably
> Fedora, and a lot of our direct users, and probably anyone using
> debian-testing most of the time).  Furthermore, downstreams that want
> particular features are much more likely to cherry-pick them from stable
> releases than from unreleased xen-unstable.

True.

> I think at some point we may just have to throw out a couple of options
> and do a 4-point survey as we've done before (i.e., "argue againts / not
> happy but won't argue / happy but won't argue / argue for") and see
> where we stand.

Agreed.

Jan

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