Am I reading it right as: "we'll fix it in the next release, and then think about fixing it in the release you're actually using"?
That's not too different from the rest of the software world.

Perhaps the problem is really that I had to ask myself whether I fully understood their response. As you said, "a perfect opaque bureaucratic tone"

Did you register a complaint with Canonical?..

Their response to your complaint should be right entertaining.

As I read it, that means that it has to be fixed in the current development branch (what *will be* 8.04) before it can be fixed in 7.10. This makes sense as far as it goes, but I don't think a policy which prevents it being considered a bug in the 7.10 release until it's handled in the development branch is a very *good* policy.

Still, that suggests that as soon as someone gets around to fixing it in their current development branch it can then be considered 'valid' in 7.10, so this could potentially happen very quickly, if you're lucky.

Weird policy, though.

Adam Williamson
Bugmaster, Mandriva

This sounds like such a trivial bug- why not re-compile the darned thing and be done with it? What's the big deal? Especially for the well-funded, hyper-hyped Kumbaya Linux, where they tout their own quality control muchly. That's why I'm so whiny about this one.

**edit**
Akkana Peck writes a better article about this:
http://shallowsky.com/blog/linux/ubuntu-aumix.html

"Ubuntu apparently thinks that users get used to packages not working, and grow to like it. I guess that if you actually fixed packages that you broke, that would be disruptive to users of the stable release."

Adam's post made me realize that the policy may be due to the problems most bug trackers have with tracking the same bug in multiple releases (mentioned in http://www.oreillynet.com/pub/a/network/2005/12/09/do-bug-trackers-all-suck.html)

One of these days, I'm intending to create a Jira plugin to do this all better.

Only Nokia comes close to finding ways to avoid fixing bugs with their Linux OS. There really is IMHO no real reason to file a bug with Ubuntu. Launchpad is a laugh and if you figure it out. Nothing ever gets done about the bugs except buck passing.

"...but I don't think a policy which prevents it being considered a bug in the 7.10 release until it's handled in the development branch is a very *good* policy."

It *is* considered a bug; it's not been declined. What's been declined is the nomination for the current stable release as of this time, and once the fix is in the development branch, the nomination can be reconsidered.

Nominating a bug for a stable release is saying "Hey, everything is ready for this fix to be deployed; it meets the SRU policy criteria, the fix is in the development branch, the patch is attached, the bug reflects everything needed to go ahead, so let's prepare the upload and deploy it NOW". Unless the above are true, the nomination will be declined.

Look at the state of that bug. Where's the patch? Is the fix in the development branch for sure? Where's the discussion of the possible impact? Where's the explanation of how it's been fixed?

It seems people think that nominating is the means by which the SRU process will be initiated: "OK, let me nominate that now, so that it will get more attention, and perhaps someone will look into it, and it will get a SRU". And they are wrong. And if they'd just spent ten minutes actually *reading* the policy they set out to criticize, they wouldn't be.

Wow John E, that's an impressive list of excuses you have there for not making a simple fix. The SRU says:

"Stable release updates will, in general, only be issued in order to fix high-impact bugs. Examples of such bugs include:

*Bugs which may, under realistic circumstances, directly cause a security vulnerability
*Bugs which represent severe regressions from the previous release of Ubuntu
*Bugs which may, under realistic circumstances, directly cause a loss of user data"

The problem is the Aumix binary was compiled incorrectly and it does not work at all. DOA. Dead. Useless. The fix is to recompile the package from source. Now what possible reason on God's green earth is there for not fixing this? It's a trivially easy fix for a severe regression- Aumix worked in the last release. Now it's dead as a doornail. I'd say it fits the SRU policy perfectly.

If you want quality releases, you should be running an LTS release which comes out every 2 years. You should not run the 6 months revisions if you are not willing to put up with some issues. If Microsoft released an OS every 6 months, you would have the same problems. Remember that if you want a high quality release, do not upgrade/install in the 6-month release cycle. The last Ubuntu LTS release was Ubuntu Dapper Drake 6.06. The next Ubuntu LTS release will be Ubuntu Hardy Heron 8.04. Wait until then :-)

Kristian, Microsoft took 7 years and spent billions of dollars on Vista, and released a buggy, lardy, bare-functional mess. So I'm afraid your example isn't quite the best one to support your premise.

Even so, none of you have answered why not fix such an easily-fixed bug? Hello, recompile and push out the update. What's the problem with that?

How many of you are Ubuntu devs or involved with Canonical in some way?

I'm not making up excuses, unless you happen to think that the whole policy is a set of excuses not to do things. Everything I've said is founded on the policy itself.

"The problem is the Aumix binary was compiled incorrectly and it does not work at all. DOA. Dead. Useless. The fix is to recompile the package from source."

The fix *cannot*, by definition, be "simply" recompiling. Source packages are built automatically by build daemons and placed into the archive; if the source package works when compiled on your computer, but the binary (whose existence means that the package *did* appear to build correctly) from the archive doesn't, that means the build daemons are doing something differently than your build environment. Has that difference been caught and indicated in the bug? No.

Right now, there's *no information* as to what exactly is causing the build in the Ubuntu archive to fail, and what's needed is that information. That compiling locally "fixes" the problem doesn't mean anything.

"Now what possible reason on God's green earth is there for not fixing this?"

None. See below.

"It's a trivially easy fix for a severe regression- Aumix worked in the last release. Now it's dead as a doornail. I'd say it fits the SRU policy perfectly."

And where did I say that it doesn't fit the SRU policy? Where did *anyone, ever* say that it doesn't?

The reason the nomination has been declined is that the bug is not ready to be acted upon *at the moment*. The "..does currently not qualify for a 7.10 stable release update" in the response means to say exactly that. The fact that its status is "Triaged" and its "Importance" field has been set means [1] that it's acknowledged as a valid bug.

What the whole situation boils down to is semantics. Your failure lies in not understanding what exactly a SRU nomination is, and what declining it means. The bug triager's failure is in using a canned response [2], which it seems is not successful enough in communicating its message to people who aren't very familiar with the bug triage and SRU processes.

Since you asked, I am an Ubuntu developer (not associated with Canonical). The response you got to that bug was sort of correct. We don't do updates after release until the problem is fixed in the development version as a risk reduction measure, so that part was right. I don't believe that the rest of the response was correct. The rest of the response read to me (and quite reasonably to you) like it would never be fixed in Gutsy and that was wrong.

I've marked the task to fix it in Gutsy approved and another developer confirmed that it's in fact fixed in Hardy (the current development release), so it's no longer blocked on that. I think if you'd just asked about this on an appropriate mailing list or IRC channel you could have gotten the same result.

Ubuntu is a big distribution with a lot of people doing a lot of different things. Most of the people are volunteers. All of the people make mistakes sometimes.

That's great that a newer, fixed version will be pushed out (thanks, Scott!) That'll help users a lot.

But I wonder about the underlying build bug that caused this. Does anybody know why the automated build process failed? Or whether it might affect other packages?

The policy is a little confusing anyway -- fixing a bug requires testing the fix on a newer release that has newer versions of everything, rather than testing it in the environment where you want it to be most stable? I applaud Ubuntu's intent to keep stable releases stable, but is that the safest way to go about it?

I'm curious how someone with any sense whatsoever could even dream that a minor bug that no one had heard of would be worked less than 3 weeks before final release.

And if it's such a trivial fix, what are the complainers doing to help in fixing the code?

"I'm curious how someone with any sense whatsoever could even dream that a minor bug that no one had heard of would be worked less than 3 weeks before final release."

That's a bit confusing- "would be worked"? This is several week after the final release. Would you please clarify?

"And if it's such a trivial fix, what are the complainers doing to help in fixing the code?"

I'm happy to send them a correctly-compiled Aumix package, built from the original sources. Where should I send it?

PS- as John E. said, there is a large communications gap between developers and end users, especially the ones that talk like John E. When you did you guys learn to talk like you don't want anyone to understand you? Nominations, semantics, failures, SRU whatsis, you're just asking for users to misunderstand you and then you have conflict. I think you should say things like "Thank you for reporting this bug. It has been assigned to someone to fix it." Nice plain English in a friendly tone.

I like Ubuntu and have been using it almost from the first release. Even so I am not blind to its flaws- it is large and well-funded, it has commercial aspirations, and it brags on itself non-stop. No wonder users have high expectations. They say all this "humanity to others" stuff, and make it sound like everyone is part of the big Ubuntu family, even plain old users who are not brilliant coders. So we try to contribute and make bug reports, which more often than not are not received in a positive way. I quit filing bug reports because it's OK for devs to be bitchy, but not the rest of us.

I must also comment that fixing bugs in the next release before the current release sounds daft.

Sorry for this being so long and somewhat negative, I just think there is a lot of room for improvement in how Ubuntu handles bugs and bug reports.

Everyone wants their bug fixed immediately. So do I. But it doesn't work that way, in any distro, or in any upstream project either. Yes, it's frustrating when something that is important to you doesn't work (and I've had my big share of those during the years) but IMO the system mostly works.

It's tempting to think that for "quick fixes" someone should drop whatever else they are doing and "just do it", but that is not a very pragmatic approach to software development/management, especially not on a large scale.

@ Drew - "That's a bit confusing- "would be worked"? This is several week after the final release. Would you please clarify?"

The original bug report was files about three weeks prior to the release of 7.10. Hence "would be worked" is understood if one had taken the time to read the linked information.

@Drew - "I'm happy to send them a correctly-compiled Aumix package, built from the original sources. Where should I send it?"

I have no idea. I'm a user and don't even know how to compile unless it's specified in the instructions. I'm sure you could find that information on Launchpad, along with the e-mail address of someone you could point you in the right direction.

This discussion reminds me of why I've shied away from cutting edge distros, and preferred the conservative approach of Debian stable (currently Etch). With Deb stable, I can enable backports repos, and have some more up to date packages, but still have an ultra stable, bug-free, efficient OS that was actually quite easy to install and configure (Etch is really a fantastic release for Debian - major improvements in HD detection, installation, and everyday use for desktop users).

That said, this discussion is rather silly. It seems the Ubuntu devs have recognized the bug and are working on fixing it (and in the process figure out what in their build process originally caused the bug), and will issue a patch for the current release. The problem is their horrible canned response to the bug report - it's confusing, ambiguous, and sounds like spinning political double talk.

John E., thanks for the clarifications. However, I would take issue with this:

"The fix *cannot*, by definition, be "simply" recompiling. Source packages are built automatically by build daemons and placed into the archive; if the source package works when compiled on your computer, but the binary (whose existence means that the package *did* appear to build correctly) from the archive doesn't, that means the build daemons are doing something differently than your build environment. Has that difference been caught and indicated in the bug? No."

It doesn't consider the situation where package A is initially built against package B, then package B is updated in such a way that package A doesn't work any more. In that case, "simply" recompiling package A is indeed all that's need to fix the problem.

I've no idea how often this is likely to happen in Ubuntu's buildsystem or whether it's the case here, just a situation you didn't seem to cover.

Drew, to be honest I'd be sympathetic to the Ubuntu guys here. Dealing with a very large number of bug reports for several iterations of a distribution at once is a fundamentally complex process and really does require 'bureaucratic' procedures and possibly jargon-y terminology that can look nasty from the outside. From what John wrote, and the follow-up on the bug, it doesn't seem like they handled the issue badly at all, really.

Although I'm *still* scratching my head over Abel Cheung's comment (the last on the bug, as I write). But then, Abel's like that sometimes :D

To me the bug is in Canonical's release & bug fix procedures, which appear to me to be unworkably bureaucratic and inflexible, for a bleeding edge release.

Carla's not been on any kind of a rant, in my view. As a software engineer and a UNIX/Linux sysadmin I understand the caution of the triager, but the copy & pasted text needs reworking. I like the response by the Ubuntu volunteer developer here, who managed to explain things in a clear non-defensive way, and actually do something helpful to!

Basically it it is ludicrous, not to fix an entirely broken package in their latest release. The part did not function, it should not have to be tested against Hardy with unstable development going on, and then trickle down. Just because they made Gutsy, 7.10 and mastered iso's should not freeze (bake might be better term?) in faults.

Whilst audio scripting is not the most critcal area, data loss unlikely, a significant feature of the realease was entirely broken, and the work round, of re-compiling the package by end user is too much effort, and going to cause gcc + development evironment to be downloaded over and over from their repositaries, costing Canonical money.

In my view, a good response is to make available a new Gutsty package, to those affected for testing, and then with their feedback push out updated package, as a recommended update.

Having downloaded Ubuntu, the 1st or 2nd day it was released, burnt a CD and installed. I was initially impressed by how solid and stable the initial release appeared to be. This was despite an number of install problems, caused by kernel changes, affecting my old hardware, which I had to work round. Disillusionment set in over next few weeks, as I found more and more of my time was spent, tracking down and isolating subtle bugs, in the scripts included with packages. None of the bug reports, I contributed to, appeared to be important enough to receive official comment, past fixes appeared to rely on Debian.

So, remembering good past experience with SuSE (6.1, 7.1, 7.3, 8.0 & 8.2) I tried OpenSuSE 10.3. Here, about 1 month after release, I got a system with more obvious rough edges, then a kernel update which proved disastrous. More response in reaction to Bug reports, though some seem to get black-holed with no light on issue escaping from Novel.

But, a month later, and Open SuSE 10.3, has had very many bug fixes, and package upgrades (using optional repositaries based on new upstream versions). The result is far more solid, and seems better maintained.

About a month later than Canonical, after releasing a month earlier, OpenSuSE have made their 1st alpha cut on 11.0.

So why is it that Open SuSE can release all these bug fixes, and not just security patches? Provide even updated experimental beta packages, of things like KDE4, and from a worse release position, become more solid and higher quality IMO?

First off Open SuSE has patches for security fixes and critical bugs, which online update installs by default. But secondly, it provide package "upgrades", which the user has to select. That means those not wanting change don't get it, those with an interest in a change do choose it.

They also, haven't regarded the GM (Gold Master) of the release as "Stable". What they've done is focus on fixes it for it, and pushed those out, making package updates available during installation, not just post-install via an "Update".

A Distro cannot no matter how hard it tries, get so much testing pre-release, that putting it out in the wild, as Release 7.10 is not going to turn things up, once the masses start pounding on it.

Therefore in first months, after release both security fixes, critical bug fixes, *and* low impact bug fixes should be produced, in a low overhead way for the packagers/support engineers/testers & affected users.

Later once the release stabilises, it can be frozen, and let the QA ppl have their way.

The next development release, should be for new features NOT bug fixes! When you base off Unstable + Experimental, then chuck in your own featurs, and have a 6 month release cycle, you cannot pretend, that it's going to be a robust QA friendly system, like Debian "stable", or various Enterprise Server versions.

Human nature, always means certain personalities will apply "rules" mindlessly, and make mistakes. They've tested and worked towards the release for months, so they'll actually be "bought in" and over-rate it's general quality, because it is impossible for them, to cover all the combinations and hardware choices that will be done by end-users.

So Canonical, be more user-friendly, be more realistic. Plan to cut 7.10.1, call it 7.10-stable if you must, but do it after 3 months of real usage, and support work, and only then create the obstacles to bug fixes on stability grounds.

All in all, having tried Fedora to, I think I'm going Open SuSE on the desktops needing M$ integration, and Debian stable on servers, with some Debian "testing" for development requirements.

Just saying that the fix is simply recompiling the package is nonsense... it has already been said, the reason why the build daemons do not build the package correctly, where a it does build correctly locally, needs to be discovered.

"stable" releases don't get fixes like that applied to them... that's why they are "stable" releases.

Use LTS or similar, they benefit from more pre-testing, and the back ports that follow their release.

I'm a sysadmin living in South France, and in charge of servers and desktops in town halls and public libraries, all running GNU/Linux. When I started the job about two years ago, I went through some serious testing of distributions. I had a TODO list counting a good hundred items, and then each candidate went through the tests: Mandriva, Ubuntu, SuSE, Debian, Fedora, etcetera. You name 'em, I probably tried 'em. In the end, two distributions ranked as "perfect", in the sense that they responded to everything we needed here on production machines: Slackware (the winner) and CentOS (a close second). I had gone through all the *buntus, of course, and I was amazed: how can you have the means ($$$$), the base (Debian) and end up producing such crap? Well, the artwork is nice, but a look under the hood keeps me wondering. Jesus, even the manpages are a babylonian encoding mess. I had filed a bug report about php-yaz at the time, and I got approximately the same treat. AFAIK, the bug was never fixed. FWIW, Ubuntu looks to me like Debian with bugs.

I don't see what the problem is, really. The policy they referred to might not be what we'd like, but it doesn't sound altogether unreasonable.

You can always ask for a refund if the excuses are unacceptable...

Yeah, I like a refund on my time please. Stick with Red Hat/Fedora/CentOS if you value your time.

Ok, I read this rant and every other rant on launchpad... Usually varying from

- I can't get so and so program/driver blah. to work on (Insert Ubuntu version released 2 days prior) and this is a real "SHOW STOPPER" for the distro (The ATI fglrx suspend/hibernate bug in gutsy comes to mind. It worked fine in (version-1) but I felt it absolutely necessary to upgrade because I am a retard and like to bitch that if you don't fix the problem now by downgrading from SLUB to SLAB in the kernel I'm going back to windows and I'm sure every newbie who was dumb enough to by a system with an ATI graphics card will as well:
https://bugs.launchpad.net/ubuntu/+source/linux-restricted-modules-2.6.24/+bug/121653
when: a. Why should OSS software suffer because of proprietary drivers?

I can admit I actually posted one of these 'show stopper' bug reports about my Edgy system destroying USB devices (Yep, plug em in and they are permanently dead! Here was a mobo BIOS update and many pricy usb devices that hit the trash can to confirm it was fixed.)

Ummm where am I going with this post? Well I havn't paid for my Kubuntu desktop, learned alot about, and like by the way, linux. HATE any non-debian .RPM system; Although I respect Gentoo which soldiered on my web server for years, replaced with FreeBSD which is ummm.... I think I should goto Debian for sanity. I hate compiling source but both work day in and out with uptimes in YEAR+mos without reboot!

Well, I can't live w/o Ubuntu on my desktop because I can move quickly through any app's command line config with ease and Suse's YAST is BS for me... Fedora... pretty but rpm's again. Trust me I apt-get it!

So dumb asses please use the LTS (Dapper). If your life is so critical why are you updating you machine????? Was something wrong with it?! Dapper still receives updates for security you know! Wow! And when Hardy+1 (Next LTS) comes out Dapper will still be on my file server until I TEST IT! Yep and back up! Yep! Ingenious solution... Many should try it! I learned it from my Windows IIS days when my web site was taken over every week or two... because of some obscure "Enable Parent Paths" tick box 50 GUI layers deep in the setup.

Or all you whiny people with "It's such an easy fix... Why don't they just do it?" can fix it themselves, and if they really care so much about Grandma, trying to figure out why some script she just wrote won't adjust the volume control using aumix, can just fix it, fork the entire Ubuntu project and name it Wasteoftimebu.

As everyone knows Grandma doesn't write scripts.... and if she did... she could easily just fix aumix be recompiling it ;)

To all the people using the word "Canonical": aumix is in Universe, which means it's not supported by Canonical. They have nothing whatsoever to do with this package. And when providing Ubuntu to you free of charge, they make this fact explicit. If anyone is to fix bugs in Universe packages, it's either upstream, the Debian maintainers, or the volunteer Ubuntu ones.

Criticism is good, but get the facts right. Canonical only supports the Main and Restricted components of Ubuntu.

part of the problem with ubuntu is it's package manager. yes people should use the long term support version. but often times a program you really want gets updated and you want it. the problem with ubuntu is that you can't simply install the new program and be happy. you have to upgrade the whole system to get that new program. if you could easily install software like you could on windows or mac, people wouldn't be complaining, they would just use LTS and install the latest version of gimp or whatever.

Sad to see I am not the only one, in fact I switched from Ubuntu to Fedora cause of a bug with binutils and ld core dumping. My bug report Granted I didn't handle it nicely.

Well Hamid,the fact is that the bug report was accepted and a fix released. Except that in Gutsy it's still broken. And it's still a fact that it's a simple fix that requires no mucking with the source code, or performing any heroic feats of coding brilliance. And it's a fact expressed several times by various developers that they would rather put their energy into the next release than fix older ones. I think this comment in the aumix bug report is a true policy statement and not satire:

"Since the Gutsy release is already out, aumix for Gutsy has entered a stable "buggy state". Any new package would cause the buggy state to be changed, thus require very careful consideration before deploying, and is rejected so far. Hardy has no such requirement ('freezing buggy state'), thus is free to receive newer packages. The final goal is to make Gutsy "Stably Buggy", not changing buggy state all the time."

Carla, did you seriously read my post? You seem to be replying to some other nonexistent post.

I'm not talking about whether the correct procedure was carried out, whether that procedure sucks and should be replaced, etcetera. Those have been debated. I'm talking about your and others's misplacing of the party at fault: it's not Canonical, it's Ubuntu. Universe packages are community supported. If something goes wrong with them, it's the community that's not doing its job 100% well.

Which brings us to the core of the problem: Ubuntu doesn't have enough eyes on the Universe repo. There are less than 100 MOTUs; that's nowhere near enough to keep track of the huge volume of packages and bugs. And this is probably because Ubuntu is still pretty young.