I'm still frantically putting the bits together for this, but it's now far enough along that I feel comfortable saying we're going to be doing it for Raring, so:
In the continuing cause of trying to make the development series more usable at all times, not just around milestones, I'm rearranging the way our uploads are processed. For Raring, all uploads will go to raring-proposed, and a modified instance of "britney" (the software that handles migration from Debian unstable to testing) will copy them to raring when they've been built everywhere and do not reduce the count of installable packages in the archive. The intent of this is to come as close as possible to eliminating transient uninstallability problems in the development release. We probably won't get all the way there. It will still be possible for uninstallability to be introduced by copies not all happening in a single publisher run, transient uninstallability in -proposed will still affect package builds, and it won't catch all cases where sets of packages that used to be simultaneously installable stop being so (the general case of this is NP-complete anyway). Even with these limitations, though, it should make things a lot better. Things that Debian does that we will *not* do include: * Imposing a delay on uploads. Packages are required to age for 10 days (or less depending on the urgency field) before they're allowed to enter testing. We won't be doing that, because that would divide our development testing community into two; the object of this exercise is simply to provide a repository on which a small number of automatic tests can be performed before pushing uploads into the development series. It remains to be seen how much of a delay will be introduced by this change, but I'm hoping we can keep it down to no more than one or maybe two publisher cycles (half an hour each). * Considering the number of release-critical bugs against different versions. For one thing, Launchpad's bug tracking system is missing some fundamental features that would make this a lot more practical. For another, it follows from not imposing a delay that people wouldn't generally have time to file RC bugs against the proposed version. * Encouraging people to run the proposed versions of packages (Debian's "unstable" branch). This makes sense for Debian because testing and unstable are often quite divergent; but we will consider any divergence as short-lived and purely for the purpose of automatic testing, and will be trying to keep the divergence as small as possible. The sort of automatic tests that might fail are the ones where you probably wouldn't want to run failing versions anyway. * Using the proposed branch as a place for new versions of packages that would fail freeze criteria. We have PPAs for that; raring-proposed is still ultimately for things targeted at raring. I'm currently working on Launchpad changes in support of this. The main one is arranging to redirect all raring uploads to raring-proposed instead (#1068071), and I expect that for most uploaders this will be almost transparent. How to handle copies is a tougher question, because copies will be used internally by the proposed-to-release migration process so we can't just redirect them all, but we also want syncpackage to behave reasonably. This may end up involving SRUs for syncpackage, but in the meantime 'syncpackage -r raring-proposed' should do the right thing. If any of this goes wrong, we should be able to turn it all off again very easily by disabling a cron job and changing a field in Launchpad. This will probably take at least another couple of days, but I hope to have it all more or less working before UDS. Cheers, -- Colin Watson [[email protected]] -- ubuntu-devel mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
