18 Responses

I agree with the bug poster and the subsequent rant, if there’s something that looks like it can be run and can be triggered without parameters, perhaps its default action should be something safer than scrubbing the filesystem.

It’s equivilent to “rm” defaulting to “rm -rf /”.

I’m not saying this isn’t a lot of wasted puff, but the total energy required should have been bug reported, one confirmation, patch pushed, patch pulled into ubuntu.

I see plenty of moaning that he should have just written the patch but It doesn’t matter who writes the patch, just that somebody does and it gets handled properly. I knoq there’s a question of process here but rather than complaining about it (or even complaining about complaining – as I am now) perhaps we should all move along and get something done.

(PS: it turns out that Scott had committed a different fix for this locally yesterday, so the branch linked above is obsolete)

I’d like to clarify the thesis of this post, which is:

Contributing patches to Ubuntu using Bazaar is really, really easy to do. Therefore, it is really not worth expending energy worrying about what someone else should do. Just do it! All you need is a Launchpad account.

It was not my intent to criticize anyone personally for how they responded to this situation, only to remind everyone that we have enough work to do, and should all spend our energy helping each other to get the work done.

There are an awful lot of people around (including folks complaining about this bug) who might consider themselves “not developers”, but who know how to fix a broken shell script. It’s not exactly a deep computer science problem. :-)

There might have been a rant and a lot of complaining, but not everybody is able/wants to code.

Defaulting to Armageddon is not something a script should do and Scott utterly failed to see that and somehow I don’t like the tone in the bug, this post and comment. It feels a bit aggressively defensive and patronizing. It surely is not “Be excellent to each other”(CoC) IMHO.

1. I don’t think I’m aggregated on Planet Ubuntu, so I guess you found my post on Planet Debian.

2. The rant was not about the bug itself. I thought I made that clear when I wrote “That alone isn’t the most spectacular about it. Bugs happen.”. The most disturbing thing about the bug was the reaction of an Ubuntu developer who is also a member of a TechBoard. As a matter of fact if people of this “importance” are deciding like that it somehow seems representative about Ubuntu at a whole. That was what I was ranting about. Because it does not really speak for the quality of Ubuntu if the reaction on a critical bug is “Its not a bug 1111!!!!11”. Therefore the rant wasn’t wasted energy.

2. In my post, I said that the rant was about how the bug was classified (wontfix, wishlist, whatever), not about the bug itself. It still didn’t help to get either problem fixed.

I don’t think Scott would argue that the discussion could have been handled better, but what he actually did about the problem (fixed the bug) was the right response. Most everyone else involved in the discussion did nothing to get the bug fixed. All of the talk was wasted effort compared to the trivial act of fixing the bug, and it would have been better to cut it short or skip it entirely.

Well, its only half of the truth that it was about the justification. He marked it invalid at the first place, so its a matter of fact that his first response was “Dumb user, this bug does not deserve attention”.

And while you argue that in the end Scott fixed the bug its obvious from the bug log that in the first place he *in fact* didn’t intend to do so. So we can speculate about cause and effect here. The question is did he really consider fixing the bug but tagged it invalid anyway? Or isn’t it (more likely) the other way round: He saw the waves his reactions made and went for damage control? I guess its the latter.

So, yes, ranting did nothing to get the bug fixed. But: So what? It was still valid to show up: “Hey, some important Ubuntu developers don’t care if they mess up with your system… unless enough people shout out.” and I don’t want to play a child here, but it was obviously a one-liner from the first look so instead of writing stupid comments on the bug report showing his complete inability to accept a perfectly valid bug Scott could have fixed the bug in the first place as well.

I’m beginning to think that too many actions on Launchpad “require” someone to Invalidate a bug. In any case, from a user’s perspective, it’s entirely the wrong answer, because it’s interpreted as “your bug is a non-bug, go home!” which is never desirable.

Leaving aside the human discussion in the bug report for the moment, I’ll say something about this comment here about Landscape workflow.

I feel your pain. We’ve had a similar discussion in Fedora off and on about invalidating bugs in our bugzilla instance when dealing with it upstream instead of in the packaging. I’m both happy and sad to see Launchpad doesn’t completely fix the problem.

Sad because the disconnect between tool required workflow for developers actions and user perception of those actions creates way to much heat.

Happy, because we aren’t alone. Misery does indeed love company.

Perhaps there’s a way to have Launchpad be more verbose about the reason things are being marked invalid. Some boiler plate response saying its being marked as invalid as a package bug so it can be tracked against the upstream launchpad project instead? The action comments are quite terse. And I think if your comment above was placed in the context of the bug report when the invalid happened..it would have dissipated some of the heat.

It’d have been valid to leave the Ubuntu task as confirmed too though. When a GNOME bug is reported in Ubuntu, we link to the upstream bugs.gnome.org bug but *don’t* invalidate the Ubuntu task in Launchpad in the process. So no, you weren’t *required* to invalidate the Ubuntu task.

Guess I should add that, this way you could’ve tracked “ok it’s Fix Released on upstart, but that package isn’t released to Ubuntu yet, so thats still In Progress” which can be useful to know. It’s how every other upstream bug gets handled. Then in the debian/changelog list which Ubuntu tasks have been fixed in this release. Because it *is* useful to know when a fix exists upstream that isn’t yet in Ubuntu.

Having the technical ability to fix the bug does not grant you the right to be silly with the person which having or not such ability devoted some effort to report the bug.
Those 99% of wasted energy were caused by Scott’s comments.
I am sure Scott does a great job, this was not about the person but about the attitude on this specific case.