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

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

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@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel