>>> On 05.10.15 at 13:23, <wei.l...@citrix.com> wrote: > On Mon, Oct 05, 2015 at 05:04:19AM -0600, Jan Beulich wrote: >> >>> On 02.10.15 at 19:43, <wei.l...@citrix.com> 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. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
