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
| ||
|
Date: Wed, 20 Sep 2006 23:48:28 -0700 From: Andrew Morton <akpm@...l.org> To: Jeff Garzik <jeff@...zik.org> Cc: linux-kernel@...r.kernel.org, Linus Torvalds <torvalds@...l.org> Subject: Re: 2.6.19 -mm merge plans On Thu, 21 Sep 2006 02:36:55 -0400 Jeff Garzik <jeff@...zik.org> wrote: > Andrew Morton wrote: > > If you think that shortening the release cycle will cause people to be more > > disciplined in their changes, to spend less time going berzerk and to spend > > more time working with our users and testers on known bugs then I'm all > > ears. > > Honestly, I do think it would be positive. It would shorten the > feedback loop, and get more changes out to testers. > > It would also decrease the pressure of the 60+ trees trying to get > everything in, because they know the next release is 3-4 months away. > It would be _much_ easier to say "break the generic device stuff in > 2.6.20 not 2.6.19, please" if we knew 2.6.20 wasn't going to be a 2007 > release. > Well, it might be worth trying. But there's a practical problem: how do we get there when there's so much work pending? If we skip some people's trees then they'll get sore, and it's not obvious that it'll help much, as the various trees are fairly unrelated (ie: parallelisable). I guess the most practical way is to incrementally shorten the cycles. <rerererepeating self> I do think that any process change we make should send the signal "slow down, be more careful, test and review it more carefully". Or at least, "try to make sure it compiles". A compulsory Reviewed-by: would wedge things up nicely ;) - 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