[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.022 / U:52.036 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site