Upload rearrangements for Raring

[Colin Watson]

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                                       [cjwatson at ubuntu.com]