Re: removing existing working drivers via staging

[Justin P. Mattock]

Ingo Molnar wrote:
> * david@xxxxxxx<david@xxxxxxx>  wrote:
>
>    
> > On Thu, 15 Oct 2009, Ingo Molnar wrote:
> >
> >      
> > > * 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:
> > >        
> > 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@xxxxxxxxxxxxxxx
> 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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/