On Wed, 5 Aug 2015, 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 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.
+1
Maybe "RC window" ?
> 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.
+1
I would even go as far as recommending maintainers to take patches in
their personal trees while xen-unstable is "frozen". Personally I
already do that for QEMU.
In fact I think that if a tree was always open to check stuff in (it
doesn't matter if the tree is xen-unstable, the maintainer's own git
tree, or a temporary branch somewhere), everybody would be much more
relaxed about releases and code freezes.
> = Possible Solution / Improvement =
> Change Terminology:
> * Keep "Feature Freeze" as is
> * Rename "Freeze Window/Period" to "Stabilisation Window/Period" or something
> similar
+1
> * 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
> * 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@lists.xen.org
http://lists.xen.org/xen-devel
