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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 07.10.15 at 19:45, <George.Dunlap@xxxxxxxxxxxxx> wrote:
> 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.

We switched this to 4 months not too long ago. This changes some
of the numbers further down, but not in a way that would significantly
affect the meat of this analysis.

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

> It has so far been assumed in this discussion that this would be an
> undue burden, and therefore not acceptable.

I don't think anyone said "undue". All that was said was that the
amount of work to be put into this increases.

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

Now that goes slightly astray: People like me having to maintain
older releases for much longer time need to do certain backports
anyway (the older the release, the higher the chance that a
difficult backport may result in a decision being made to ignore
that fix as not important enough, due to the risk of the backport
going wrong being higher than that of leaving the bug in place).
I.e. at least a good part of the _backporting_ overhead can
probably be discounted. What I consider more of an issue is the
tedious (because purely mechanical) task of committing the
patches to the respective stable trees, which (in my way of
doing it) implies test builds for every commit. This is time I
consider worthwhile spent as long as it doesn't grow too much,
but of course this time could be used for less boring and more
productive things.

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.

> 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?

> 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?

So using the 4 month stable release cadence I get currently 6
stable releases a year (two maintained branches, ignoring short
periods of overlap), compared to 6 ordinary stable releases (two
ordinary branches) plus 6 LTS releases (two LTS branches) a year,
i.e. doubling the amount.

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

If what becomes an LTS release is known up front, the pressure to
get things into such a release may (and, looking at what I got to
notice on Linux, will) be quite a bit higher. After all the expectation
and intention is for distros to particularly use those releases when
caring for long term maintenance. And with that why would
contributors bother much about getting things into non-LTS
releases when those won't get used by many / for a reasonable
time period anyway?

If what becomes an LTS release is to be determined only at the
end of a branch's ordinary life cycle, the above problem can be
avoided, but downstream consumers having picked the "wrong"
release will be penalized. This is what we've been getting
complaints on by openSUSE users relative to the kernel versions
(and which keeps coming up the discussion of up-rev-ing the
kernel version post release, which as you surely can imagine has
all kinds of up and down sides). Plus depending on who gets to
maintain the branch from that point on (if not handed to always
the same person), quality and hence value to the downstreams
may heavily vary.

Jan

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