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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 08.10.15 at 16:23, <wei.liu2@xxxxxxxxxx> wrote:
> On Thu, Oct 08, 2015 at 06:13:27AM -0600, Jan Beulich wrote:
>> >>> On 08.10.15 at 13:10, <wei.liu2@xxxxxxxxxx> wrote:
>> > 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.

Yes and no. The main criteria for me is that 4.<n>.x should never have
a fix that 4.<n+1>.y doesn't have. I.e. (quite naturally I would say) if
I decide to drop a patch due to being too difficult to backport, I'll surely
not re-introduce it on an older branch. Maintaining all branches this is
actually easily enforced: When doing backports, I (again quite naturally)
do them in reverse order of releases, and hence once a patch got
dropped it won't re-appear going further backwards.

And yes, to preempt your respective argument, this can be documented
and people can be told to obey to this rule. But there are cases where
I push back certain desirable, but more risky backports, with the plan to
perhaps apply them once they've seen more testing on unstable or even
in a release. This is quite a bit more cumbersome (but not impossible,
agreed) to coordinate.

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

I'm sure Linux has criteria too. But you know what - people tend to
ignore such when they think they know better (and I can't exclude
myself here).

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

Oh, sorry, "from that point on" was meant to refer to the transition
from ordinary to LTS maintenance (at which point a transfer of
responsibilities seems quite reasonable a possibility).

Jan


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