Re: removing existing working drivers via staging

[Ingo Molnar <mingo@elte.hu>]

* 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