lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20070430180952.GC23336@stusta.de>
Date:	Mon, 30 Apr 2007 20:09:52 +0200
From:	Adrian Bunk <bunk@...sta.de>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Diego Calleja <diegocg@...il.com>,
	Andi Kleen <andi@...stfloor.org>,
	Chuck Ebbert <cebbert@...hat.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: Linux 2.6.21

On Sun, Apr 29, 2007 at 02:24:03PM -0700, Linus Torvalds wrote:
> 
> 
> On Sun, 29 Apr 2007, Adrian Bunk wrote:
> > > 
> > > Kernel bugzilla has 1600 open bugs BECAUSE IT SUCKS.
> > 
> > OK, how do you suggest to track bugs in a way that doesn't suck?
> 
> I've tried to explain.
> 
> Bugzilla can be one _part_ of it, but anybody who thinks it's the "main 
> part" is really not being realistic. It's too cumbersome, and it's too 
> stupid. 

I do completely agree with you on this.

The main parts are people doing some sorting and forwarding of an 
incoming bug (currently mostly Andrew) and someone with deeper subsystem 
knowledge looking deeper into a bug (currently often missing).

> Quite frankly, "lkml + google" is probably in many ways a *better* way to 
> search for problems. But yes, some manual smarts (and the _occasional_ 
> pointer to bugzilla) is probably currently the only option.
> 
> Exactly because I don't think anybody has shown any better automation than 
> bugzilla. But that doesn't make bugzilla "the One Choice". That's not how 
> it works. If there is no automation, manual tracking is still better than 
> *crap* automation.

I had the regressions stored in a plain textfile.

For getting regressions reasonably grouped for my regression emails, I 
used paper, pen and scissors - and this is not a joke.

That really didn't scale when we had 36 regressions.

So some tool is needed if the bug numbers are bigger - no matter whether 
it's Bugzilla or speaking plain SQL to a database, or anything else.

> > Bug reports to linux-kernel have the big problem that they are lost if 
> > no developer immediately picks them up.
> 
> ..and this is different from bugzilla exactly _how_?
> 
> Those things are lost too. As you yourself have pointed out. The fact that 
> you can search for them is _exactly_ as relevant as the fact that you can 
> search for lkml on google.

It depends on how you look at bugs.

My ideal was always that reported bugs should be fixed.

If you accept that this is anyway impossible because more bugs get added 
than could get fixed you might not need any tracking at all.

> > What I do know is that the majority of them has never been proper 
> > debugged by a kernel developer knowing the subsystem in question.
> 
> And you blame the developers, but not bugzilla? Why are you so unable to 
> see bugzilla as part of the *cause* of the problem? You're perfectly happy 
> to blame other things, but bugzilla is somehow above blame?

If Andrew forwarded a bug reported in Bugzilla to a developer, and 
the developer doesn't answer, is this Bugzilla's fault? Or in any other 
way worse than a bug report direct to the developer?

> 		Linus

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ