Stable Release Update Regression/Build Problem

[Colin Watson]

On Tue, Jun 24, 2008 at 04:49:04PM +0300, Lars Wirzenius wrote:
> ti, 2008-06-24 kello 15:42 +0200, Sebastien Bacher kirjoitti:
> > Right, that makes sense but is not easy to do. Hardy got quite some
> > updates and it's not really easy to try each combination. Testing one
> > update against hardy-updates is not always correct since sometime
> > several packages are moved to updates the same day and that's this
> > combination that should be tested. Having a way to test installability
> > before copying the binaries to updates would be nice though
> 
> Have: foo, foo-updates, foo-proposed.
> 
> Add: foo-updates-new, foo-proposed-failed.
> 
> Procedure: move a package from foo-proposed to foo-updates-new, together
> with all packages it depends on from foo-updates. Test upgrades of each
> package (with, e.g., piuparts). If there are any problems, move the
> packages to foo-proposed-failed, otherwise move them to foo-updates.
> Repeat until foo-updates is empty.
> 
> Would that work?

The idea of adding even more pockets (note that these are currently
hardcoded in Launchpad code!) in order to support a (presumably) mutable
process gives me the willies, I'm afraid. Furthermore, this would
require excessive coordination between testers and archive
administrators, and would result in tests needing to be serialised.

I think we can and should deal with this on the client side.

-- 
Colin Watson                                       [cjwatson at ubuntu.com]