Re: Why was etch released as stable if it still has bugs?
[debian-release is not a discussion list; cc:ing to debian-project, please
respect M-F-T (if mutt doesn't eat my setting again).]
On Tue, Apr 10, 2007 at 05:22:46AM -0700, Seth Lang wrote:
> By definition I thought release-critical to mean that
> it was critical for these bugs to be fixed before the
> release can happen. If they are not release-critical
> why label them as such. I thought that it was part of
> debian's high standards (which make debian the distro
> of choice for many) to not release a stable distro if
> it had bugs that are considered as serious or grave.
> Or what is the REAL definition of release-critical? If
> the bugs are not critical for a stable distro to be
> released why label them as such (defeats the purpose).
By default, any bug of severity: serious or higher is treated as
release-critical. In various cases, exceptions are made.
For the bugs of severity: serious or higher that were still present in etch
at the time of release, a deliberate decision was made to release with those
bugs because we were confident that etch was already of higher quality than
sarge -- many of the RC bugs that were fixed for etch were actually present
in sarge but never documented as such, and while it would be nice to have
zero known security bugs at the time of a release, the supply of security
bugs is being constantly replenished, so it doesn't make any sense to hold
out for a perfect score.
For the remaining non-security 5 RC bugs in etch at the time of release,
holding out for bugfixes before etch r0 would have meant delaying the
release for at least two weeks for the simplest of these, in a best-case
scenario assuming everyone was available to finish the release at that
point; and these bugs were variously unreproducible, of debatable severity,
not regressions from sarge, or the appropriate fix is in doubt, such that
fixing all 5 would more than likely require a full month or more before we
would be ready to try for a release again. When all of these bugs are
candidates for fixing in etch r1, it doesn't make sense to further delay the
release when doing so means stable users would continue to use sarge, which
we were confident we had already surpassed in quality.
> I'm only pointing out that it doesn't help with user
> confidence when a distro releases under the name
> stable when it admits to still having several
> release-critical bugs at the time.
"release-critical" is, by definition, something that blocks the release.
Since these bugs did not block the release, they were not release-critical;
so what you're seeing is misleading statistics.
> But as you can see from:
> http://www.debian.org/Bugs/Developer#severities for a
> bug to be release critical means that the package is
> either critical, grave, or serious. Furthermore, the
> same document also states that a package maintainer
> can tag the package as etch-ignore
Er, no, it doesn't say this, nor should it.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
vorlon@debian.org http://www.debian.org/
Reply to: