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: <20070614173049.GU3588@stusta.de>
Date:	Thu, 14 Jun 2007 19:30:49 +0200
From:	Adrian Bunk <bunk@...sta.de>
To:	Oleg Verych <olecom@...wer.upol.cz>
Cc:	Stefan Richter <stefanr@...6.in-berlin.de>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andi Kleen <andi@...stfloor.org>,
	"Rafael J. Wysocki" <rjw@...k.pl>,
	Diego Calleja <diegocg@...il.com>,
	Chuck Ebbert <cebbert@...hat.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: regression tracking (Re: Linux 2.6.21)

On Thu, Jun 14, 2007 at 06:39:23PM +0200, Oleg Verych wrote:
> On Thu, Jun 14, 2007 at 05:33:40PM +0200, Stefan Richter wrote:
> []
> > [...]
> > > Why you didn't proposed (used) Debian's BTS as alternative to bugzilla,
> > [...]
> > 
> > BTS has been mentioned in that thread in a few posts; mostly positively
> > as I recall.
> 
> I know, that most developers here are not working/familiar with what
> Debian has as its bug shooting weapon ``The system is mainly controlled
> by  e-mail, but the bug reports can be viewed using the WWW.''[0].
> 
> I thought somebody, who familiar with that, might propose to setup/tune
> it, but not doing yet another NIH thing, especially from e-mail
> integration POV. I doubt mozilla guys can think about it without
> javascript and/or java servlets :)
>...

The problem isn't Bugzilla, and the Debian BTS wouldn't solve any 
problem.

What is missing?

We need people who know one or more subsystems and who are willing to 
regularly handle bug reports in their area.

And we need a release process that makes debugging, and if possible 
fixing, all regressions prior to the release mandatory. You might never 
come down to zero regressions and might not be able to handle all 
last-minute reported regressions, but the 2.6.21 situation with 3 week 
old known regressions not ever being debugged by a kernel developer 
before the release has much room for improvements.

Changing the BTS would make sense if some core developers would state 
that they would start using the BTS after this change. But otherwise it 
doesn't matter which BTS to use.

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