On Mon, Oct 11, 2004 at 11:42:57AM +0100, Matthew Garrett wrote: > paddy <[EMAIL PROTECTED]> wrote: > > On Mon, Oct 11, 2004 at 10:42:58AM +0100, Matthew Garrett wrote: > >> I think those are arguments for making releases more quickly, rather > >> than anything else. > > > > I'm not sure about that, graphics hardware, for example, is far faster > > moving > > than stable. And there are forces pulling both ways on the stable release > > cycle. > > If we aimed at a new stable release about once a year (which obviously > requires providing support for more than one release at once, but > still), that would be much less of a problem.
I'm wondering if the long-term solution may be to extend security.d.o support for some important subset (say standard, for the sake of argument), allowing the main release cycle a little more freedom to float to a different level if that is where it wants to go. > > The kernel and X are both at least somewhat modular, how unrealistic > > is it to think in terms of backporting just the drivers ? And would that > > be better? > > Adding new drivers is usually fairly easy and probably wouldn't cause > any problems. Backporting more recent versions of existing drivers isn't > desperately hard, That's good ... > but newer drivers frequently cause regressions in > existing hardware support. Without going through a full release cycle, > it's difficult to track down whether or not something has broken. If all drivers are in one large package, then this is a huge problem, but if they can be packaged individually, much less so I think. Even without individual packaging, volatile might one-day still make a home for such things (but I _won't_ be helping! :) It it easy to imagine how one might admit a single driver onto the volatile archive ... Regards, Paddy -- Perl 6 will give you the big knob. -- Larry Wall