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 [cjwat...@ubuntu.com] -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
