Martin Michlmayr schrieb:
Well, personally, I'm a bit afraid of testing and unstable moving
apart... for example, all developers use unstable rather than testing
but we ship testing...
Don't forget all the users, which have testing for a long time now,
because woody is very outdated.
if testing and unstable grow apart, this would
be a problem.
stable and testing already growed apart - very far.
Let's ask the question, how long good time-lags should be.
It depends;-)
From my experience in testing/QA at large commercial projects, I can
say, that 2 weeks are to short in most cases. 3 months should be enough
for re-testing even a large package.
In a distri like debian, things are different.
1) high quality upstream
Think about packages with high activity, systematic testing on upstream,
e.g. apache, gnumeric, mozilla, perl. They have a large user base, with
some users keen on new features, testing and trying upstream-unstables.
They come to debian in a stable condition (in most cases). Even small
packages can be high quality. E.g. drbd 0.6.12 was released March 10th
as a upstream bugfix, went to debian 1 month later, and now after the
magic 3 months packaging problems are solved, no bugs known at upstream
or debian BTS. That's stable, I think.
2) poorly upstream, unimportant package
Don't know, how long they should stay in unstable and/or testing. 3
months minimum.
3) important debian-packages
E.g. installer, apt, dpkg. In this case other rules apply. From my point
of view, these packages can be classified as large, complex
developments. For major redesign releases I would estimate 9 months
_systematic_ testing, under the precondition, that every 3 months a
_bugfree_ release is available for re-test. The installer is far away
from stable.
We recently discussed move checks for packages which we release, and
the suggestion was to leave packages into unstable just like we do
now, but require further checks before they move to testing for the
first time.
A good decision.
I think it's a good compromise because we give packages
the chance to get tested and find users (by distributing them in
unstable), but I am a bit worried about having such big differences
between testing and unstable.
There will always be delays between phases. You can not shorten the
minimum time needed between coding and stable. I would like see packages
in a place for "acceptance testing", where they can only be after a
sanity check (= install without problems, main functionality works
without important bugs). This place should not be stable (like some
distries do, including experimental into a release).
I know, that debians tradition does not like timelines for release. But
avoiding such huge gaps between debian-stable and upstream-stable needs
better release policy, needs timelines, needs kick-back of buggy packages.
Well, one example: sometimes, a package is removed from testing
because it's buggy, but it's left in unstable... in some cases this
may be okay, but I think we should also check if those package should
be removed from Debian altogether.
In case of Gnumeric nobody wants to remove it from debian;-) In this
special case, Gnumeric 1.2.12 in unstable damages KDE and
XFree-installation, if I "apt-get install" it. 1.2.12 is stable at
upstream and an important release. Gnumeric is one of the best packages,
to get away from M$-Excel (all other comparables including OOo are not
really usable). 1.2.11 has a important bug, that hinders me, to use it
for my professional work. I would like to test 1.2.12 und help the
gnumeric people finding bugs. But I estimate hours or days getting it
installed. F*ck*ng dependencies on unimportant broken packages. I am
really angry, that this problem is known for a long time and left unsolved.
Helmut Wollmersdorfer
