All of lore.kernel.org
 help / color / mirror / Atom feed
From: Randy Dunlap <randy.dunlap@oracle.com>
To: "Dave Jones" <davej@redhat.com>, "Greg KH" <gregkh@suse.de>,
	"Ingo Molnar" <mingo@elte.hu>,
	"Geert Uytterhoeven" <geert@linux-m68k.org>,
	"Andrew Morton" <akpm@linux-foundation.org>,
	"Jörn Engel" <joern@logfs.org>, "David Brown" <lkml@davidb.org>,
	"Phil Oester" <kernel@linuxace.com>,
	"Kay Sievers" <kay.sievers@vrfy.org>,
	"Phillip Lougher" <phillip@lougher.demon.co.uk>,
	"Christoph Hellwig" <hch@infradead.org>,
	torvalds@linux-foundation.org, linux-kernel@vger.kernel.org,
	linux-fsdevel@vger.kernel.org
Subject: Re: [GIT PULL] Squashfs pull request for 2.6.29
Date: Thu, 22 Jan 2009 13:57:53 -0800	[thread overview]
Message-ID: <4978EBE1.9080403@oracle.com> (raw)
In-Reply-To: <20090122215041.GA29369@redhat.com>

Dave Jones wrote:
> On Sun, Jan 11, 2009 at 08:30:18AM -0800, Greg KH wrote:
> 
>  > I was wanting to stick with drivers to start with, but I really have no
>  > objection to adding filesystems, if they are self-contained, to the
>  > drivers/staging/ directory.
>  > 
>  > I looked at adding squashfs, but at the time, it touched other portions
>  > of the kernel which wouldn't have made it a good canidate for staging.
>  > This was later resolved, and now that it is merged, it's a moot issue :)
>  > 
>  > So, if anyone wants to send me filesystems, I'll be glad to take them
>  > into drivers/staging, as long as they are self-contained (novfs for
>  > example would fit this category.)
> 
> Filesystems in staging worries me.
> 
> * The number of people who competently review filesystem code
>   (and I mean real review here, not checkpatch & codingstyle crap)
>   is significantly less than those who review drivers.
>   I foresee stuff just lingering there for years.
>   (Look how long fs stuff hangs around unmerged in -mm for example).
>  
> * The fallout of staging is already starting to drift into distros.
>   Within a week of Fedora shipping a kernel that had staging/
>   we had requests to enable drivers from it.
>   And of course, those drivers were garbage.
>   This is only going to increase as time goes on.
> 
> * For crap drivers that a minority cares about, this isn't a big deal
>   to tell the users "build it yourself, we don't support it when stuff breaks".
>   (And a lot of that crap will break.  NetworkManager won't work properly
>    with some of the wireless crap in staging for example), but by
>   continually adding to the shitpile the potential for review dramatically
>   gets reduced, and for something as critical as a filesystem, I find this
>   absolutely terrifying from a support perspective.
> 
> I don't mean to piss on your parade, but from my viewpoint, staging
> is a trainwreck so far, and I'd hate to see it get worse.
> 
> We've already demonstrated "look how much stuff we can merge" time and
> time again, but no-one ever seems to have a proposal for how we increase
> the amount of review code gets before it's merged.
> 
> There's lowering the barrier for entry, and there's not having a barrier at all.
> The latter is what I'm concerned that staging/ has become.

I agree.  Alexey D. asked about that a few days ago and the Greg's answer
about what he would accept was "anything".  Ugh ugh ugh.  I did not like
that reply at all.

I agree that crap is the right name for lots of it.  For the ones that
people & distros care about, someone should step up and do some real
work on them.



~Randy

WARNING: multiple messages have this Message-ID (diff)
From: Randy Dunlap <randy.dunlap@oracle.com>
To: "Dave Jones" <davej@redhat.com>, "Greg KH" <gregkh@suse.de>,
	"Ingo Molnar" <mingo@elte.hu>,
	"Geert Uytterhoeven" <geert@linux-m68k.org>,
	"Andrew Morton" <akpm@linux-foundation.org>
Subject: Re: [GIT PULL] Squashfs pull request for 2.6.29
Date: Thu, 22 Jan 2009 13:57:53 -0800	[thread overview]
Message-ID: <4978EBE1.9080403@oracle.com> (raw)
In-Reply-To: <20090122215041.GA29369@redhat.com>

Dave Jones wrote:
> On Sun, Jan 11, 2009 at 08:30:18AM -0800, Greg KH wrote:
> 
>  > I was wanting to stick with drivers to start with, but I really have no
>  > objection to adding filesystems, if they are self-contained, to the
>  > drivers/staging/ directory.
>  > 
>  > I looked at adding squashfs, but at the time, it touched other portions
>  > of the kernel which wouldn't have made it a good canidate for staging.
>  > This was later resolved, and now that it is merged, it's a moot issue :)
>  > 
>  > So, if anyone wants to send me filesystems, I'll be glad to take them
>  > into drivers/staging, as long as they are self-contained (novfs for
>  > example would fit this category.)
> 
> Filesystems in staging worries me.
> 
> * The number of people who competently review filesystem code
>   (and I mean real review here, not checkpatch & codingstyle crap)
>   is significantly less than those who review drivers.
>   I foresee stuff just lingering there for years.
>   (Look how long fs stuff hangs around unmerged in -mm for example).
>  
> * The fallout of staging is already starting to drift into distros.
>   Within a week of Fedora shipping a kernel that had staging/
>   we had requests to enable drivers from it.
>   And of course, those drivers were garbage.
>   This is only going to increase as time goes on.
> 
> * For crap drivers that a minority cares about, this isn't a big deal
>   to tell the users "build it yourself, we don't support it when stuff breaks".
>   (And a lot of that crap will break.  NetworkManager won't work properly
>    with some of the wireless crap in staging for example), but by
>   continually adding to the shitpile the potential for review dramatically
>   gets reduced, and for something as critical as a filesystem, I find this
>   absolutely terrifying from a support perspective.
> 
> I don't mean to piss on your parade, but from my viewpoint, staging
> is a trainwreck so far, and I'd hate to see it get worse.
> 
> We've already demonstrated "look how much stuff we can merge" time and
> time again, but no-one ever seems to have a proposal for how we increase
> the amount of review code gets before it's merged.
> 
> There's lowering the barrier for entry, and there's not having a barrier at all.
> The latter is what I'm concerned that staging/ has become.

I agree.  Alexey D. asked about that a few days ago and the Greg's answer
about what he would accept was "anything".  Ugh ugh ugh.  I did not like
that reply at all.

I agree that crap is the right name for lots of it.  For the ones that
people & distros care about, someone should step up and do some real
work on them.



~Randy

  reply	other threads:[~2009-01-22 21:59 UTC|newest]

Thread overview: 59+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-01-08 16:48 [GIT PULL] Squashfs pull request for 2.6.29 Phillip Lougher
2009-01-08 16:50 ` Christoph Hellwig
2009-01-08 17:05   ` Phillip Lougher
2009-01-08 17:11   ` Geert Uytterhoeven
2009-01-08 17:11     ` Geert Uytterhoeven
2009-01-08 23:55   ` H. Peter Anvin
2009-01-09  1:53   ` Andrew Morton
2009-01-09  2:11     ` Phillip Lougher
2009-01-09  2:24       ` Kay Sievers
2009-01-09  2:36         ` Phil Oester
2009-01-09 16:54           ` Jörn Engel
2009-01-09 16:54             ` Jörn Engel
2009-01-09 19:37             ` David Brown
2009-01-09 19:37               ` David Brown
2009-01-09 21:19               ` Jörn Engel
2009-01-10 12:43                 ` Ingo Molnar
2009-01-10 12:43                   ` Ingo Molnar
2009-01-10 16:50                   ` Jörn Engel
2009-01-10 16:50                     ` Jörn Engel
2009-01-10 18:12                     ` Andrew Morton
2009-01-10 18:30                       ` Linus Torvalds
2009-01-10 19:57                         ` Jeff Garzik
2009-01-10 20:16                           ` Leon Woestenberg
2009-01-11  6:36                         ` Valdis.Kletnieks
2009-01-10 19:19                       ` Olivier Galibert
2009-01-10 22:15                       ` Ingo Molnar
2009-01-11  9:30                         ` Geert Uytterhoeven
2009-01-11 15:39                           ` Ingo Molnar
2009-01-11 16:30                             ` Greg KH
2009-01-22 21:50                               ` Dave Jones
2009-01-22 21:57                                 ` Randy Dunlap [this message]
2009-01-22 21:57                                   ` Randy Dunlap
2009-01-22 22:15                                   ` Greg KH
2009-01-22 21:58                                 ` Greg KH
2009-01-22 21:58                                   ` Greg KH
2009-01-22 22:26                                   ` Ingo Molnar
2009-01-22 22:50                                   ` Kyle McMartin
2009-01-22 23:04                                     ` Greg KH
2009-01-22 23:25                                       ` Evgeniy Polyakov
2009-01-22 23:34                                       ` Kyle McMartin
2009-01-22 23:41                                         ` Ingo Molnar
2009-01-22 23:28                                     ` Evgeniy Polyakov
2009-01-22 22:16                                 ` Ingo Molnar
2009-01-22 22:16                                   ` Ingo Molnar
2009-01-22 22:24                                   ` Pekka Enberg
2009-01-23  0:16                                 ` Andrew Morton
2009-01-23  0:30                                   ` Greg KH
2009-01-09  2:30     ` Harvey Harrison
2009-01-09 11:25     ` KOSAKI Motohiro
2009-01-09 12:02     ` Alan Cox
2009-01-09 21:56       ` Linus Torvalds
2009-01-09 22:08         ` Andrew Morton
2009-01-09 22:12           ` Linus Torvalds
2009-01-09 22:26             ` Alan Cox
2009-01-09 22:36               ` Harvey Harrison
2009-01-11  3:01         ` Phillip Lougher
2009-01-11  3:06           ` H. Peter Anvin
2009-01-09 16:32     ` Geert Uytterhoeven
2009-01-09 16:32       ` Geert Uytterhoeven

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4978EBE1.9080403@oracle.com \
    --to=randy.dunlap@oracle.com \
    --cc=akpm@linux-foundation.org \
    --cc=davej@redhat.com \
    --cc=geert@linux-m68k.org \
    --cc=gregkh@suse.de \
    --cc=hch@infradead.org \
    --cc=joern@logfs.org \
    --cc=kay.sievers@vrfy.org \
    --cc=kernel@linuxace.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lkml@davidb.org \
    --cc=mingo@elte.hu \
    --cc=phillip@lougher.demon.co.uk \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.