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
next prev parent 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).