Re: removing existing working drivers via staging

From: Greg KH
Date: Thu Oct 15 2009 - 14:56:13 EST


On Thu, Oct 15, 2009 at 08:20:12PM +0200, Bartlomiej Zolnierkiewicz wrote:
> On Thursday 15 October 2009 19:49:32 Greg KH wrote:
> > On Thu, Oct 15, 2009 at 07:42:40PM +0200, Bartlomiej Zolnierkiewicz wrote:
> > > On Thursday 15 October 2009 18:47:26 Greg KH wrote:
> > > > On Thu, Oct 15, 2009 at 09:39:51AM -0700, david@xxxxxxx wrote:
> > > > > however, what I think I saw proposed was to move drivers that need to be
> > > > > 'cleaned up', to staging and then dropping them if they don't get cleaned.
> > > >
> > > > What is "proposed" is the following:
> > > >
> > > > - For drivers currently in the kernel tree, that the subsystem
> > > > maintainer, for whatever reason, feels is obsolete / broken /
> > > > needs major cleaning / wants to get rid of, can be submitted
> > > > to the staging maintainer to be moved to the drivers/staging/
> > > > directory.
> > >
> > > This is insanity and opens a door for various forms of abuse.
> >
> > What do you mean by this? What kind of "abuse"?
>
> Typical situation:
>
> You have driver for _really_ difficult hardware used by minority of total
> users of a given subsystem. Said driver has no major problems except being
> f*cking complicated (because of hardware) so it stays in the way of future
> changes.
>
> With the current system people making bigger changes have to comprehend
> that difficult stuff [*]. This is a good thing in the long-term since it
> results in the better overall system understanding, better knowledge of
> "DO's and DON'T's" and better users' experience.
>
> Now with the proposed scheme it is sufficient to throw said driver into
> staging for few weeks and make future changes. Before users even notice
> and complain they are screwed already since bringing the driver back is
> no longer possible without big effort (+ subsystem is still evolving)..

But a driver in staging still has to be able to build, api changes are
not able to be ignored in it.

> This will result in a "new kernel new hardware" world that some distro
> people have been silently trying to accomplish and in this brave new world
> few key people have way too much advantage over everyone else.

I don't understand what you are referring to here.

How about we take it one proposed (real) situation at a time here? If
anyone objects to what is going on, please let me know.

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/