Re: [GIT PULL] Squashfs pull request for 2.6.29

[Kyle McMartin]

On Thu, Jan 22, 2009 at 03:04:57PM -0800, Greg KH wrote:
> > Why does it need to be upstream for someone to cut their teeth helping
> > out?
> Because people don't know where to look if it is out-of-the tree.
> Seriously, if it can't be easily found, it's not fixed up.  Proof of
> that is the hundreds of out-of-tree drivers that I have found over the
> past months.

What about the hundreds of utterly crap drivers we have *right now* in
the kernel? Just because something is distributed with the kernel does
*not* mean it will get cleaned up. There's hundreds of counterexamples
to that. If you think moving some of them to drivers/staging to increase
the "visibility" to people looking for low hanging fruit, I can generate
a list...

> > 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.
> 
> Woah, you are changing the conversation here totally.
> 

What if vendor X has decided that they can now save some money by simply
dumping the code at the "hey, I'll take anything" tree instead of
continuing to work with the community, or following the example of people
who do. They can still tell their users "we're upstream, just enable
this CONFIG option and our stuff will work."

> This has nothing to do with "put pressure on a vendor to get their code
> into upstream so that a distro will enable it."  We have vendors today
> working with the staging tree to get their code cleaned up better to get
> it into mergable shape to move over to the main portion of the kernel
> tree.
> 
> Other vendors throw us code and run away.  We handle that as well, by
> doing the work on our own, taking our time.  While that cleanup happens,
> users can use their hardware with Linux without having to find the
> latest version of a driver on a random google code site, and figure out
> how to patch things to handle api changes that have happened since then
> (true story for one of the drivers in staging right now.)
> 

My concern is what was stated above, that vendors who have historically
done the right thing may have less motivation to continue in the future.

I defer to your judgement though.

> > I think we have higher standards to live up to than that.
> 
> The staging tree has NOTHING to do with our coding and acceptance
> standards.  And anyone that thinks otherwise is totally mistaken.
> 

I don't know how you can say this, given. Nothing in there would
make the cut at all... obviously it has a lower barrier to entry. Is
there a maintenance burden imposed on someone for staging? I mean, to
get something in there is someone agreeing to take point on all the
issues?

If its purpose isn't "the staging point for things to get (in theory)
cleaned up because people want convenience now" then what is it?

> > 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.
> 
> I'll take responsibility if such a thing happens.  Fear of such a thing
> is no reason to prevent users from having their hardware work properly
> with Linux.
> 
> Again, I'll point to Linus's laptop that now works properly due to the
> drivers/staging/ tree as a very visible example of this effort actually
> working properly.
> 

I assume this is the eee wireless?

As I said, I'm not (deliberately) trying to be negative. I'm simply
trying to understand the rationale. I'm sorry if I sound that way, but
working on distros has made me horribly pragmatic about these things.

I guess time will tell.

cheers, Kyle

> thanks,
> 
> greg k-h
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/