[xen 4.6 retrospective] [urgent] rename "freeze" window and make release branch as soon as possible after RC1

[Lars Kurth <lars.kurth.xen@gmail.com>]

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

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 something similar
* Make clear that "Stabilisation Window/Period" != no development in the "Development Update x.y mail template"

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)
* 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
* 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)

[-- Attachment #1.2: Type: text/html, Size: 3055 bytes --]

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

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