Staging area for hardy-proposed ?

[Steve Langasek]

Hi Michael,

On Wed, Jun 04, 2008 at 05:28:20PM +0200, Michael Vogt wrote:

> I would like to discuss if we should have a staging area for
> hardy-proposed for updates that need to go in together at the same
> time.

> With hardy we have more changes than in previous releases and more
> packages like openoffice (with its translations), firefox (with
> xulrunner), compiz (with its plugins) and of course the kernel that
> require multiple package to enter -proposed at the same time for a
> flawless upgrade.

> It would make the life of users with -proposed enabled a lot
> easier. This also affects upgrade, for example bug #235583 is the
> result of users with gutsy-proposed who try to upgrade to hardy. When
> hardy-proposed is inconsitent the release upgrader will refuse the
> upgrade because it would have to remove translation packages
> (something that it refuses by default). 

(Is 235583 the right bug number?)

> I discussed this briefly with the launchpad soyuz team and one
> possible way would be to have a trusted private PPA that is used for
> the staging and then the results are copied over to
> hardy-proposed. This will put additional work on the archive-admins
> though (also I think we could script a lot of the consistency checks).

> What do you think?

This feels to me like it would be solving the wrong problem, fundamentally. 
I fear that most users who have -proposed configured generally have it
configured for the wrong reasons, and that we really need to have better
support for cherry-picking fixes from -proposed so that it can be used as
the staging area for -updates that it was intended to be.

Ideally, I believe we would be able to automatically handle apt pinning on
behalf of the user so that if -proposed is enabled, packages are not
installed from it unless manually selected, with preference given to lower
package versions in $suite{,-security,-updates}.  With an adequate
implementation in apt, it seems to me that the update-manager UI
requirements are simple enough - display a list of "proposed updates", which
are not selected for installation by default unless a -proposed version of
the package is already installed.

Then, setting aside the question of whether -proposed should remain enabled
across upgrades (and I can see a strong argument for disabling it),
temporary uninstallabilities in -proposed would regardless not be an issue
for release upgrades, allowing unencumbered use of -proposed as a sandbox.

Now arguably, this would reduce the amount of testing received by packages
in -proposed because users would have to explicitly opt in for each package;
but on the other hand, it would make enabling -proposed to test packages a
much safer proposition in the first place, letting users easily test only
those packages that are of direct interest without worrying about unrelated
regressions.

Better tools to indicate when an update will render packages uninstallable
would be worthwhile in their own right, though, whether they actually end up
used for ppa->proposed staging, or for staging of -security/-updates.

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek at ubuntu.com                                     vorlon at debian.org