Re: [RFC] Tweaking the release process for Xen 4.6

[Dario Faggioli <dario.faggioli@citrix.com>]

[-- Attachment #1.1: Type: text/plain, Size: 3173 bytes --]

On Tue, 2015-02-10 at 11:11 -0500, George Dunlap wrote:
> On Tue, Feb 10, 2015 at 10:04 AM, Wei Liu <wei.liu2@citrix.com> wrote:

> > # Scrapping soft freeze
> >
> > I think existing model (development + freeze) works well in general,
> > but it would be better if we can shorten the time frame a bit, or try
> > harder to stick to the 9 months promise.
> >
> > I would like to propose a tweak: scrap the soft freeze. The soft freeze
> > is used to allow features posted during development window to get merged
> > in time for a certain release. However this practice leads to longer
> > freeze period (new features means more testing, hence longer freeze).
> >
> > If we scrap the soft freeze, there are several pros:
> >
> > 1. We only need to harden existing features in freeze. That would
> >    probably shorten the time needed for freeze, or at least keep
> >    everything within 3 months time frame.
> >
> > 2. Contributors with big features to upstream would not need to rebase
> >    aggressively because they don't need to worry about features that
> >    go in between soft freeze and hard freeze.
> >
> > 3. Contributors can accelerate their upstreaming effort by benefiting
> >    from the possible shorter freeze time.
> >
> > I think this tweaked process can help make the development flow
> > smoother. We release in a more timely manner and contributors have less
> > work to do.
> >
> > The cons are of course we have shorter time in freeze and lead to
> > possible less harden code. But I don't really see that as a big
> > issue, given that we a) we still set aside 3 months for it, b) we
> > only need to harden existing code.
> >
> > What contributors need to do with this changed process: develop and
> > upstream features as usual in development window, but no more arguing
> > whether a feature should go in after freeze.
> >
> > What maintainers / committers need to do with this changed process:
> > "business as usual" during development window, no more new feature
> > after freeze, only bug fixes can go in.
> >
> > # Proposed Xen 4.6 time frame
> >
> > With the above proposal in mind, here is my proposed time frame for
> > Xen 4.6 release:
> >
> >   Development start: 6  Jan 2015
> >   Feature freeze:    10 Jul 2015
> >   Release date:      9  Oct 2015 (could release earlier)
> >
> > Note that the release date is not a goal. It is more like a deadline
> > we try to keep up with. We might be well able to release earlier if
> > everything is in good shape.
> >
> > Any thought on this tweaked process? Comments are welcome.
> 
> I think it's certainly worth a try.
> 
It does indeed, IMHO.

One thing that we did, at least for the past two cycles, was to have two
distinct events:
 - feature freeze, starting from which no more new features where 
   accepted
 - code freeze, starting from which no more code, apart from bug fixes, 
   where accepted

Genuine question: do we still want this distinction? Maybe getting rid
of it, or cutting it as short as possible/practical could help achieve
what you're after (i.e., less time in freeze)?

Regards,
Dario


[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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