Re: Linux 2.6.21

On Sun, Apr 29, 2007 at 09:07:43AM -0700, Linus Torvalds wrote:


On Sun, 29 Apr 2007, Andi Kleen wrote:
Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> writes:

The thing is, bugzilla is totally broken because it's designed to help
track bugs, but it's *not* designed to actually handle the much harder
problem, which is to actually get the *right* developers to be aware
of the *right* bugs!

This means we need people who figure out who to assign bugs too.
Aka bugmasters.

Yes. But not using bugzilla.

And what would you use instead?


I don't know if you've noticed already, but I'm not the only one that
doesn't have a very high opinon of bugzilla ;)

Sure, but do you have alternatives?

What works is somebody who is a bugmaster, and it doesn't really matter
*what* bug tracker he points to (bugzilla being one of the possibilities,
although not necessarily the best, and absolutely NOT the only choice),
and turn them into emails. Once they are emails, bugzilla can track them.

So you want to do the work that should be done by a computer in
a database done by a human. Does not sound particularly efficient.

In theory it could be nearly automated. Figure out what files related
to the bug and assign to the last 5 people who submitted patches
for them and/or signed off.

I do think you're pretty optimistic. I think it's true for trivial driver
bugs, but even for trivial driver bugs the initial report is often not
enough to pinpoint the driver.

Let's take the sis900 bug as an example (not because I want to rag on that
being a problem, but it happened to be a _trivial_ bug in 2.6.21, so it's
a good case of something really really easy - and if that easy case isn't
handled trivially and obviously, then the bug-reporting doesn't work).

In that case, the initial report was (condensed version, but fairly
accurate): "system hangs on boot at random points. 2.6.21-rc7 worked
well".

Now, realistically, if that entry had been in bugzilla, what would you do?

You need a few people in bugzilla that ask the questions to narrow it
down (= bugmasters). e.g. the opensuse bugzilla works this way :-
everything new gets assigned to a few screening people who
ask some questions and then reassign to the right people.

Would bugzilla have helped? HELL NO. It would have been a disaster. It
would have wasted reporter time, it would have wasted developer time, and

An unmaintained bugzilla yes. A well maintained one would have someone
asking them the (often quite repetive questions) to narrow it down
to a subsystem or a driver. And then it could have been assigned.

I think both of these are good ideas, but I don't think it's enough. There
must be some better form of bug tracking than bugzilla. Some relly
distributed way of letting people work together, *without* having to
congregate on some central web-site kind of thing. A "git for bugs", where
you can track bugs locally and without a web interface.

And I think it would be something much closer to "distributed email mbox
with status tracking facilities", _not_ a web clicky interface.

There have been a couple of email thread trackers; like jitterbug --
in fact bugzilla can do that with an email interfaces. But in my experience
they don't work well because a bug tracking system has slightly different
requirements than normal emails (e.g. it wants you to roughly
stay on topic for the current bug). With email people always
forget that and in the end you end up with lots of stuff in there
not related to the bug at all.

Also with distributed solutions it would be hard to get
a global "how many regressions do we really have right now" statistic,
which is fairly important.

The web interface is slow and ugly but at least it puts
the people in the right mind set for this unlike email.
And it gives you a central point to get an overview of the bugs.

Anyways I'm sure bugzilla could be improved, I just don't know
of anything better currently.

-Andi

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Relevant Pages

  • Re: kernel bugzilla is FPOS (was: Re: "buggy cmd640" message followed by soft lockup)
    ... use bugzilla only for long-term bugs and avoid the needless bureaucracy. ... It looks like you'd like the reporter to initially debug the issue for you ... the bugreport status before filling bugzilla entry). ...
    (Linux-Kernel)
  • kernel bugzilla is FPOS (was: Re: "buggy cmd640" message followed by soft lockup)
    ... use bugzilla only for long-term bugs and avoid the needless bureaucracy. ... I put all of the reported regressions into the Bugzilla early. ... "Kernel version" given by reporter should be checked against the latest ...
    (Linux-Kernel)
  • Bugzilla and management thereof
    ... reporting it to bugzilla. ... the report could be updated to note that it still applies to f7. ... auto-closes bugs from older releases*. ... I was assuming that if Ray decided it was an upstream bug he'd ...
    (Fedora)
  • Re: [BUG] New Kernel Bugs
    ... of the biggest problems with bugzilla. ... Virtually no one in the ARM ... community looks for ARM bugs in bugzilla. ... the number of arm-specific reports in there is very small. ...
    (Linux-Kernel)
  • Re: MODULE_MAINTAINER
    ... ever gone to bugzilla without killing well over ... used for a report) to search for similar reports and join them. ... bugs and then simply mark them as such once identified. ... As subsystem maintainer, I am actively using kernel.org's bugzilla and I ...
    (Linux-Kernel)