It also seems that several of the dapper to edgy upgrade problems are caused by the use of Automatix; a tool to perform common customisations to Ubuntu, such as replace the pre-installed software with alternatives and install packages that Ubuntu is unable to pre-install due to patent or other legal issues.

Henrink has a few good points about this, however I feel that it’s also important to remember that the Ubuntu community does not only consist of the core developers.

Automatix, and its like, are by their very definition, tools to reduce the amount of your system that the core developers will support. The default set of installed packages is not arbitrary, and one may be selected over your preferred solution simply because we do not have the expertise in the team to deal with the other, or even because the other is not supported upstream!

We therefore rely on the wider community to take ownership of these packages, and support them within the community structure.

Support, in the development sense, doesn’t just consist of security updates either; it also consists of keeping the software up to date, fixing bugs, and most importantly of all; testing it before we release.

The right approach to making sure that Automatix users are not bitten again during the edgy to feisty upgrade in 6 months time is for members of the community to come together and form a team to support it. The existing Automatix team in Launchpad is probably a good start.

One of the goals of this team should be to make sure that throughout feisty’s development cycle, upgrading from an edgy box with Automatix installed works flawlessly. Where it doesn’t, they should take effort to ensure that useful bugs are filed (e.g. “foo 1.1-2 contains same file as bar 1.0-1 but neither Replaces nor Conflicts it”) so that the problems can be fixed.

Likewise where community members suggest that a user install software from outside the main component, or even outside the Ubuntu repository entirely, they should keep in mind that they’re likely to cause that user problems when it’s time for upgrade.

If you’re running a repository of your own right now, have you considered that you need to start testing upgrades from edgy with your packages installed to feisty? Testing when feisty releases is too late!

It seems that some people with heavily customised Ubuntu installations have had problems upgrading from dapper to edgy. While we do test upgrades as much as we can, there’s no way to test every possible permutation, so problems do creep in.

Here’s a checklist to perform before upgrading to minimise any problems you might have:

• Make sure you have the ubuntu-minimal and ubuntu-desktop packages installed (Kubuntu, Xubuntu, etc. should use the appropriate meta-packages for their distribution). This may require removing some replacement programs you have installed, but you can always put those back after the upgrade process.
• Check for any locally installed packages, you can use aptitude search '~i!~Oubuntu' to get a list of them. Some of these may cause conflicts with the upgrade process, it may be worth removing them and putting them back after the upgrade.
• If you have manually installed any software from upstream, and not used Ubuntu packages (especially the Nvidia or ATI binary drivers), revert those to the Ubuntu-provided versions before upgrading.
• Use the update manager, as described in the release notes, and not apt-get dist-upgrade. While the latter may work eventually, it will require more manual tinkering than the automatic upgrader.

If, after taking all of these precautions, your upgrade still fails; please file a bug report, and try to include as much information as possible. Provide the list of packages that failed, and if possible the error message provided by them. Provide /var/log/dpkg.log and the files in /var/log/dist-upgrade.

Now that Ubuntu 6.10 (“The Edgy Eft”) has been released, we’re starting to see reviews of it; while largely positive, one common theme is that Edgy isn’t quite as edgy as people were expecting.

Mark’s original announcement is certainly the likely reason for this expectation. In it he set the scene for a bold, brash, bleeding edge release to counter the boring dapper release.

Unfortunately, the simple truth is that reality set in. When planning the release schedule for edgy, we realised that if we wanted to get back to our original six-monthly release schedule, we were only going to have four months in which to develop it.

That’s still enough time to throw everything to the wind, and shove out a “release” at the last moment when the CD happens to be installable. It’d be edgy in the extreme sense.

Unfortunately while exciting, we felt that such a release would ruin Ubuntu’s reputation. It’d be a release that, for all intents and purposes, would only be interesting to Ubuntu developers.

Mark has already touched on this in his blog, citing a conversation he had with Matt (the Ubuntu CTO). Especially noteworthy is the mention that the kinds of itches that developers get are not the same as those users get. We get itches because the installer still relies on devfs-style paths, or because it’s not possible to boot the system without race-conditions. None of these things are noticeable to the end-user.

We’re drawing up the list of topics to be discussed at UDS Mountain View in two weeks time, this is as good a guide as any for what we’re thinking about for feisty, the next release. At the end of that summit, we’ll have a list of approved specifications, assigned to developers throughout the community for implementation in the feisty schedule.

Obviously some of those won’t make it due to time constraints, but the best thing about a six-monthly release cycle is that they’re not delayed for long.