linux-fsdevel.vger.kernel.org archive mirror
 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>
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: 50+ 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 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 19:37             ` David Brown
2009-01-09 21:19               ` Jörn Engel
2009-01-10 12:43                 ` Ingo Molnar
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 22:15                                   ` 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: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

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=mingo@elte.hu \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).