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

Re: Unidentified subject!



On Tue, Nov 04, 2003 at 03:31:42PM -0500, Marc Shapiro wrote:
> Colin Watson <cjwatson@debian.org> wrote:
> >On Tue, Nov 04, 2003 at 03:57:02PM +0000, Richard Kimber wrote:
> >> This may be a stupid question, but has consideration been given to
> >> having a 'holding area' between testing and stable to which stuff
> >> gets moved only when there are no breakages?
> >
> >That's what testing is supposed to be. It would be too hard to try to
> >construct yet another stage, I believe.
> 
> So why does it NOT work that way.  My only serious breakage under testing 
> was the gnome2 problem a little while back.

GNOME 2 got into testing in a partial state because deficiencies in its
packaging meant that the testing management scripts didn't automatically
detect that it would be broken that way. As far as the dependencies
stated, everything was just fine.

> It made a mess of my system and I was unable to  get back to a working
> gnome 1.4, or get a working gnome2.

snapshot.debian.net usually helps.

> You (Colin) just recently posted that KDE3 has entered testing, but
> that it is broken.  Why is it going in to testing if it is KNOWN to be
> broken.  That seems to go against what you posted (above).

KDE 3 was forced in by the release manager on the basis that even a
partially broken KDE (and it *is* only partially broken; not all the
metapackages are installable, so you can't say 'apt-get install kde' or
'apt-get install kdebase', but the actual core packages are basically OK
as I understand it) was better than the ancient pile of unreleasable
junk that was in testing. Sometimes human decisions are necessary when
managing a distribution, and breaking things is not done lightly or for
no reason.

If you tried to construct something between testing and stable that you
used as the basis for a release, you would have to manage it
automatically with occasional human intervention, and I confidently
expect that sooner or later you would find yourself making exactly the
same hard decisions that are involved in managing testing. You wouldn't
actually end up improving matters at all, because there's no way to
construct a working system out of broken parts, and waiting for working
parts sometimes takes time, which is why problems in testing sometimes
take a while to be fixed.

Cheers,

-- 
Colin Watson                                  [cjwatson@flatline.org.uk]



Reply to: