removing existing working drivers via staging

removing existing working drivers via staging

[david]

I missed this discussion in the thread "Moving drivers into 
staging (was Re: [GIT PULL] SCSI fixes for 2.6.32-" and I suspect that 
many others did as well

for those that missed it, as I understand it the proposal is that 'ugly' 
(working drivers that don't do things the kernel way and are perceived as 
not being commonly used anymore) drivers will get moved into staging, and 
if the driver maintainers do not clean them up within 6-9 months they will 
be removed entirely.

the expectation is that if there are no maintainers for the driver who 
care enough to do the cleanup they should be removed (with interested 
users being able to take over maintaining the drivers if there the 
maintainers are MIA)

I have several reactions to this

I think that 6-9 months (2-3 releases) is _far_ too short for users to 
notice. most users will be using a distro kernel that is on a release 
cycle longer than this (even if they are not using a 'enterprise' distro), 
so their first inkling of a problem will be the driver disappearing on 
them. Yes the driver can be recovered through git, bit at that point 
there is going to be catch-up changes to make.

What happened to the desire that Linux would be able to use anything, and 
once a driver was upstream changes to the kernel that would break it 
should be fixed by whoever is introducing those changes? This seems to be 
moving in the direction of only having drivers for fairly current, fairly 
common hardware.

David Lang

Re: removing existing working drivers via staging

[Stefan Richter]

david@lang.hm wrote:
> I missed this discussion in the thread "Moving drivers into 
> staging (was Re: [GIT PULL] SCSI fixes for 2.6.32-" and I suspect that 
> many others did as well
> 
> for those that missed it, as I understand it the proposal is that 'ugly' 
> (working drivers that don't do things the kernel way and are perceived as 
> not being commonly used anymore) drivers will get moved into staging, and

There was mention of "abandoned and unused" drivers (rather than "not
/commonly/ used anymore"), see e.g.
http://linux.derkeiler.com/Mailing-Lists/Kernel/2009-10/msg05204.html
(2nd to last paragraph; thread continues with Greg's follow-up).

> if the driver maintainers do not clean them up within 6-9 months they will 
> be removed entirely.
> 
> the expectation is that if there are no maintainers for the driver who 
> care enough to do the cleanup they should be removed (with interested 
> users being able to take over maintaining the drivers if there the 
> maintainers are MIA)
> 
> I have several reactions to this
> 
> I think that 6-9 months (2-3 releases) is _far_ too short for users to 
> notice. most users will be using a distro kernel that is on a release 
> cycle longer than this (even if they are not using a 'enterprise' distro), 
> so their first inkling of a problem will be the driver disappearing on 
> them. Yes the driver can be recovered through git, bit at that point 
> there is going to be catch-up changes to make.
> 
> What happened to the desire that Linux would be able to use anything, and 
> once a driver was upstream changes to the kernel that would break it 
> should be fixed by whoever is introducing those changes? This seems to be 
> moving in the direction of only having drivers for fairly current, fairly 
> common hardware.

AFAIU, mostly just code which is known to _not work_ anymore or has been
functionally replaced by an alternative drops out of the mainline.  This
idea of using drivers/staging/ in the process is surely not going to
change that in principle; it will only raise awareness among active
kernel developers better than feature-removal-schedule.txt can do.
-- 
Stefan Richter
-=====-==--= =-=- -====
http://arcgraph.de/sr/

Re: removing existing working drivers via staging

[david]

On Thu, 15 Oct 2009, Stefan Richter wrote:

> david@lang.hm wrote:
>> I missed this discussion in the thread "Moving drivers into
>> staging (was Re: [GIT PULL] SCSI fixes for 2.6.32-" and I suspect that
>> many others did as well
>>
>> for those that missed it, as I understand it the proposal is that 'ugly'
>> (working drivers that don't do things the kernel way and are perceived as
>> not being commonly used anymore) drivers will get moved into staging, and
>
> There was mention of "abandoned and unused" drivers (rather than "not
> /commonly/ used anymore"), see e.g.
> http://linux.derkeiler.com/Mailing-Lists/Kernel/2009-10/msg05204.html
> (2nd to last paragraph; thread continues with Greg's follow-up).

how can you tell if a driver is "unused"? (other than leaving it broken 
for several years and getting no complaints)

>> if the driver maintainers do not clean them up within 6-9 months they will
>> be removed entirely.
>>
>> the expectation is that if there are no maintainers for the driver who
>> care enough to do the cleanup they should be removed (with interested
>> users being able to take over maintaining the drivers if there the
>> maintainers are MIA)
>>
>> I have several reactions to this
>>
>> I think that 6-9 months (2-3 releases) is _far_ too short for users to
>> notice. most users will be using a distro kernel that is on a release
>> cycle longer than this (even if they are not using a 'enterprise' distro),
>> so their first inkling of a problem will be the driver disappearing on
>> them. Yes the driver can be recovered through git, bit at that point
>> there is going to be catch-up changes to make.
>>
>> What happened to the desire that Linux would be able to use anything, and
>> once a driver was upstream changes to the kernel that would break it
>> should be fixed by whoever is introducing those changes? This seems to be
>> moving in the direction of only having drivers for fairly current, fairly
>> common hardware.
>
> AFAIU, mostly just code which is known to _not work_ anymore or has been
> functionally replaced by an alternative drops out of the mainline.  This
> idea of using drivers/staging/ in the process is surely not going to
> change that in principle; it will only raise awareness among active
> kernel developers better than feature-removal-schedule.txt can do.

I don't disagree with dropping code that has been replaced by an 
alternative. and I don't disagree much with dropping broken code.

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.

David Lang

Re: removing existing working drivers via staging

[Greg KH]

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.
	- For a file to be moved into this directory, all of the normal
	  staging rules apply, including most importantly, a TODO file
	  listing what needs to be done to the driver in order for it to
	  be moved back into the main portion of the kernel tree.
	- If, after a period of 3 releases, no work has been done on the
	  driver by anyone, the driver will be removed from the staging
	  tree, just like all drivers in the staging tree.

Note, as always, if a driver wants to come back from removal of the
staging tree, a simple email to the staging maintainer, along with the
promise that work will be done, is all it takes to resurrect it.

Sound good?

Now, where to put these "rules"?  Any suggestions?

thanks,

greg k-h

Re: removing existing working drivers via staging

[Bartlomiej Zolnierkiewicz]

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.

Re: removing existing working drivers via staging

[Greg KH]

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"?

Re: removing existing working drivers via staging

[Bartlomiej Zolnierkiewicz]

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.)

Re: removing existing working drivers via staging

[Greg KH]

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

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

Re: removing existing working drivers via staging

[Bartlomiej Zolnierkiewicz]

On Thursday 15 October 2009 20:46:56 Greg KH wrote:
> 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@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)..
> 
> But a driver in staging still has to be able to build, api changes are
> not able to be ignored in it.

Sure, it will build at the of being submitted to staging..

> > 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.

See my PM.

Re: removing existing working drivers via staging

[david]

On Thu, 15 Oct 2009, Greg KH wrote:

> 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@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)..
>
> But a driver in staging still has to be able to build, api changes are
> not able to be ignored in it.

a driver in staging will be able to build, but a driver that was removed 
after 6-9 months that a user discovered the removal of a year later when 
they upgraded to a new distro release (say a normal ubuntu release after 
staying on the old one for the 18 month support period) is likely to need 
significant work to catch up with kernel changes in the meanwhile.

David Lang

Re: removing existing working drivers via staging

[Ingo Molnar]

* david@lang.hm <david@lang.hm> wrote:

>> But a driver in staging still has to be able to build, api changes 
>> are not able to be ignored in it.
>
> a driver in staging will be able to build, but a driver that was 
> removed after 6-9 months that a user discovered the removal of a year 
> later when they upgraded to a new distro release (say a normal ubuntu 
> release after staying on the old one for the 18 month support period) 
> is likely to need significant work to catch up with kernel changes in 
> the meanwhile.

Where do you get the 6-9 months from? Greg said he'll wait 3 kernel 
releases. Here's the timeline of that:

 - release x
 - [A] driver moves into drivers/staging/ in the staging tree
 - release x+1
 - drivers/staging/ change gets merged in the x+2 merge window
 - release x+2 - first kernel with the driver in staging
 - release x+3
 - release x+4
 - driver gets removed in the staging tree
 - release x+5 - 3 kernel releases passed - now it's removed
 - removal propagates upstream in the x+6 merge window
 - [B] release x+6

from the decision to move it into staging there's 4 kernel releases 
during which the information is known, and 3 full kernel releases with 
the driver is actually moved, and even in the 4th cycle there's still 3 
months to undo the removal if there's objections (i.e. it's a 
regression).

This means the timeline is 4*3 = 12 months _at minimum_. In practice it 
will be more than a year - up to 1.5 years. Well within most distros ~3 
months upstream kernel update schedule.

And if a distro does not follow the upstream kernel ... that's a self 
inflicted wound and a distro problem really.

	Ingo

Re: removing existing working drivers via staging

[david]

On Thu, 15 Oct 2009, Ingo Molnar wrote:

> * david@lang.hm <david@lang.hm> wrote:
>
>>> But a driver in staging still has to be able to build, api changes
>>> are not able to be ignored in it.
>>
>> a driver in staging will be able to build, but a driver that was
>> removed after 6-9 months that a user discovered the removal of a year
>> later when they upgraded to a new distro release (say a normal ubuntu
>> release after staying on the old one for the 18 month support period)
>> is likely to need significant work to catch up with kernel changes in
>> the meanwhile.
>
> Where do you get the 6-9 months from? Greg said he'll wait 3 kernel
> releases. Here's the timeline of that:

that was the timeframe listed in the prior discussion, 3 kernel releases * 
2-3 months/release works out to this

> - release x
> - [A] driver moves into drivers/staging/ in the staging tree
> - release x+1
> - drivers/staging/ change gets merged in the x+2 merge window
> - release x+2 - first kernel with the driver in staging
> - release x+3
> - release x+4
> - driver gets removed in the staging tree
> - release x+5 - 3 kernel releases passed - now it's removed
> - removal propagates upstream in the x+6 merge window
> - [B] release x+6

I would have seen this as

release x
driver moves into staging
release x+1
release x+2
release x+3
driver is removed
release x+4 no longer has the driver

> from the decision to move it into staging there's 4 kernel releases
> during which the information is known, and 3 full kernel releases with
> the driver is actually moved, and even in the 4th cycle there's still 3
> months to undo the removal if there's objections (i.e. it's a
> regression).
>
> This means the timeline is 4*3 = 12 months _at minimum_. In practice it
> will be more than a year - up to 1.5 years. Well within most distros ~3
> months upstream kernel update schedule.

yes, this is well past the distro update cycle for new releases, but not 
within the user update cycle. there are a LOT of people who don't upgrade 
every 6 months. every distro provides support for at least 12 months, if 
not more. and even then there are a lot of people who drop out of their 
distro support before they upgrade.

it's these users who will discover the missing driver and care about it, 
not the distros.

personally, I try to do a kernel update every year (if security concerns 
in a feature that I have compiled in don't force me to upgrade sooner) 
sometimes with a distro upgrade, sometimes not.

David Lang

Re: removing existing working drivers via staging

[Stefan Richter]

david@lang.hm wrote:
> it's these users who will discover the missing driver and care about it,
> not the distros.

I think we are talking about stuff of which users will typically
discover that it plainly doesn't work long before it vanishes from any
kernel distribution, or of which there is a superior alternative already
available.
-- 
Stefan Richter
-=====-==--= =-=- -====
http://arcgraph.de/sr/

Re: removing existing working drivers via staging

[david]

On Thu, 15 Oct 2009, Stefan Richter wrote:

> david@lang.hm wrote:
>> it's these users who will discover the missing driver and care about it,
>> not the distros.
>
> I think we are talking about stuff of which users will typically
> discover that it plainly doesn't work long before it vanishes from any
> kernel distribution, or of which there is a superior alternative already
> available.

if there's a superior alternative already available staging isn't needed 
(like the e1000 split), but I have also seen many new systems added to the 
kernel that the author thinks covers all the old ones, only to find out 
when people get it in the real world that it doesn't cover all existing 
hardware. but this is an existing problem that is already being handled.



if it clearly doesn't work that is also fine with me.

however, that is not the criteria that has been expressed.

from earlier in this thread

         - 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.

it's the 'needs major cleaning' and 'wants to get rid of' portions that 
concern me the most.

'obsolete' can mean that there is a superior alternative available, or it 
could mean that the hardware the driver supports has not been manufactured 
in several years (or, depending who you ask, several weeks ;-)

David Lang

Re: removing existing working drivers via staging

[david]

for those who were reading this thread, the topic has come up again in the 
thread titled

[PATCH 1/4] strip: move driver to staging

where a driver is being moved to staging because it does not have a 
maintainer and the only changes to it for some time have been due to 
kernel API changes.

the maintainer of the area feels that it's too much work to allow the 
driver to remain because it must be updated when kernel APIs change.


this is exactly the 'wants to get rid of' category I mentioned being 
concerned about below.


I don't know what was decided at the kernel summit where this was 
discussed, how easy is it supposed to be to drop drivers out of the 
kernel?

David Lang

On Thu, 15 Oct 2009, david@lang.hm wrote:

> Date: Thu, 15 Oct 2009 12:57:49 -0700 (PDT)
> From: david@lang.hm
> To: Stefan Richter <stefanr@s5r6.in-berlin.de>
> Cc: Ingo Molnar <mingo@elte.hu>, Greg KH <gregkh@suse.de>,
>     Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>,
>     linux-kernel <linux-kernel@vger.kernel.org>
> Subject: Re: removing existing working drivers via staging
> 
> On Thu, 15 Oct 2009, Stefan Richter wrote:
>
>> david@lang.hm wrote:
>>> it's these users who will discover the missing driver and care about it,
>>> not the distros.
>> 
>> I think we are talking about stuff of which users will typically
>> discover that it plainly doesn't work long before it vanishes from any
>> kernel distribution, or of which there is a superior alternative already
>> available.
>
> if there's a superior alternative already available staging isn't needed 
> (like the e1000 split), but I have also seen many new systems added to the 
> kernel that the author thinks covers all the old ones, only to find out when 
> people get it in the real world that it doesn't cover all existing hardware. 
> but this is an existing problem that is already being handled.
>
>
>
> if it clearly doesn't work that is also fine with me.
>
> however, that is not the criteria that has been expressed.
>
> from earlier in this thread
>
>        - 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.
>
> it's the 'needs major cleaning' and 'wants to get rid of' portions that 
> concern me the most.
>
> 'obsolete' can mean that there is a superior alternative available, or it 
> could mean that the hardware the driver supports has not been manufactured in 
> several years (or, depending who you ask, several weeks ;-)
>
> David Lang
>

Re: removing existing working drivers via staging

[David Miller]

From: david@lang.hm
Date: Mon, 26 Oct 2009 21:23:35 -0700 (PDT)

> where a driver is being moved to staging because it does not have a
> maintainer and the only changes to it for some time have been due to
> kernel API changes.

It's also in a non-working condition and we are very confident
nobody is using it.

It hasn't been maintained at all for years, it's just taking up
space.

Re: removing existing working drivers via staging

[david]

On Mon, 26 Oct 2009, David Miller wrote:

> From: david@lang.hm
> Date: Mon, 26 Oct 2009 21:23:35 -0700 (PDT)
>
>> where a driver is being moved to staging because it does not have a
>> maintainer and the only changes to it for some time have been due to
>> kernel API changes.
>
> It's also in a non-working condition and we are very confident
> nobody is using it.
>
> It hasn't been maintained at all for years, it's just taking up
> space.

this is the first I have seen anyone say that the driver doesn't work, 
everything prior had been "I don't know that it works, do you?"

I agree that it's unlikly that many people are using this.

David Lang

Re: removing existing working drivers via staging

[Greg KH]

On Mon, Oct 26, 2009 at 10:50:25PM -0700, david@lang.hm wrote:
> I agree that it's unlikly that many people are using this.

Then why argue about it?

Re: removing existing working drivers via staging

[Alan Cox]

> this is exactly the 'wants to get rid of' category I mentioned being 
> concerned about below.

Why are you concerned, its dead, its defunct, nobody cares, nobody uses
it. The same is true of a lot of other junk drivers we have and need to
get rid of.

> I don't know what was decided at the kernel summit where this was 
> discussed, how easy is it supposed to be to drop drivers out of the 
> kernel?

If there is someone with the hardware its a trivial git command to put it
back and they can then maintain it, but I'm pretty sure that there won't
be anyone using this ancient hardware and I really doubt the code even
works after the big tty re-arrange.

There is a difference between ancient junk people care about (however
crazy) and stuff that is just dead and slowing real work (and I have
several serial drivers I want to bit bucket such as rio and esp)

Re: removing existing working drivers via staging

[Ingo Molnar]

* david@lang.hm <david@lang.hm> wrote:

> On Thu, 15 Oct 2009, Ingo Molnar wrote:
>
>> * david@lang.hm <david@lang.hm> wrote:
>>
>>>> But a driver in staging still has to be able to build, api changes
>>>> are not able to be ignored in it.
>>>
>>> a driver in staging will be able to build, but a driver that was
>>> removed after 6-9 months that a user discovered the removal of a year
>>> later when they upgraded to a new distro release (say a normal ubuntu
>>> release after staying on the old one for the 18 month support period)
>>> is likely to need significant work to catch up with kernel changes in
>>> the meanwhile.
>>
>> Where do you get the 6-9 months from? Greg said he'll wait 3 kernel
>> releases. Here's the timeline of that:
>
> that was the timeframe listed in the prior discussion, 3 kernel releases 
> * 2-3 months/release works out to this

We do 4 kernel releases a year - that's almost exactly 3 months per 
release - not 2-3 months.

It's one release per season / per quarter. That is a very natural 
frequency for releases: both in the biological and in the socio/economic 
spectrum.

Look at the release dates for version x, x-4 and x-8, they line up very 
nicely:

  v2.6.31: Date:   Wed Sep 9 15:13:59 2009 -0700
  v2.6.27: Date:   Thu Oct 9 15:13:53 2008 -0700
  v2.6.23: Date:   Tue Oct 9 13:31:38 2007 -0700

And that kind of release date reliability is intentional and i think can 
be expected to continue in the future as well. If you want to base 
products on Linux you really want to know the latencies of upstreaming 
and what to know when a driver or a kernel feature you'll rely on will 
be released.

[ .31 was a bit earlier - partly due to the KS (which always delays the
  cycle a tiny bit so it's good to save up for it) - and i'd personally
  not mind if we did the .33 merge window before Christmas, to avoid the
  distraction right in the middle of the holliday season. ]

Plus the inevitable fuzz of 1-2 weeks depending on the momentary QA 
situation.

	Ingo

Re: removing existing working drivers via staging

[Justin P. Mattock]

Ingo Molnar wrote:
> * david@lang.hm<david@lang.hm>  wrote:
>
>    
>> On Thu, 15 Oct 2009, Ingo Molnar wrote:
>>
>>      
>>> * david@lang.hm<david@lang.hm>  wrote:
>>>
>>>        
>>>>> But a driver in staging still has to be able to build, api changes
>>>>> are not able to be ignored in it.
>>>>>            
>>>> a driver in staging will be able to build, but a driver that was
>>>> removed after 6-9 months that a user discovered the removal of a year
>>>> later when they upgraded to a new distro release (say a normal ubuntu
>>>> release after staying on the old one for the 18 month support period)
>>>> is likely to need significant work to catch up with kernel changes in
>>>> the meanwhile.
>>>>          
>>> Where do you get the 6-9 months from? Greg said he'll wait 3 kernel
>>> releases. Here's the timeline of that:
>>>        
>> that was the timeframe listed in the prior discussion, 3 kernel releases
>> * 2-3 months/release works out to this
>>      
>
> We do 4 kernel releases a year - that's almost exactly 3 months per
> release - not 2-3 months.
>
> It's one release per season / per quarter. That is a very natural
> frequency for releases: both in the biological and in the socio/economic
> spectrum.
>
> Look at the release dates for version x, x-4 and x-8, they line up very
> nicely:
>
>    v2.6.31: Date:   Wed Sep 9 15:13:59 2009 -0700
>    v2.6.27: Date:   Thu Oct 9 15:13:53 2008 -0700
>    v2.6.23: Date:   Tue Oct 9 13:31:38 2007 -0700
>
> And that kind of release date reliability is intentional and i think can
> be expected to continue in the future as well. If you want to base
> products on Linux you really want to know the latencies of upstreaming
> and what to know when a driver or a kernel feature you'll rely on will
> be released.
>
> [ .31 was a bit earlier - partly due to the KS (which always delays the
>    cycle a tiny bit so it's good to save up for it) - and i'd personally
>    not mind if we did the .33 merge window before Christmas, to avoid the
>    distraction right in the middle of the holliday season. ]
>
> Plus the inevitable fuzz of 1-2 weeks depending on the momentary QA
> situation.
>
> 	Ingo
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>
>    
man!! well put ingo,well put..
like I like to do:
CONFIG_INGO=y
regardless of what people say, the cycle is
perfect, as for the staging tough to say, I haven't found
anything in there yet that I need, but can only image I would..

Hope you guys enjoy japan for the kernel summit,
and BTW: please checkout "if you have time":
sasuke or "ninja warriror"....


Justin P. Mattock

Re: removing existing working drivers via staging

[Stefan Richter]

david@lang.hm wrote:
> a driver in staging will be able to build, but a driver that was removed
> after 6-9 months that a user discovered the removal of a year later when
> they upgraded to a new distro release (say a normal ubuntu release after
> staying on the old one for the 18 month support period) is likely to
> need significant work to catch up with kernel changes in the meanwhile.

I don't think this new mechanism is meant to be, or can ever be, a way
to remove things that work and that users need.

Hence the timeline of 3 releases per <20091015164726.GA10125@suse.de>
affects developers/ janitors much more than end users.
-- 
Stefan Richter
-=====-==--= =-=- -====
http://arcgraph.de/sr/

Re: removing existing working drivers via staging

[david]

On Thu, 15 Oct 2009, Stefan Richter wrote:

> david@lang.hm wrote:
>> a driver in staging will be able to build, but a driver that was removed
>> after 6-9 months that a user discovered the removal of a year later when
>> they upgraded to a new distro release (say a normal ubuntu release after
>> staying on the old one for the 18 month support period) is likely to
>> need significant work to catch up with kernel changes in the meanwhile.
>
> I don't think this new mechanism is meant to be, or can ever be, a way
> to remove things that work and that users need.

the problem I have is that the criteria that I have seen voiced for why 
something would move into staging does not require that it not work. it 
just requires that it need 'cleanup' of some sort.

removing something that worked always runs a significant risk that someone 
out there 'needs' it (sometimes removing something that's broken, but 
works in some cases causes similar problems)

> Hence the timeline of 3 releases per <20091015164726.GA10125@suse.de>
> affects developers/ janitors much more than end users.

it may be that I've jumped the gun here with my concerns, and should just 
wait until something actually gets moved to staging to see what the actual 
policies are going to be in practice, but the policies as written seem to 
be very loose.

David Lang

Re: removing existing working drivers via staging

[Greg KH]

On Thu, Oct 15, 2009 at 12:49:40PM -0700, david@lang.hm wrote:
> On Thu, 15 Oct 2009, Stefan Richter wrote:
> 
> > david@lang.hm wrote:
> >> a driver in staging will be able to build, but a driver that was removed
> >> after 6-9 months that a user discovered the removal of a year later when
> >> they upgraded to a new distro release (say a normal ubuntu release after
> >> staying on the old one for the 18 month support period) is likely to
> >> need significant work to catch up with kernel changes in the meanwhile.
> >
> > I don't think this new mechanism is meant to be, or can ever be, a way
> > to remove things that work and that users need.
> 
> the problem I have is that the criteria that I have seen voiced for why 
> something would move into staging does not require that it not work. it 
> just requires that it need 'cleanup' of some sort.
> 
> removing something that worked always runs a significant risk that someone 
> out there 'needs' it (sometimes removing something that's broken, but 
> works in some cases causes similar problems)
> 
> > Hence the timeline of 3 releases per <20091015164726.GA10125@suse.de>
> > affects developers/ janitors much more than end users.
> 
> it may be that I've jumped the gun here with my concerns, and should just 
> wait until something actually gets moved to staging to see what the actual 
> policies are going to be in practice, but the policies as written seem to 
> be very loose.

Loose is good, it gives us much room in which to work with, taking each
case as it comes.

Let's all see how it goes before declaring this whole thing is broken.
There's no reason we can't constantly reevaluate it as time goes on, as
nothing we ever do here is set in stone :)

thanks,

greg "the only constant is change" k-h

Re: removing existing working drivers via staging

[Ingo Molnar]

* david@lang.hm <david@lang.hm> wrote:

>> Hence the timeline of 3 releases per <20091015164726.GA10125@suse.de>
>> affects developers/ janitors much more than end users.
>
> it may be that I've jumped the gun here with my concerns, and should 
> just wait until something actually gets moved to staging to see what 
> the actual policies are going to be in practice, but the policies as 
> written seem to be very loose.

Note that nothing has changed: the same fine folks who worked for 15+ 
years to give you the OS with the most built-in drivers on this planet 
(more than 3000 drivers today and counting) are handling this too.

Please dont assume that this trend is now being reversed - to the 
contrary - Linux being able to boot out of box on 99% of the systems
out there is one of our biggest strengths.

	Ingo

Re: removing existing working drivers via staging

[Alan Cox]

On Thu, 15 Oct 2009 19:42:40 +0200
Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> 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.

It seems very sensible to me. It could be abused but that overlooks the
fact that Greg administers staging, the kernel community sees everything
and even if Greg doesn't keep things in order Linus would.

There are a pile of serial drivers that I think should get this
treatement (actually I was simply going to submit removal patches for
rio, riscom8, esp and a couple of others until this idea occurred)

Re: removing existing working drivers via staging

[David Miller]

From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Date: Thu, 15 Oct 2009 19:42:40 +0200

> 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.

Being a maintainer, period, give the person these kinds of "abusive"
powers.  The same thing that controls them already, will still control
them in this case with this new rule.  And that's public pressure and
the will of the larger developer community.

Re: removing existing working drivers via staging

[Pavel Machek]

On Thu 2009-10-15 09: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.
> 	- For a file to be moved into this directory, all of the normal
> 	  staging rules apply, including most importantly, a TODO file
> 	  listing what needs to be done to the driver in order for it to
> 	  be moved back into the main portion of the kernel tree.
> 	- If, after a period of 3 releases, no work has been done on the
> 	  driver by anyone, the driver will be removed from the staging
> 	  tree, just like all drivers in the staging tree.
> 
> Note, as always, if a driver wants to come back from removal of the
> staging tree, a simple email to the staging maintainer, along with the
> promise that work will be done, is all it takes to resurrect it.
> 
> Sound good?
> 
> Now, where to put these "rules"?  Any suggestions?

I'm not sure it sounds good. It should not be named 'staging' at
least.

								Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: removing existing working drivers via staging

[Ingo Molnar]

* Pavel Machek <pavel@ucw.cz> wrote:

> On Thu 2009-10-15 09: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.
> > 	- For a file to be moved into this directory, all of the normal
> > 	  staging rules apply, including most importantly, a TODO file
> > 	  listing what needs to be done to the driver in order for it to
> > 	  be moved back into the main portion of the kernel tree.
> > 	- If, after a period of 3 releases, no work has been done on the
> > 	  driver by anyone, the driver will be removed from the staging
> > 	  tree, just like all drivers in the staging tree.
> > 
> > Note, as always, if a driver wants to come back from removal of the
> > staging tree, a simple email to the staging maintainer, along with the
> > promise that work will be done, is all it takes to resurrect it.
> > 
> > Sound good?
> > 
> > Now, where to put these "rules"?  Any suggestions?
> 
> I'm not sure it sounds good. It should not be named 'staging' at 
> least.

Why not? It's a good match - a driver gets staged because it's not fit 
for upstream.

The usual staging rules apply regardless of where the driver came from 
(outside or inside the kernel): someone has to care about it and it has 
to be fixed.

	Ingo

Re: removing existing working drivers via staging

[Greg KH]

On Mon, Oct 19, 2009 at 09:32:30AM +0200, Ingo Molnar wrote:
> 
> * Pavel Machek <pavel@ucw.cz> wrote:
> 
> > On Thu 2009-10-15 09: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.
> > > 	- For a file to be moved into this directory, all of the normal
> > > 	  staging rules apply, including most importantly, a TODO file
> > > 	  listing what needs to be done to the driver in order for it to
> > > 	  be moved back into the main portion of the kernel tree.
> > > 	- If, after a period of 3 releases, no work has been done on the
> > > 	  driver by anyone, the driver will be removed from the staging
> > > 	  tree, just like all drivers in the staging tree.
> > > 
> > > Note, as always, if a driver wants to come back from removal of the
> > > staging tree, a simple email to the staging maintainer, along with the
> > > promise that work will be done, is all it takes to resurrect it.
> > > 
> > > Sound good?
> > > 
> > > Now, where to put these "rules"?  Any suggestions?
> > 
> > I'm not sure it sounds good. It should not be named 'staging' at 
> > least.
> 
> Why not? It's a good match - a driver gets staged because it's not fit 
> for upstream.
> 
> The usual staging rules apply regardless of where the driver came from 
> (outside or inside the kernel): someone has to care about it and it has 
> to be fixed.

Exactly, I'll keep the name for now, it's easier that way.

thanks,

greg k-h