Releasing Alphas and Betas without "freezing"
rick.spencer at canonical.com
Fri Jun 15 14:12:22 UTC 2012
At UDS I had some "hallway discussions" about why we freeze for Alphas
and Betas, and the fact that I think it is time to drop this practice
and rather focus on making Ubuntu good quality each day. Sadly, there
was no session on this, thus this email to this list for discussion.
I think it is time drop our "Freeze" practices for the alphas and
betas. Here is my reasoning:
1. We are developing tools that allow us to efficiently use -proposed
in a way that will ensure we will not have partially built or
incompatible components in the release pocket ... ever. Including days
we release Alphas and Betas:
These blueprints tools to ensure that Ubuntu is not uninstallable or
have other problems due to partially built components and such:
I have been assured that the tools necessary to automate the work of
moving components correctly from -proposed to the release will be
ready before Alpha 2.
2. We are investing heavily in the daily quality of Ubuntu. For example ...
We run the same automated tests on an alpha as we run on a daily:
We tend to archive issues each day:
We ran all the manual ISO tests *before* we released Alpha 1, and we
have the capability of doing this at will:
In short, freezing the archive before an alpha or beta should not
actually be contributing to either ensuring the installability of
Ubuntu images or ensuring the quality of these images. This implies,
therefore, that all the work around freezing, and all the productivity
lost during a freeze, actually subtracts from the quality of Ubuntu by
reducing our overall velocity for both features and bug fixes, since
every day the image is good quality, and Alpha or Beta should be just
that day's image tagged appropriately.
AIUI, A1 was delivered in such a manner, though without the tooling to
ensure that moving from -proposed to the release pocket was efficient
More information about the ubuntu-devel