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 ...
Regards,
Paddy
--
Perl 6 will give you the big knob. -- Larry Wall
Reply to: