Not That Edgy
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.
I’m glad that you guys decided the route that you did with the Edgy release. I’ve just recently switched over from XP for good now and I may have had to switch back if the release wasn’t stable.
Not Edgy? How about overturning 30 years of UNIX history!
Ahem. Anyway, looking at the specs the sabdfl is pushing at MTV, I think feisty may be rather more edgy than edgy. BerylByDefault, eek.
Also, please make wireless rock, kthxbye
I said it almost the moment I read Mark’s release: He was “promising to impose (almost
zero from-the-top requirements for Edgy” not because he wanted “cutting edge, perhaps bleeding edge, brand new code and infrastructure,” but because there wasn’t enough time to make significant improvements. You’ll note that of the improvements hinted at in the release, none really made it to main.
And really, that’s fine by me. I’d rather upgrade from Dapper to a newer but marginally better Edgy than watch Edgy cut things from the safety of Dapper, knowing that in six months times things will be even better. It may be the case that many of the low lying fruit have been picked. In such a case, we should expect diminishing returns with the current six months from start to finish plan.
That said, if you’re subtly digging for MTV topics, I’ve got a few suggestions:
1) security-updates should go live the moment security updates can’t make it to the regular archive.
2) ditch the keyring crap in networkManager (surely I’m not the only one who feels this way). and maybe help fix suspend, hibernate and resume, etc.
3) tabletPC improvements. this one would probably require the starting of a team to evaluate and implement various changes from drivers and middleware tools to alternate themes more suitable for pen input. I’m guessing this one would require me to step up and drive the initiative given how few developers have tablets.
4) Power consumption specs. Maybe send a few kill-a-watts meters to the right people, and drum up some measurements on how to improve battery performance. dropping from 21 to 19 W, while only a 2 watt gain would be close to a 10 percent improvement in battery life.
But now that I think about it, you’ve probably still got your plate full on upstart. Hopefully when you’re much closer to done, you’ll have some sage advice for others on how to plan a large scale, long term project
IMO, it would go along way towards better reviews and less user frustration if there was a page explaining _why_ X or Y didn’t get in. For example, myself I can not really understand why NetworkManager didn’t make it but I’m sure there’s a good reason for that decision…