Re: [Xen-devel] RFC: change to 6 months release cycle

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 05.10.15 at 15:51, <wei.liu2@xxxxxxxxxx> wrote:
> On Mon, Oct 05, 2015 at 07:31:05AM -0600, Jan Beulich wrote:
>> >>> On 05.10.15 at 14:52, <wei.liu2@xxxxxxxxxx> wrote:
>> > On Mon, Oct 05, 2015 at 05:37:32AM -0600, Jan Beulich wrote:
>> >> >>> On 05.10.15 at 13:23, <wei.liu2@xxxxxxxxxx> wrote:
>> >> > On Mon, Oct 05, 2015 at 05:04:19AM -0600, Jan Beulich wrote:
>> >> >> >>> On 02.10.15 at 19:43, <wei.liu2@xxxxxxxxxx> wrote:
>> >> >> > The main objection from previous discussion seems to be that "shorter
>> >> >> > release cycle creates burdens for downstream projects". I couldn't
>> >> >> > quite get the idea, but I think we can figure out a way to sort that
>> >> >> > out once we know what exactly the burdens are.
>> >> >> 
>> >> >> I don't recall it that way. My main objection remains the resulting
>> >> >> higher burden of maintaining stable trees. Right now, most of the
>> >> >> time we have two trees to maintain. A 6-month release cycle means
>> >> >> three of them (shortening the time we maintain those trees doesn't
>> >> >> seem a viable option to me).
>> >> >> 
>> >> >> Similar considerations apply to security maintenance of older trees.
>> >> >> 
>> >> > 
>> >> > Sorry, my memory failed me. So the major objection is the maintenance
>> >> > burden of stable releases.
>> >> > 
>> >> > What do you consider "must-have"s when it comes to stable releases?
>> >> > 
>> >> > The only "must-have" to me is that we need stable releases. This
>> >> > doesn't preclude us from exploring other options to achieve that goal.
>> >> > 
>> >> > Just to throw around some ideas: we can have more stable tree
>> >> > maintainers, we can pick a stable tree every X releases etc etc.
>> >> 
>> >> Both points we have been discussing before:
>> >> 
>> >> More stable tree maintainers means higher total cost (there's certainly
>> >> some amortization if a single person maintains the same [parts of the]
>> >> tree everywhere), plus an increased chance for certain backports
>> >> ending up in only some of the trees (clearly bad if a newer one retains
>> >> a bug that got fixed in an older one).
>> >> 
>> >> Picking a release (or a longer term maintained one) results in some
>> >> releases being "better" than others.
>> >> 
>> > 
>> > If this is not an option for you. We can work on a technical solution
>> > for having more stable release maintainers. 
>> > 
>> > For example, we create an email alias for stable backport requests,
>> > subscribe every stable tree maintainers to that list. This should make
>> > it impossible to miss patches. The rest is subject to individual stable
>> > tree maintainers' discretion if a certain patch goes in or not. This has
>> > worked and scaled reasonably well for Linux.
>> 
>> How many stable backport requests have you seen over the last
>> couple of years, perhaps excluding ones in reply to stable tree
>> release preparation polls? Take that number and compare to the
>> one of backports that actually went into the stable trees...
>> 
> 
> Sorry, I don't quite follow the point you're trying to make. 
> 
> Excluding replies to preparation polls, the only way of requesting a
> backport is to do it in patch, which is very informal nowadays and easy
> to get lost in huge amount of emails.
> 
> If you're saying the only a low number of backport requests make it to
> stable trees, doesn't that mean we have issues here? Either maintainers
> are overloaded hence forgetting things, or we don't have a good way of
> tracking requests even if people are willing to help. Or it could be the
> combination of both issues. The first issue can be addressed with more
> maintainers, the second issues can be addressed with a formal way of
> requesting and keeping track of backports.
> 
> If your point is "there isn't that many backport requests", doesn't it
> make the argument of "having too big burden for maintaining more stable
> releases" moot?

My point was that I'm trying to make sure that relevant changes fine
their way into the stable tree without explicit backport requests. I.e.
I don't think we have an issue now, but this model imo wouldn't work
well with multiple stable tree maintainers.

Jan

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