Re: Linux 2.6.21





On Thu, 26 Apr 2007, Diego Calleja wrote:

Bugzilla sucks quite a lot at email, but you can answer emails and they get
into the bugzilla database; and there're two mailing lists (listed in
Documentation/HOWTO) that send notifications about every new bug
added/modified- I know it's not the perfect email interface every hacker
wants, but it's better than nothing.

No, it's *not* better than nothing.

The thing is, these reports MUST NOT go to "everybody". If they do, that
is actually *worse* than nothing, because people will just ignore them
entirely, since they aren't "directed".

The emails need to be directed to the appropriate parties, not go to
everybody. There is nobody who is interested in seeing all regressions,
except perhaps me and Andrew. Most *real* developers (as opposed to people
like me, who are integrators, not "real developers") want to be notified
about problems in *their* area, and if it's just automation that sends out
everything, it just dilutes the value of the thing, to the point where
people will ignore it even for the cases when they happen to be related to
what they do.

I suggested some time ago that it'd be useful to send every new bug
notification from bugme-new to the LKML (and/or other lists).

I don't know a lot of developers who actually read LKML. I know a lot of
people who look for interesting subject lines and interesting people, but
read LKML in the sense of reading everything? Not likely.

That's why I think Adrian did a great job: he took the "noise" and made it
somethng worth looking at! And part of that is very much to make it
directred to only relevant parties (yes, they *also* got cc'd to
linux-kernel, but people would get them in their personal mailboxes and
*not* feel like it was just noise that didn't matter to them!)

I can understand Adrian's resign. Bugzilla is crap, but there're users
reporting bugs there and willing to cooperate to fix them, and they're
not getting listened.

I personally refuse to have anything at all with bugzilla. The interface
is so horrible that it's just not worth my time. I know there are a few
people who use it productively, but I'm always amazed that they can do
that.

The *big* problem with bugzilla is that it's such a "detail-oriented"
thing. It's fine if you have *one* bug that you're tracking. But whenever
that's not the case, it's almost totally useless.

Let me put it another way: I would never use a source control system that
forces me to look at my 22,000 files one at a time. I think such a system
is fundamentally broken, because it makes it impossible to get the big
picture ("what changed in the last week" kind of thing). The same is true
of bugzilla: if you *know* which bug you're looking at, it's good. For
anythign else, it's almost worse than useless, exactly because there is no
way to get an overview.

There're even a few description of patches (ie: "line
6 in foo.c is wrong and it breaks our testing, it should read like this:")
that have been sitting there for *years* and not getting merged.

.. and you claim that this shows that developers don't listen. I'd say it
shows the exact *opposite*: the users don't listen. There's a lot mroe
users than developers, and bugzilla is pretty much designed to let the
users "report and forget", which is exactly the *wrong* thing to do,
because it puts the onus on the developer.

(I've said this before, but I'll say it again: one thing that would
already make bugzilla better is to just always drop any bug reports that
are more than a week old and haven't been touched. It wouldn't need *much*
touching, but if a reporter cannot be bothered to say "still true with
current snapshot" once a week, then it shouldn't be seen as being somehow
up to those scare resources we call "developers" to have to go through
it).

So there are probably things that bugzilla could do to become more useful,
but I don't see that happening. We'd need either a smarter/better
bugzilla, or somebody who actually turns noise into real information.
Adrian did that (although in fairness to others, other people definitely
do it too. Dave Jones, for example. Very useful).

So I, or anyone else, could try to do Adrian's job. But if Adrian (a guy
that sends patches to make global functions static 8) got tired
of doing that job, I suspect that I, or anyone else would also got
tired of it even sooner.

I do agree - one of the problems with the job is not that it's thankless
(I think we've had at least ten kernel developers, very much including me,
talking about how _useful_ it is), but there is definitely a lack of
glamour and probably interest.

I think it could be more interesting if part of the job was doing the
tools. Tools *are* important. Most of my actual _development_ for the last
couple of years has been on "git", not the kernel, but I think I was more
productive that way, so I don't think that's wasted time at all.

So yes, automation would be a good idea, but I don't think bugzilla is it.

There're other big projects with probably more bug reports than linux,
they don't work this way, and they look more succesful in their bug
handling.

Well, one thing to keep in mind is that the kernel really does have a
*lot* more development going on that most other projects.

I don't think you'll find another project that has about six megabytes of
diffs every release (every two months). That's really one of the
fundamental issues - things really *happen* in the kernel. A *lot* of
things. You can't take a breather - I can do "stabilization releases"
every once in a while, and Andrew can kick out patches he decides aren't
ready to be merged rather than maintain them in his tree (and he does do
that), but the kernel simply tends to have a different *scale* than other
projects.

And almost all hard bugs are about hardware interactions. Drivers. Big
iron. Things like that - ie unlike something like a compiler, you can
seldom say "this test-case crashes". Yes, that does happen for the kernel
too, but those are the *easy* bugs. Those generally get fixed in a day or
two.

So I really don't think you can compare to "other projects". They simply
don't have these issues.

Limis
-
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

  • RPM packages: Athlon vs i686 vs i386
    ... I recently submitted what I thought was a bug to bubzilla concerning CPU ... Kernel 2.4.22-1.2174.nptl on an i686 ... On bugzilla, the report has been closed with: ...
    (Fedora)
  • Re: [Slightly OT] Re: Ranter or evangelist?
    ... They use git, which is not really a bugzilla, but bugs do get fixed before ... these which are the fault of web developers relying on IE specific things. ... net they'll find instructions suggesting that they install akmod-nvidia, ...
    (Fedora)
  • Re: Giving developers clue how many testers verified certain kernel version
    ... >> bugzilla. ... to the kernel itself. ... there is a bug somewhere when one can't really know if that is the way ... send the line "unsubscribe linux-kernel" in ...
    (Linux-Kernel)
  • Re: Who wants to maintain KR list for stable releases? (was Re: nmi_watchdog=2 regression in 2.6.21)
    ... Bugzilla is for tracking bugs, ... Tracking feature or implementation suggestions wouldn't make sense. ... write what they think the kernel should do but who never write a single ... The only thing that comes into my mind is that you cannot reassign a bug ...
    (Linux-Kernel)
  • Re: Linux 2.6.21
    ... That's exactly where Linus' "drop any bug reports that are more than a ... bugzilla is totally broken because it's designed to help ... And spamming even the right developers ... the whole phase of connecting developers to bug ...
    (Linux-Kernel)