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