[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] RFC: change to 6 months release cycle
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. > > # Proposed release cycle > > > > Aim for 6 months release cycle -- 4 months development period, 2 > > months hardening period. Make two releases per year. > > > > Fixed hard cut-off date, no more freeze exception. Arrange RCs > > immediately after cut-off. > > > > Take into account holiday seasons in US, Europe and China, the two > > cut-off dates are the Fridays in which that last day of March and > > September are in. > > > > Targeted release date is two months after cut-off date. Still, we pick > > a Friday using the same rule. We can also release a bit earlier if > > everything goes well. If we somehow fail to release on time, we eat > > into next development cycle. The next cut-off date will still be > > fixed. > > > > With the proposed scheme, the dates will be: > > > > - 4.7 cut-off date: April 1, 2016 > > - 4.7 release date: June 1, 2016 > > > > - 4.8 cut-off date: September 30, 2016 > > - 4.8 release date: December 2, 2016 > > > > - 4.9 cut-off date: March 31, 2017 > > - 4.9 release date: June 2, 2017 > > > > and it goes on. > > Despite my disagreement to the 6 month cycle, I do agree to > this part of the proposal, i.e. setting a fixed release schedule, > independent of how much the previous release slipped (or got > released early). > Any cycle that is not denominator of 12 is going to eventually collide with holiday seasons. That's bad IMHO, but with adequate planning the impact can be minimised. Wei. > Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |