Justin Dugger ([info]jldugger) wrote,
@ 2009-03-02 13:12:00
Previous Entry  Add to memories!  Tell a Friend  Next Entry
Entry tags:bugs, launchpad, training, ubuntu

I wholeheartedly agree

Colin puts together a coherent rant about bug triage with Ubuntu. I'm glad he was able to meditate on the subject and produce a document with clarity and specific improvements; I wrote a private rant that included the phrase "Bug Assassination Squad: We kill bugs in their infancy". Probably not diplomatic enough to publish.

More diplomatically, one thing I'd like to add to Colin's commentary is about bug duplicates. Some people seem to be in the habit of marking duplicate bugs invalid. Yes, there are a lot of bugs, so going to the effort of finding the dupe and marking it means you'll be slower at closing bugs. But you'll have a better bug database as a result. And it will spare me the effort of searching through all the package's bugs to discover there is no such duplicate. Certainly, if you believe there's a duplicate report, you have a better idea of where the dupe is than the person who submitted the bug, who went through LP's own dupefinder to report the bug in the first place.

While I do feel vindicated that this practice is contrary to guidelines, the fact that it still happens is not encouraging.


(2 comments) - (Post a new comment)


(Anonymous)
2009-03-04 07:13 pm UTC (link)
Once again I find some sanity from your comments after coming from Ubuntu planet.

Indeed it was a good and coherent rant. (See also the corresponding LWN article.)

How would I put this. Diplomatically: the signal-to-noise ratio is low in Ubuntu. Less diplomatically: while new ideas are constantly being thrown and more people are getting involved each day, there seems to be a lack of very old-fashioned work, purely technical work, work that can not be solved by silver bullets, work that has kept Ubuntu's parent busy for over a decade. The real problem is that the described pattern with bug reports is exactly the kind of behavior that kills the motivation of people who actually do technical work.

I predict that if Ubuntu is going to achieve even wider userbase, the described -- real or perceived -- problems will become even more intense, eventually requiring either more professional (read: paid) developers or more clear-cut divisions between users and developers also at the community-level (instead of the now implicit assumption that everyone is qualified to evaluate segmentation faults because, well, we are all a big happy family).

Perhaps this went out more as a rant, but was meant as a constructive criticism. Sorry for that.

(Reply to this) (Thread)

[info]jldugger
2009-03-04 10:50 pm UTC (link)
I disagree with your rant. In my experience, professionals are the bigger infringers. It might not surprise you that Canonical hires a few people to handle bugs within Ubuntu, to work alongside the community. Some of it may be pressure from "management" to quash the load, but some of it seems to be inherited from dysfunctional bug report projects like GNOME.

I think 5-a-day is the wrong approach here, and I make no secret about it. 5-a-day encourages shallow effort on a lot of reports. It's not as hard as you suggest to hunt down segfaults. If I can do it with GDB and X, there are probably people who can hunt these down on simpler projects. And it's the perfect time to collaborate with upstream when you don't know how to fix it.

Instead of teaching people to find old bugs and reproduce them, we should be teaching people to try to reproduce the problem. As Colin suggests, it will be slower, but volunteers will learn a lot about new software that way, and probably produce something of value in the process.

There's still room for triage and light bugwork; a lot of bugs come in unassigned to a package and we don't yet have a good package inferrence tool.

(Reply to this) (Parent)

(2 comments) - (Post a new comment)

Create an Account
Forgot your login or password?
Login w/ OpenID
English • Español • Deutsch • Русский…