Ubuntu quality control (or: Why I'm recommending people not upgrade to Ubuntu 8.04 yet)
Obviously I’m a fan of Ubuntu as I run it on my laptop, desktop, and even a number of servers (both physical and virtual). That can’t deter me from being critical of the Hardy Heron release. I can sympathize with the difficulty of the task of releasing a stable OS every 6 months. Perhaps that is simply an unrealistic goal. Or perhaps this is just a stage of growing pains for a new OS. I watched launchpad during the beta testing of Hardy Heron and saw the number of bugs being reported. Having a new bug report every 2-3 minutes accumulates a large number of reports for people to examine and remedy. And I suspect that’s where Canonical will have to increase its effort. The success is that so many people are contributing bug reports. The failure is that so few have been resolved, including some fairly critical ones that I will mention in detail.
The most critical bug that I’m aware of that was not resolved is bug #32906 which causes sudo to stop functioning if the system’s hostname is not in /etc/hosts. Such a requirement is new. The desktop I’m using at this moment does not have any such entry in /etc/hosts and works correctly. I’d classify this as a release critical bug because it will cause large numbers of systems to stop working properly following an upgrade.
Another release-critical bug is bug #218126 which reports that Xen guest domains running Hardy have no networking (or broken networking). Until this bug is fixed none of my Ubuntu Gutsy virtual servers (I currently run approximately 20) can be upgraded.
Of the bugs that I feel are important or critical that I have been tracking only 1 of 10 has been fixed. That’s not a respectable rate. The breakdown seems to be in disagreements over the severity of a particular bug. I can understand why Canonical would not want to blindly allow users to set the importance of bugs since their is concern that users will always see the bugs they are experiencing a extremely important. I’m not sure if that would actually be a problem because many users can distinguish between a critical bug and a non-critical one.
However I wonder if a better system might be a set of metrics used to describe a problem. Right now a bug report can be flagged as a security issue. However the 2 bugs above might have security implications but I’d say more importantly they break significant functionality after being upgraded. So having some additional flags users could set to increase their visibility to the community could really help separate critical bugs from more trivial ones. I also think a team should be in place to review bugs where there is contention over the severity of the bug. In the case of the sudo bug the person who has been assigned the bug does not see it as serious or worth addressing despite the fact that it has, is, and will continue to break systems upgrading to Hardy. So in the cases of disagreement a knowledgeable team that can assess the situation accurately and recommend a course of action could be quite helpful.
With some better quality control procedures in place I think Ubuntu could make much better use of the torrent of bug reports received and produce a much better OS. This will be important for Ubuntu to not be seen as releasing products that are unready for production use. I am subscribed to numerous bug reports that I hope will get attention and resolution now that Hardy has been released. At the point they are I hope to happily and enthusiastically recommend people upgrade to Ubuntu 8.04 (Hardy Heron).
Sudo bug
I've run into the sudo bug where my hosts file got changed and sudo wouldn't work. All I did was go into the network manager, select my network connection and edit my host file through there. Gave me back my sudo every time.
Yes it's not a difficult bug for a user to fix
My position is simply that it shouldn't need fixing by the user in the first place. This particular issue will be noticed more quickly by the more savvy users who rely on sudo regularly. These users are quite capable of fixing the problem. However, it may affect a much larger set of users, perhaps everyone who upgrades, or who has upgraded from before whichever release first put the hostname into the /etc/hosts file, as well as anyone who has changed their hostname. That's a large number of users who won't even know they have a problem until they try their next sudo command. That could be a very large number of users with complaints for a long time.
It seems to me that the wiser course of action is, and was, to simply fix the bug. There are already over 25 reports of this bug on ubuntuforums. Isn't it easier to just fix the problem than to have to explain to countless users how they can fix the problem using network manager, gksudo, or recovery mode?
Given that there is no need to do a hostname lookup when someone has permission to ALL computers this seems well worth taking the time to fix in order to save the frustration it will cause users.
Wasn't commenting on the bug, just your fix
I agree it's a bug. I agree it's aggravating. And I agree it should be fixed. I was just pointing out that your solution was more work than was needed.
I quote from the second paragraph the 2nd last sentence which is discussing the sudo bug:
"To fix the problem requires the use to enter recovery mode or to boot from a rescue cd."
By giving the most complicated solution to a problem it seems to me that you are deliberately putting a negative spin on the situation.
Also, as I said, I agree it should and needs to be fixed. You say isn't it easier to fix it rather then give a temporary solution? In the long run yah but until it IS fixed I say make the temporary solution easier until it is fixed rather than breaking out recovery cds and rebooting.
I apologize for misreading your comment
> By giving the most complicated solution to a problem it seems to me that you are deliberately putting a negative spin on the situation.
I actually just posted the wrong draft of this article. I appreciate that you pointing out that error.
At this point I'm not sure it should be edited or updated at this point.I've tried to make it clear in the comments that there are simpler solutions. I certainly wasn't trying to be negative. This was meant to be a rumination on how to improve the system.> In the long run yah but until it IS fixed I say make the temporary solution easier until it is fixed rather than breaking out recovery cds and rebooting.
Yes, since gksudo, and maybe kdesudo (that's worth testing) are unaffected it's much simpler to use one of them to alter the hosts file, or to use Network Manager which has root permissions. However, many of the articles giving advice on this bug do recommend using rescue mode, or even a rescue cd, so that is a path a lot of users will end up taking depending on where they get their help.
I've decided to remove that text from the article rather than replace it so the article reads better. But in the interest of transparency here's what was taken out:
To fix the problem requires the use to enter recovery mode or to boot from a rescue cd. This is not a behavior one wants in an upgrade, to have to rescue the system afterward.Not a bug
I would say this is not a bug at all as you've gotten your system into an inconsistent state. From what I can tell gutsy was the only version that allowed this, I know dapper did not. Hardy actually does allow this if you do a clean install but it complains loudly. It doesn't work on upgrades because it is not allowed to mess with your /etc/sudoers file.
I'm sorry but you are mistaken
No version of Ubuntu (or Debian) has ever had sudo fail for not having the hostname in the /etc/hosts file. I have 2 systems that have been upgraded through every release of Ubuntu without ever having sudo fail due to the lack of a hosts file entry.
Now one could argue that this is a necessary change in behavior. I haven't seen anyone do so and would really appreciate if anyone has any links to someone who has. Of course, even in that case this is still a bug. If this was a necessary change then the correct course of action would have been to ensure that the /etc/hosts file was correct and correct it if it was not.
Under no circumstance should an upgrade break sudo or any other required functionality. If it was working fine before an upgrade, it should work fine afterward. If it does not that constitutes a bug as far as I'm concerned.
Comments
I too have encountered a few of the 8.04 bugs, which have soured me on Ubuntu.
I ran into the /etc/hosts snag, bug, faux pas, whatever you wish to call it. I also hit the networking bug, where any manual configuration just blows it out of the water. Then there's the wireless Broadcom bug. This worked great in 7.10 and again, blown out of the water in 8.04, great job Canonical.
It seems to me that in every release of Ubuntu, something that worked in the previous version, quits working in the new version. This simply is not acceptable.
Most, if not all the bugs, had been reported during the betas and there was time to fix them. Seemingly, a great majority have been ignored, or rushed to fix, but still broken.
Yes, it can be frustrating
I try to remember that one of the great things about Ubuntu is the openness of the project. We'll never know how many bugs are reported to Apple and Microsoft that don't get fixed by the initial release of their operating systems. The sheer number of bug reports coming in to Launchpad is going to create a challenge to identifying important and critical bugs. However if this challenge is met, and I believe it can be, I think the quality of the Ubuntu releases could improve dramatically. But I agree that right now the quality control is not what it could be, and that will discourage and frustrate users who see things working fine before a release but find them broken after an upgrade.
Another idea might be some sort of tool that scans for potential upgrade issues before an upgrade proceeds. Warning users about parts of a system that could break on upgrade would be better than nothing. Though I think the goal should be an upgrade that breaks as little as possible. But with Hardy I think about users who rely on Firefox extensions that haven't been ported to Firefox 3. Perhaps they should be warned prior to upgrade about the potential problems and offered suggestions on how to avoid them.
Never has been, never will be
This post reads exactly like any number of other posts after every single distro release ever made.
Never has been, never will be advisable to upgrade to a new version the day it comes out. Wait a month or two. It even seems fashionable these days to crow about how someone's running Ubuntu current+1 Beta 4 and it's perfectly stable. Yeah, sure, but why. Linux and Ubuntu are already so good these days that the new features in a given release are hardly going to turn your world around. Let the itchy folk install it the day it comes out and be the real beta testers. Doesn't even matter how great the distro's QC is. There will always be critical bugs that don't even show up until after release. Always.
Perhaps I haven't made my point clear
While I agree that there will always be bugs that show up after a release and that it may often be prudent to wait before upgrading, this article was specifically trying to address what to do about the large number of bugs that have been reported but remain unfixed by the release date.
This is I think what separates this release from similar situations in the past. Ubuntu has been remarkably successful at getting large numbers of bug reports during the alpha and beta stages. I ran several Ubuntu 8.04 virtual machines to test issues I was concerned with. I reported bugs or added to existing bug reports with my findings. Now having put all of that volunteer work in I'm trying to address whether it was worth my time to do so since very few of the bugs I worked on were fixed. That's discouraging to myself and perhaps to others that have put in that kind of work. So my question for the larger community is how to improve this situation. I've offered my thoughts but I'd appreciate hearing others.