Releasing Alphas and Betas without "freezing"
stgraber at ubuntu.com
Fri Jun 15 14:28:55 UTC 2012
On 06/15/2012 10:12 AM, Rick Spencer wrote:
> Hello all,
> 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
> and automated.
> Cheers, Rick
We certainly want to allow people to upload stuff to -proposed during a
milestone week, but I don't agree that we should automatically copy from
-proposed to the release pocket during a milestone week.
We usually try to release all our images with the same versions of the
packages, considering it takes us hours to rebuild everything, having
seeded packages land during that time, will lead to images having
different version of packages.
As for what happened with Alpha 1, we simply asked everyone to upload
their packages to -proposed and then cherry picked the packages we
actually needed for the release from -proposed and copied them into the
release pocket before rebuilding the images (we did that 3 times).
As I understand it, the plan going forward is to have the release pocket
be an alias of -proposed on upload, so that everything always lands into
After something lands in -proposed, is properly built and passes
whatever other criteria we'll have, the package will be automatically
copied to the release pocket.
That last part (copy to the release pocket) would be what we'd block
during a milestone week for any package that's seeded. These would be
copied on a case by case basis by the release team and the images
That'd essentially allow any non-seeded package to still flow to the
release pocket and be available for everyone.
All the others will be available for people running with -proposed
enabled or will be available when we manually copy them to the release
pocket or right after we release the milestone and we copy everything
left in -proposed to the release pocket.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 900 bytes
Desc: OpenPGP digital signature
More information about the ubuntu-devel