public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
To: Greg KH <gregkh@suse.de>
Cc: david@lang.hm, Stefan Richter <stefanr@s5r6.in-berlin.de>,
	"linux-kernel" <linux-kernel@vger.kernel.org>,
	Ingo Molnar <mingo@elte.hu>
Subject: Re: removing existing working drivers via staging
Date: Thu, 15 Oct 2009 20:20:12 +0200	[thread overview]
Message-ID: <200910152020.13080.bzolnier@gmail.com> (raw)
In-Reply-To: <20091015174932.GA3595@suse.de>

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@lang.hm 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)..

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.

[*] Booing current maintainer and forking also sometimes works.
(Though old drivers are still in place in such situation.)


  reply	other threads:[~2009-10-15 18:24 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-10-15  5:27 removing existing working drivers via staging david
2009-10-15 16:33 ` Stefan Richter
2009-10-15 16:39   ` david
2009-10-15 16:47     ` Greg KH
2009-10-15 17:42       ` Bartlomiej Zolnierkiewicz
2009-10-15 17:49         ` Greg KH
2009-10-15 18:20           ` Bartlomiej Zolnierkiewicz [this message]
2009-10-15 18:46             ` Greg KH
2009-10-15 18:58               ` Bartlomiej Zolnierkiewicz
2009-10-15 19:02               ` david
2009-10-15 19:16                 ` Ingo Molnar
2009-10-15 19:38                   ` david
2009-10-15 19:47                     ` Stefan Richter
2009-10-15 19:57                       ` david
2009-10-27  4:23                         ` david
2009-10-27  5:22                           ` David Miller
2009-10-27  5:50                             ` david
2009-10-27 14:06                               ` Greg KH
2009-10-27 10:45                           ` Alan Cox
2009-10-16  7:40                     ` Ingo Molnar
2009-10-16  7:58                       ` Justin P. Mattock
2009-10-15 19:40                 ` Stefan Richter
2009-10-15 19:49                   ` david
2009-10-15 20:56                     ` Greg KH
2009-10-16  7:25                     ` Ingo Molnar
2009-10-15 18:44         ` Alan Cox
2009-10-15 19:24         ` David Miller
2009-10-17 17:27       ` Pavel Machek
2009-10-19  7:32         ` Ingo Molnar
2009-10-19  7:40           ` Greg KH

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=200910152020.13080.bzolnier@gmail.com \
    --to=bzolnier@gmail.com \
    --cc=david@lang.hm \
    --cc=gregkh@suse.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=stefanr@s5r6.in-berlin.de \
    /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