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)
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
