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, :
http://www.debianplanet.org/node.php?id=858
http://www.debianplanet.org/node.php?id=920
http://lists.debian.org/debian-devel-announce/2003/03/msg00006.html
http://www.debianplanet.org/node.php?id=903
http://www.debianplanet.org/node.php?id=872
http://lists.debian.org/debian-gtk-gnome/2002/11/msg00242.html
http://lists.debian.org/debian-gtk-gnome/2002/11/msg00242.html
http://www.debianplanet.org/node.php?id=784
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
archive.
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:
A)
testing/unstable will be broken and some stage.
B)
At various times you will have mixed versions for parts of major packages.
Thanks,
Lex.
--
AutoQ - www.autoq.org - Best funk music in the land.
Reply to: