Freeze next week?

[Kate Stewart]

On Thu, 2012-07-12 at 17:07 +0100, Colin Watson wrote:
> 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?

We usually end up soft-freezing from Monday at 2100 until Thursday when
we ship.   Most of the churn happens between Monday 2100 and Wednesday
2100 - so how about that as the window here?   That will give a 2 day
test?

Would rather this be done sooner than later, so we can start to use this
capability going forward.   Anyone see anyreasons why not to try this
next monday?  July 16 -> July 18 th?

Thanks for all your hard work on getting this ready.  :)

Kate