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

Re: Finding an improved release process.

On Sun, 28 Nov 2004 03:49 am, Andrew Suffield wrote:
> On Sat, Nov 27, 2004 at 11:15:26PM +1000, Anthony Towns wrote:
> > Andrew Suffield wrote:
> > >On Sat, Nov 27, 2004 at 01:34:09PM +1100, alexeijh@westnet.com.au wrote:
> > >>People often suggest running testing or unstable. "It's just as stable
> > >> as any distro". I have never agreed with this. The reason for this is
> > >> that neither are engineered or intended for being an end product.
> > >
> > >This is an improper definition of 'stable'. It doesn't mean
> > >'reliable', it means 'not changing'. The important feature of a stable
> > >release is that it stays the same.
> >
> > Not changing does actually mean it's reliable -- you can rely on doing
> > the same thing today as it did yesterday.
> Yes, very clever, you've successfully conflated the terminology. He
> was obviously referring to 'no/low serious bugs', as distinct from
> 'stable'.

Interesting that the main discussion point was this last one instead of the 
main crux of my post. I probably could have stated it a little more clearly.

Here's some quotes from 1st post:

"neither are engineered or intended for being an end product"
"sometimes I may update and things will be broken"
"Unless you can tell the user that they install/update/upgrade anytime 24/7 
with the same unbroken result you can't recommend these systems."

key terms were: "end product", unbroken, broken.

My main point is the variability of the reliability of the packages in testing 
or unstable with respect to time.

I trawled through debianplanet.org for some examples in time since woody 
released, :


Some examples of when testing/unstable were broken or when major packages 
[gnome, kde, perl] were inconsistent [probably need a better word I can't 
think of right now]. i.e. not all at the same version. When transitions are 
happening and half of the old and half of the new versions are in the 

from: http://lists.debian.org/debian-qt-kde/2004/11/msg00448.html
> On Mon, Nov 22, 2004 at 03:30:03PM +1000, Anthony Towns wrote:
> > Adeodato Simó wrote:
> > >  We know from experience that KDE upstream really ensures that their
> > >  monolithic x.y.z works together nicely, but that mixing even minor
> > >  point releases can break things very badly.
> > In that case, you should be using the control files to prevent mixed 
> > installs. If users can install packages in some combination that won't 
> > work; the Depends/Recommends/Provides/Conflicts fields should be used to 
> >  tell them of that in advance. That's what they're for.
> I agree. In this way, the kde packages have allways been broken. We
> have been so far reluctant to enforce all of kde being the same version,
> since it would seem make testing maigration even harder - Ie. every
> kde release would need to be hinted all packages at once, which wouldn't
> certainly help the "make kde safe to trickle in" -requirement.
So in a nutshell, my concern is:
testing/unstable will be broken and some stage.
At various times you will have mixed versions for parts of major packages.


AutoQ - www.autoq.org - Best funk music in the land.

Reply to: