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

[George Dunlap <George.Dunlap@xxxxxxxxxxxxx>]

On Tue, Oct 6, 2015 at 3:52 PM, Jan Beulich <JBeulich@xxxxxxxx> wrote:
>>>> On 06.10.15 at 16:09, <wei.liu2@xxxxxxxxxx> wrote:
>> What do you propose when we regarding stable branches when we switch to
>> 6 months cycle?
>
> See the chicken-and-egg problem: I can't answer this, because the
> issues with the stable trees are the main reason I don't support the
> change to the release cycle (yet).

OK, so we have to decide on a *set* of factors, rather than just one.

Let's try to be analytic.

So we have so far identified 4 "parameters" that we can tweak:

1. Release frequency.  At the moment, this is "9 months".
2. Length of time bug fixes are backported.  At the moment this is "18 months".
3. Length of time security fixes are backported.  At the moment this
is "36 months" (i.e., original 18 months of bug fixes + 18 further
months of security-only fixes)
4. Subset of releases given treatment for #1 and #2.  At the moment
this is "all".
5. The release frequency for maintenance release.  At the moment this
is every 3 months.

Let's call this "R9 S3 {18,36}"  (Release every 9 months, maintenance
release updates every 3 months, all releases get bug fixes for 18
months and security updates for 36 months".

Metric-able criteria that are important to people:
1. Amount of time once a feature has been accepted until the time it
shows up in a release.  This is directly related to release frequency.
2. Amount of time a bug fix has been checked into tree before it shows
up in a maintenance release.  This is directly related to the
maintenance release frequency.
3. Amount of time a release receives bug fixes and/or security
updates.  These are related directly.
4. Total amount of work to maintain stable releases.  The *number* of
such releases is directly related to all of the above, but must be
calculated.

"All releases the same" is a criteria that's been brought up, but I
think there are probably practical implications we haven't teased out
yet.

(Please let me know if there are other criteria we should be considering.)

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.

There are many people in favor of changing #1 to "6 months".  This
gives us "R6 S3 {18, 36}".

The steady-state for "R6 S3 {18,36}" is to have 3 releases receiving
bug fixes and 3 releases receiving security-only fixes at any given
time.  This gives is a total of 12 bug-fix and 12 security-only ports
per year.

It has so far been assumed in this discussion that this would be an
undue burden, and therefore not acceptable.  But it's worth asking
whether that is actually the case.  It has been argued, for instance,
that the difficulty in backporting a patch scales with the distance in
commits that the patch has to be ported over.  Porting a patch to a
releases 3, 9, and 15 months ago isn't 1.5x as much work as porting it
to one 3 and 12 months ago.

But I would guess that the porting *is* more work; and the building,
testing, and releasing certainly is 1.5x more work.

We could also explore other options, like having more automation, or
spreading the work of porting patches among more people.

Another option could be to decrease the frequency of maintenance
releases.  "R6 S4 {18,36}" gives us 9 bug-fix and 9 security-only
ports per year -- not much more than what we have now.  But of course
this increases the amount of time between a bug fix and the time it
shows up in a maintenance release, which is less desirable.

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.

So one option would be "R6 S3 {12,12} L24 S3 {24, 48}" (Regular
releases every 6 months, maintenance releases every 3 months, fixes
backported for 12 months; LTS release every 24 months, bug-fixes
backported for 24 months, security fixes backported for 48 months).
Steady-state this gives us a max 3 releases receiving bug-fix
backports and 1 release receiving security backports at any given
time.  This gives us 12 bug-fix and 4 security-only ports per year.

Any thoughts on this?  Anything else to add or discuss?

Personally I like the LTS model.  I think arguably if we use the
numbers I chose above, it shouldn't be any more actual work than it is
now (as there are still only 4 releases every 3-month maintenance
window), and I don't understand the concern with "treating releases
differently".

 -George

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