Re: [Xen-devel] [xen 4.6 retrospective] [urgent] rename "freeze" window and make release branch as soon as possible after RC1

[Wei Liu <wei.liu2@xxxxxxxxxx>]

On Wed, Aug 05, 2015 at 10:22:13AM +0100, Lars Kurth wrote:
> This is one item of feedback, which I believe is a quick win for us.
> This is one piece of feedback from a list of items that have during
> the last few weeks been raised with me personally, either during
> face-2-face conversations in a private e-mail thread. See
> http://lists.xenproject.org/archives/html/xen-devel/2015-08/msg00173.html
> <http://lists.xenproject.org/archives/html/xen-devel/2015-08/msg00173.html>
> for information on the retrospective
> 
> 
> = Issue / Observation =
> The name "freeze" window/period - aka the time period from when we
> "feature freeze" until we branch master and/or make the release leads
> some contributors to mistakenly assume that development for the next
> release stops. I saw a few mails on xen-devel@ recently, pointing out
> to contributors that development does not stop during "freeze".
> Chatting to Ian Campbell, he mentioned that he replied to several
> different people who said they were waiting for the tree to reopen.
> Maybe choosing a better name will help.
> 
> In addition, we used to branch master a lot earlier I believe up to
> Xen 4.1 (around RC2 or RC3). At some point we started branching master
> when we release. I do not know why we changed, but it seems we did not
> have any issues branching master around RC2 or RC3. Branching earlier,
> would mean that contributors do not have to carry patches for as long
> as they do now, and the risk of having to rebase patches several times
> is lower.
> 
> = Possible Solution / Improvement =
> Change Terminology:
> * Keep "Feature Freeze" as is
> * Rename "Freeze Window/Period" to "Stabilisation Window/Period" or

Don't really have preference on this.

> * Make clear that "Stabilisation Window/Period" != no development in
> the "Development Update x.y mail template"

+1

> 
> Release Process improvements:
> * Reopen the tree development tree as soon as possible after RC1 (I
> will let you guys figure out the best RC - let's call it RCx)

+1

> * In other words, create the release  branch at RCx
> 
> There could be some optimisations and additional things that may make
> sense:

> * Encourage maintainers/committers to refrain from committing big
> refactoring changes during RCx and the final RC for a release to avoid
> complications if we want to cherry port bug fixes, etc. from master to
> the release branch

+1

> * Committers should be permitted to apply backports to the release
> branch until the actual release rather than putting all the burden on
> the stable maintainer(s)

+1

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


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