why we freeze for alpha milestones [was, Re: Accepted: evince 2.23.5-0ubuntu1 (source)]

[Steve Langasek]

On Thu, Jul 24, 2008 at 09:29:51AM +0200, Sebastien Bacher wrote:
> > The reason I bring this up is because evince is current breaking the
> > Xubuntu sysfs build. Although your upload isn't the cause, it did

(s/sysfs/livefs/)

> > cause me to spend several minutes digging around to see if it was
> > (thank your lucky stars it isn't because I hear the wrath of of
> > slangasek is second only to the wrath of vorlon in intensity).

> why would a software update break CD builds? there is a new GNOME
> available this week and we can't stop packaging new versions only
> because it could eventually break a CD build,

While you shouldn't stop packaging the new versions during a soft freeze,
the intent of the soft freeze is that you shouldn't /upload/ them until
after the alpha milestone is out except when the upload is needed to clear
milestone-blocking bugs.  The change from a hard archive freeze to a soft
freeze for alpha milestones was never intended to change the character of
what was accepted during the freeze, just to distribute the decision-making
process better so that the release team would be less of a bottleneck for
package accepts during this time.

As to "Why would a software update break CD builds", I'm not sure if this is
a rhetorical question or not, so I'll answer it for the benefit of anyone
who doesn't think that it is. :-)  There are lots of ways a software update
will break CD builds even if the update itself is not buggy:

- pushing the CDs past the size limit, due to code growth or new library
  dependencies (evince did pull in a new library here, though the size
  change was inconsequential)
- arch: any / arch: all version skew that causes packages to be
  uninstallable on !i386 archs if we're trying to build CDs after amd64 has
  finished building but before i386 has, or vice-versa
- pulling in dependencies that have not yet been promoted to the right
  archive component

These are the kinds of problems that an archive freeze needs to prevent
while we're building CDs for a milestone, because each of them will cost us
a CD build iteration to identify and fix, which takes time.

It happens that we did have an instance of this last problem during the
alpha-3 soft freeze, which made for a two-hour delay in trying to iterate
CDs.  That's not so much of a delay that I think we need to reevaluate the
use of a soft freeze - we can, and have, easily had that long of a delay
with a hard freeze, just because of release team not being readily available
due to timezones - and in the end it wasn't critical path for ISO building
anyway.  But it is the kind of thing we should be trying to avoid.

> we are usually careful on what is updated and avoid soname changes for
> example, but stopping random applications uploads doesn't really make
> sense there, what is your concern exactly?

While it wasn't a problem in this case, it does concern me if people take
this position towards the milestone freeze.  I fear it will lead to more and
more packages being uploaded during the freeze until we eventually reach the
point where using the soft freeze is no longer saving us time.

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek at ubuntu.com                                     vorlon at debian.org