linux-kernel - Re: 2.6.19 -mm merge plans

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: <20060920220744.0427539d.akpm@osdl.org>
Date:	Wed, 20 Sep 2006 22:07:44 -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 00:22:26 -0400
Jeff Garzik <jeff@...zik.org> wrote:

> Andrew Morton wrote:
> > A wander through the -mm patch queue, along with some commentary on my
> > intentions.
> > 
> > 
> > When replying to this email, please rewrite the Subject: to something
> > appropriate.  Please also attempt to cc the appropriate developer(s).
> > 
> > 
> > There are quite a lot of patches here which belong in subsystem trees. 
> > I'll patchbomb the relevant maintainers soon.  Could I pleeeeeze ask that
> > they either merge the patches or solidly nack them (with reasons)?  Don't
> > just ignore it all and leave me hanging onto this stuff for ever.  Thanks.
> 
> I know this is probably heresy, but what would happen if we didn't merge 
> all that stuff at once, and then committed to having a real 4-week cycle?

(where'd 4 weeks come from?)

Why would a shorter cycle be better?  What are we trying to achieve?

> The cycles seem to be stretching out again, and I don't really think 
> it's worth it to hold up the entire kernel for every single piddly 
> little regression to get fixed.  We'll _never_ be perfect, even if we 
> weren't slackers.
> 

People seem to treat the stabilisation period as a wonderful quiet time in
which to run off and develop new features, rather than participating in the
stabilisation.  This has the following effects:

1: release cycles get longer

2: the kernel has more bugs

3: we put new features into the kernel faster than we otherwise would
   (see 2:, above).

Furthermore, in this period we have 60-odd disjoint trees which are based
on a relatively-slowly-changing mainline.  This makes people think they are
free to go berzerk, leaving me bemusedly wondering why there are VFS and
NFS changes in the OCFS2 tree, SATA changes in the powerpc tree, SATA
changes in the scsi tree, configfs changes in the GFS2 tree,
every-goddam-thing changes in the driver tree, MM changes in the parisc
tree, etc, etc, etc.

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.

So...  it again comes down to "what are we trying to achieve"?  Me, I'd
like to see people spending less time developing whizzy new things and more
time fixing bugs, tuning performance, etc.  That would fix the lengthy
release cycle problem automatically.

What do _you_ want to achieve by making changes?

And a question.  The current batch of git trees has:

 2611 files changed, 295643 insertions(+), 130150 deletions(-)

How much of this has been suitably reviewed?

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