Re: removing existing working drivers via staging

Justin P. Mattock
2009-10-16T07:59:45Z

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