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

["Jan Beulich" <JBeulich@xxxxxxxx>]

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

Jan


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