Freeze next week?

[Colin Watson]

Hopefully the subject got people's attention. :-)  I don't mean quite
what you might think, though.

I've been working on a new upload queue management API in Launchpad, and
it's almost feature-complete; the next Launchpad deployment will
probably contain everything needed to make the API client a full
replacement for the old script that archive admins used to run by sshing
to a privileged server.  I would like to remove the old queue script
soon so that we don't have two implementations of essentially the same
thing lying around and confusing people.

However, I also need to be careful about this.  In the past, we have
sometimes found that accepting uploads through the Launchpad web UI has
timed out, and we've had to fall back to using the non-time-limited
script.  This tended to particularly affect uploads that closed several
bugs with large numbers of subscribers and/or duplicates.  I *think* the
API client should be a bit less susceptible to this because the cost of
rendering the queue view again won't be included in the timeout, but
it's possible I'm wrong and that further work is needed.  It would be
bad to discover during beta or final freeze that we were unable to
accept an important fix!

I'd therefore like to do a real-world test of a freeze at some point
when it doesn't matter too much.  We would move quantal into the
"Pre-release Freeze" state, meaning that all uploads to quantal and
quantal-proposed would land in the Unapproved queue.  However, we
wouldn't review packages in the queue manually, but any archive admin
would be able to accept them as soon as they noticed them, preferably
using the API client.  We have enough archive admins in a variety of
timezones that we should be able to keep disruption to a minimum.

I'm not sure how long it would take to achieve a reasonable level of
assurance.  I doubt a day would be enough, but people's patience would
probably start to wear thin after a week, so probably something in
between.  I'd like to make sure that we've accepted a few reasonably
large sets of changes in the relevant period.

Note that uploads to -proposed aren't a terribly good test of this,
because they don't close bugs until they're copied to the release pocket
(and the copy goes through a separate job queue that has a much more
generous timeout); so we can't really test this with SRUs and a
sufficiently rigorous test will probably involve people not uploading to
quantal-proposed when they otherwise might have done.  Similarly, while
kernel uploads would ordinarily be good sources of large numbers of bug
closures, they're only any use for this if they go straight to quantal
rather than going through the canonical-kernel-team PPA or
quantal-proposed.

Any thoughts?

-- 
Colin Watson                                       [cjwatson at ubuntu.com]