[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: about volatile.d.o/n

On Mon, Oct 11, 2004 at 11:42:57AM +0100, Matthew Garrett wrote:
> paddy <paddy@panici.net> 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 ...

Perl 6 will give you the big knob. -- Larry Wall

Reply to: