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

[Wei Liu <wei.liu2@xxxxxxxxxx>]

On Thu, Oct 08, 2015 at 02:05:51AM -0600, Jan Beulich wrote:
> >>> On 07.10.15 at 19:45, <George.Dunlap@xxxxxxxxxxxxx> wrote:
[...]
> 
> >  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.
> 

Building every commit can be easily implemented. I don't think it takes
more than a day to write a script.  What do you mean by "in place"? Are
there any other considerations?

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

Perhaps. But we're still lacking data points here. The only downstream
that voiced opinion recently was Steven.

But for now, let's say 3 years of security support is good enough. Do
you have proposal that would fit 6 months release cycle? A majority of
developers seem to think 9 months is too long and 6 months is worth
trying.

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

So this seems to be your major concern. My interpretation is that you
kept stressing workload because you think it is a major issue. 

I fail to get the idea why this would be a problem. Maybe you're seeing
every backport as your sole responsibility?  From Xen project's point of
view, this amount can be absorbed by a team of stable release
maintainers. Then this leads to your concern of varying quality of
different branches? But again, I fail to grasp that idea. All stable
trees maintained by Xen project are equally good.

Further more, there is argument such scheme wouldn't increase workload.
Ian mentioned the amount of backport during a set period is the same.
With automation mechanism in place (as simple as a script) there
wouldn't be too much work.

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

I disagree. Many developers care about getting their patches upstream
but are not interested in which releases their features are going to be.

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

As you mentioned above, there are always upside and downside with *any*
change. We won't know until we try.

But what we do know at hand is that current scheme is not perfect, hence
the whole discussion.

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

This is really irrelevant to this discussion. If we hand that to
external people, that means it's out of our control and by definition we
don't care that much -- no matter what scheme we use.

Wei.

> Jan

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