[lkml]   [2009]   [Oct]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: removing existing working drivers via staging

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

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.


 \ /
  Last update: 2009-10-15 21:25    [W:0.085 / U:0.320 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site