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

[Wei Liu <wei.liu2@xxxxxxxxxx>]

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?

Wei.

> Jan

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