Re: Debian reliability growth
Another problem that was not mentionned in this thread, but which I
see as being related, is the repeted bottlenecks we currently have for
entrance into testing.
How does it relate to quality ? Well, there are several ways:
- some packages are held in sid because of completely unrelated
problems. This makes packages enter testing later than they should,
and so they're less tested.
- one particular case of the above situation is when we must wait for
all dependencies of a given lib to be rebuilt and free from RC bugs
(eg. for the g++3.2 ABI transition, bock is still holding libgc, see
#180969 and #193549), for the whole set to be promoted.
This bottleneck issue is such that some bugfixes, which are not seen
as sufficiently critical to use woody-proposed-updates, can be held in
sid for a _very_ long time.
Janne wrote:
> Could the wishes of both these groups be satisfied with two supported
> releases? Let me explain. Debian would then have four branches:
>
> Unstable: No change from the current situation
>
> Testing: As currently, but with relaxed requirements/more manual
> intervention/something else so that a release can be made faster
>
> Release: Fully supported release with security AND bug fixes, like Remi
> suggested. Depending on upstream policy, why not new minor versions of
> packages instead of backporting fixes (perhaps this would reduce the burden
> on maintainers?)? And also, why not allow new packages to be added as long
> as they don't conflict with existing packages. Perhaps bugfixes and new
> packages could be added via point releases if continous addition is a bad
> idea?
>
> Stable: As a new release branch is made, the current release branch is
> renamed stable (and packages with RC bugs dropped?). Same policy as the
> current stable branch, but as the release branch has been in widespread use
> for quite some time most bugs and security issues have (hopefully) been
> corrected, so it would be of even higher quality than the current stable.
One idea that comes to my mind is to combine this proposal with
another one I hear here and there from unhappy users - you'll see
below.
We could allow promotion into "testing"-as-described-above mostly on a
per-package basis; only _source_ packages would be promoted (provided
the build-deps are satisfied), and would then be automatically rebuilt
against the libs/whatever in "testing".
That would filter from "testing" the vast majority of the bugs that
are currently filtered, while virtually removing the bottlenecks
caused by commonly-used support packages (glibc, libgcc's et al). As
a consequence, bugfixes go faster into "testing", and the overall
quality in "testing" (and thus the quality in "stable") is raised.
Then promotion from "testing" into "more-stable-than-testing" could be
handled as promotion into "testing" is currently done, since most
bottleneck-inducing problems (eg. does not build on arch XYZ) have
already been filtered.
Well, you noticed, that's not Janne's "release" after "testing".
That's just an additional stage in the pipeline. But being automated,
it would only require more computing power and archive space, and not
much more manpower (apart from the work needed to get this
up-and-running at first).
Regards,
--
Yann Dirson <ydirson@altern.org> | Why make M$-Bill richer & richer ?
Debian-related: <dirson@debian.org> | Support Debian GNU/Linux:
Pro: <yann.dirson@fr.alcove.com> | Freedom, Power, Stability, Gratuity
http://ydirson.free.fr/ | Check <http://www.debian.org/>
Reply to: