* david@xxxxxxx <david@xxxxxxx> 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.