linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Kyle McMartin <kyle@redhat.com>
To: Greg KH <gregkh@suse.de>
Cc: Dave Jones <davej@redhat.com>, 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 17:50:26 -0500	[thread overview]
Message-ID: <20090122225025.GA21879@bombadil.infradead.org> (raw)
In-Reply-To: <20090122215817.GA27609@suse.de>

Playing devil's advocate here...

On Thu, Jan 22, 2009 at 01:58:17PM -0800, Greg KH wrote:
> > * 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.
> 
> That's up to you as a distro to handle, not much I can do there.
> 
> But, if you want a recommendation, some of the drivers in staging came
> from the Fedora kernel tree, so you should be enabling them :)
> 

Just at76, I think.

> What is wrong with it?  Bugs are getting fixed, people are getting use
> out of their hardware (hell, Linus is even using one of the drivers),
> and lots of developers are cutting their teeth on helping out.
> 

Why does it need to be upstream for someone to cut their teeth helping
out?

> If you don't like it, just disable it in your kernel packages, or
> instantly close out the bugs.  The drivers in staging has already helped
> out some distros by virtue of including newer drivers than they were
> mistakenly using at the time (Ubuntu, I'm looking at you...)
> 
> And again, it's helped out users, which is the most important thing
> here.
> 

What concerns me is the precedent this sets. If "getting something
upstream" now means "getting something into staging" then we've failed
our users since there's no longer any motivation for a vendor to invest
in all but the most cursory work on a Linux driver.

I think we have higher standards to live up to than that.

I agree that this is a much better plan than all the distros
individually collecting all the shit drivers themselves and (well, for
some of them) fixing the most egregious of crap and not getting fixes
back upstream because they've all frozen on different versions. But
still.

(I also think TAINT_CRAP is kind of an insulting name for things which
are really Linux-targetted features that just haven't had thorough
enough review. Evgeniy Polyakov's work comes to mind... it's really
comparing apples to a bunch of festering pieces of turd. While I'm sure
he's happy to have gotten his stuff in for more review, is it likely to
actually get more review than it would with weekly mailing list
postings? Maybe, who am I to say... I do think labelling his work crap
by virtue of the directory it resides in is fairly silly.)

</rant off>

Yeah, I realize it's fairly hypocritical for me to criticize given I
used to work on Ubuntu, but if it makes anyone feel any better, I didn't
like the idea of shipping things we wouldn't possibly support there
either.

While it is nice to justify things as "but users want it" they also
don't want a driver that reads files out of /etc and panics their kernel
or trashes their data. Which is why we won't enable this in Fedora. We
have enough maintenance burden with the utter horrowshow drivers we
claim as "maintained" in mainline already. If people really think having
something in mainline increases the odds something will get cleaned up,
I urge them to look at any scsi, network, or isdn driver from more than
five years ago. Make sure you bring a barf bag.

In summary, I don't know, this is one of those damned if you do, damned
if you don't paradoxes. ;-) But if you suck in a driver that barfs all
over your filesystem, because it was allowed to be turned in with zero
review, are you going to be the one to tell the user "ha ha, sucks to be
you?" I sure wouldn't want to be.

regards, Kyle

  parent reply	other threads:[~2009-01-22 22:50 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
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 [this message]
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=20090122225025.GA21879@bombadil.infradead.org \
    --to=kyle@redhat.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=kyle@infradead.org \
    --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 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).