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

[Wei Liu <wei.liu2@xxxxxxxxxx>]

On Thu, Oct 08, 2015 at 06:13:27AM -0600, Jan Beulich wrote:
> >>> 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.
> 

This is still based on the assumption that only you alone is going to do
the work. If you agree we can solve this by having more helping hand,
I'm sure we can try to call for more people to help -- that's a possible
solution to this issue.

> > 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 understand. I, too, prefer productive things over tedious tasks.

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

So your point here is that you would like to have all branches manage by
same person so that their quality are all the same because they always
have the same set of backports, or at least all patches are considered
with same standard.

This is understandable but not always applicable. As you noted, when you
backport stuff you also consider the difficulty and risk of backport.
So in the end even if there is only you who manage all the trees they
will still have different sets of backports. I don't think there is
difference in the end result when you have multiple people maintaining
different trees. True, their criteria for deciding if a patch is worth
backporting are different, but we can perhaps write down a guide to
stable tree maintainers to minimise the differences.

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

I can't say for sure. There is no scientific survey to determine that.

But then the reverse argument applies to longer release cycle, why would
you develop your feature for a project knowing that it would definitely
not be available at all for 9 months and even longer (if its release is
delayed) -- you would miss precious window to release you hardware /
software platform.

Again, I'm not dismissing your argument. But my empirical observation
suggests that some developers just want their features to in _some_
version.

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

No. That was not my intent.

It's just my misinterpretation of constraints. Sorry about that.

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

So what do you mean by "from that point on"? I thought it mean "after
retirement of a particular branch" -- retiring a branch means we don't
care that much about it anymore. That happens no matter what scheme we
use.

Wei.

> Jan

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