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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 08.10.15 at 13:10, <wei.liu2@xxxxxxxxxx> wrote:
> On Thu, Oct 08, 2015 at 02:05:51AM -0600, Jan Beulich wrote:
>> 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?

No. "In place" simply means this needs to be written and tested.
And as things stand what will fit Ian may not fit me or vice versa.
I.e. unless this would be a server side thing (see the queue thing
I mentioned in another reply), multiple scripts may end up being
needed. And a day is a day - if it saves, say, 15 minutes per batch,
it would take 32 batches for the work to amortize.

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

And if there is a majority, I'm sure we will try it. I'm not arguing
because I mean to try to veto any such decision, I'm only trying
to point out that there also are reasons to stick with the current
model.

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

Thing is - I'm not of the opinion that it's impossible to do, but I am
of the opinion that any amount of time spent on mechanical things
is worthwhile trying to avoid or at least limit as much as possible. I
don't know about you, but I prefer to do productive things...

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

Because right now they're all being managed by the same people.
The main reason for questioning the quality of some Linux stable
trees was that the criteria based upon which selection of backports
happened appeared to be quite different between individual people.
I'd be much less worried of the quality of the actual backports.

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

Likely there are both. It's pretty clear to me that developers driven
by product release cycles, and with product releases preferring (and
as was expressed earlier, perhaps even expected to prefer) LTS
releases, focus would be on those releases that end up being used
in products. Of course that's not going to be the exclusive case,
but do you really think a large scale contributor would see much point
in starting work on a feature when they can be sure their code won't
land in any major distro for the next almost 2 years?

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

Sure. My main point really is that it's not just the current model that
isn't perfect, yet I'm getting the impression that staying with it has
been (almost) ruled out from the beginning.

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

That's a strange reply, considering that there is no strict boundary
between who "represents" XenProject and who does not. Or am I
missing something here?

Jan

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