MOTU todo list

[Michael Vogt]

Thanks Daniel for your CC on this :)

On Wed, Nov 01, 2006 at 09:46:02AM +0100, Daniel Holbach wrote:
> Am Dienstag, den 31.10.2006, 23:01 -0500 schrieb Daniel T. Chen:
> > Jordan Mantha wrote:
> > > Anything else we should take care of soonish? I'd like MOTU to get
> > > feisty with Feisty and rock the user community with the most stable,
> > > up-to-date, and usable Universe yet. Starting the development cycle
> > > right will help a lot, IMO.
> > 
> > Reading Scott's comments[0] regarding dist-upgrading led me to revisit
> > something we've been neglecting: We should plan a testing scheme for
> > universe dist-upgrades. Granted we're already doing this from revision
> > to revision, but William's and Michael's efforts in Edgy have reiterated
> > just how imperative it is that we strive for smooth dist-upgrades. For
> > Feisty, although our primary upgrade path will be Edgy->Feisty, there's
> > no reason we shouldn't at least attempt Dapper->Feisty, too.
[..]
> I talked to Michael about dist-upgrade testing and we had some ideas
> involving popcon data in simulating release upgrades.
> 
> https://features.launchpad.net/distros/ubuntu/+spec/auto-dist-upgrade-testing/
> https://features.launchpad.net/distros/ubuntu/+spec/dist-upgrader-fixes
> 
> 
> It'd be really cool to see people jump in there and get release upgrades
> tested early in the game so we can get packages fixed before release.

We plan to do more (and better) automatic testing for feisty, this
will also include universe to a certain extend. 

But it seems to me like we also need a easier way to test selected
upgrades. I was thinking of a application in the spirit of pbuilder
that can be used to simulate a upgrade. It would be based on the
current ReleaseUpgrader and run a upgrade in a chroot. This way it
would be easy for each MOTUs to test their favorite package for
unreadability. We may even include a "simulate upgrade of my current
system" to see if that would work/fail.

We still need testing on real HW to catch problems like HW regressions
(we had some in edgy unfortunately), but with this sort of upgrade
testing we can at least catch postinst problems or file overwrite
issues (and unclean dependency decissions).

Cheers,
 Michael