linux-kernel - Re: Linux 2.6.21

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <200704300119.18474.rjw@sisk.pl>
Date:	Mon, 30 Apr 2007 01:19:17 +0200
From:	"Rafael J. Wysocki" <rjw@...k.pl>
To:	Diego Calleja <diegocg@...il.com>
Cc:	Adrian Bunk <bunk@...sta.de>, Andi Kleen <andi@...stfloor.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Chuck Ebbert <cebbert@...hat.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: Linux 2.6.21

On Sunday, 29 April 2007 23:51, Diego Calleja wrote:
> El Sun, 29 Apr 2007 23:10:28 +0200, Adrian Bunk <bunk@...sta.de> escribió:
> 
> > What exactly is the purpose of the 2.6.21 regressions list in the Wiki?
> 
> AFAIK, submitting its contents to the list periodically CCing the developers,
> like you did with your lists.
> 
> If developers care to fix it or not or how much Linus cares about that list before
> releasing a new version is another question. I think it's useful because it makes
> those bugs look more important than the 1600 stored in the bugzilla...it won't
> help to fix those 1600, but it attracts some attention over the "release critical"
> ones and encourages developers to fix them, even if not all of them get fixed.
> 
> I don't think you can do many other things to get as much bugs fixed as possible,
> unless we reward bug fixers with weekends in the Playboy mansion. I think the
> fundamental question here is: is there a way to make hackers follow and fix _all_
> the bugs? I'd love it was possible, but AFAIK all the projects that have tried to
> be ultra-stable and have adopted a policy to fullfill such goal have fallen behind
> of competing projects that cared more about working in improving their software.

Apart from this many bugs are found and get fixed in the process of developing
new code, so the 'ultra stable' approach is not really practical.

Greetings,
Rafael
-
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/