Re: gpilotd problem

[abo minkirri apana org au (Donovan Baarda)]

On Mon, Aug 19, 2002 at 02:44:04PM -0700, Jack Coates wrote:
> On Fri, 2002-08-16 at 08:21, Fr?d?ric Crozat wrote:
> > Le ven 16/08/2002 ? 16:44, Jack Coates a ?crit :
> > > On Fri, 2002-08-16 at 07:31, Fr?d?ric Crozat wrote:
[...]
> > > > Le ven 16/08/2002 ? 06:56, Jack Coates a ?crit :
> > > But let me get this straight -- the recommendation is to upgrade my
> > > *entire* operating system to unstable code in order to get a single
> > > feature?? I think I'll keep using the cooker RPMs, supported or
> > > otherwise.
[...]
> > It is not by chance that all distros are freezing their distro and
> > squashing bugs before release. It is to ensure all softwares provided in
> > the distro interoperate correctly.. If you start installing
> > unstable/untested software on your distro,  you are on your own.
[...]

This demonstrates one of the big problems facing all distro's at the moment.
They are so big they are nearly impossible to release. All the various bits
and pieces are evolving independantly at different rates, so trying to
bundle together a coherent stable distro is nearly impossible.

Debian as the biggest distro has hit this wall harder than most, and the
result is Debian takes years to freeze and go stable, and when it finally
does it includes out of date major components that have had bugfixes
from recent releases painfuly reto-fitted to make them stable enough to
release.

The only solution I can see is the same solution applied to any other
problem that has become too complex; divide and decouple. Break the distro
into major decoupled components, and test/fix/release them independantly on
their own shedules. 

An unstable component going into an unstable distribution cannot be
effectively tested by end users, because they cannot be sure if the problem
is in the component, or the distro. If these unstable components were being
tested on a stable base distro, it would be much easier to isolate the
problems.

Of course it's pretty hard to make an ustable "foo" for a stable "bar" if it
depends on the latest unstable "jig" that depends on the latest unstable
"bar". This is where the decoupling comes in. You need to identify and
partition the components along the least-interconnected bits to minimize the
dependency coupling problem. This is a design issue that just needs to be
addressed.

This is already sortof happening, with major component clusters of distros
being maintained by the same people, and agreements between component
mantainers to target common versions of other required components. However,
the package archives don't yet reflect this, with them still bundling
packages into single massive "stable/unstable" distros that cannot be mixed.

I'm looking forward to see what happens. I expect Debian to be the first to
try out varous solutions, because it's the one with the biggest problems and
has pool-archive infrustructure in place to do stuff :-)

-- 
----------------------------------------------------------------------
ABO: finger abo minkirri apana org au for more info, including pgp key
----------------------------------------------------------------------