Open Stack

Hello everyone,

With E4 out of the door, here is some explanation on how we'll
collectively handle the last 5 weeks before release. The idea for each
project is to come up, in the weeks before final release, with a release
candidate that they are happy with. On April 5 we'll release all those
candidates under the common OpenStack 2012.1 "Essex" umbrella. The
sooner we get the final RC, the easier it is for everyone.

To that effect, we created essex-rc1 milestones for each of
{Glance,Nova,Keystone,Horizon}, to which bugs can be targeted. When the
bug list is empty, that means we think we've come up with a potential
release candidate, which we will publish. At the same time, we'll open
Folsom for development.

So if you think a given bug absolutely needs to be fixed before Essex
can come out, make sure it is targeted to essex-rc1. If you can't do
that yourself, ping me or one of the projects drivers to do it for you.

In case release-critical bugs are found after the RC1 is published,
we'll start another RC cycle (essex-rc2), etc. As we get closer to final
release date, we get more picky as to whether a bug is indeed
release-critical, or just a known issue we'll document and have to live
with. Expect bugs to be removed from the RC list.

Starting now, core reviewers should apply extra caution in their
reviews. New features are forbidden, and bugfixes that are likely to
introduce a regression should be avoided (a known bug is often better
than an unknown regression). In order to minimize the impact for
testers, technical writers, translators and packagers, bugfixes that
change the DB schema, add files, add configuration options, add
dependencies or add new messages should also be avoided if possible.

In a couple of weeks, we'll switch to extreme caution, and only targeted
bugs will be allowed in the release branch.

PS: Swift will use 1.4.7 as their Essex release candidate, so expect
conservative changes in that version.

Happy testing !

-- 
Thierry Carrez (ttx)
Release Manager, OpenStack