On Sat, Feb 23, 2002 at 02:08:23AM +0900, Junichi Uekawa wrote:
> Josip Rodin <joy@cibalia.gkvk.hr> cum veritate scripsit:
> > That is not in question, it never was. (If anyone thought differently,
> > please show yourself so I can shoot you. >:)
> > The Severity: field of the bugs is the issue.
> To summarize this thread:
> o The "Severity" field indicates the nature of the bug
> o "Severity: serious" is used for indicating violation of a
> "must" clause in policy
> o Not building from source with build-dependencies satisfied is
> a violation of must clause
> o The "this package doesn't build from source" bugs were not really
> that vigorously checked before
> o "Severity: serious" is a RC bug
> o Some people don't think they can fix the RC bug before woody,
> but rather release woody with unbuildable packages, and thus
> filing RC bugs was deemed "wrong".
* The "Severity" field indicates the severity of the bug.
* Severity "critical" is used for bugs in packages that actively damage the
system, just by existing.
* Severity "grave" is used for bugs in packages that damage a user who runs
them.
* Severity "serious" is used for bugs in packages that we believe are bad
enough that we'd rather not release the package.
* The sorts of bugs that match "critical" and "grave" are described in the
bugs.debian.org pages. The sorts of bugs that match "serious" have been
passed off to the policy document.
* The policy document says "If build-time dependencies are specified, it
must be possible to build the package and produce working binaries on a
system with only essential and build-essential packages installed and
[the ones build-dep'ed on]", making that a "serious" bug.
The bits that probably haven't been spelled out in this thread which you also
need to get to the conclusion are:
* The reason for this requirement is to allow the autobuilders to
automatically build packages without needing the porters to special
case hundreds or thousands of packages.
* The reason for *that* is to ensure we have the same version of every
package on every architecture, so that when we distribute our source CDs,
we don't have to worry that we're distributing the i386 source rather than
the alpha source, and so that we minimise different behaviour across
architectures, and so forth.
For example, libgc6 1:6.0-3 (libgc source package) doesn't build on arm
or hppa. Since it's built on arm in the past, and thus the versions are
out of sync, a serious bug has been filed about it (Bug#134309). On the
other hand, the fact that it's never built on hppa, means that a bug
about it still not building on hppa *isn't* serious (Bug#96661).
* These things are equally well achieved if *someone* special cases them.
* For the arch:i386 and arch:all cases, the maintainer is special
casing them, which is why nobody noticed until now.
* Hence, the fact that the package doesn't autobuild on i386 or for arch:all,
while still a bug, isn't RC.
First: this is definitely up for review post woody. It gets in the way of
people doing "make world" like things which people seem interested in, and
more importantly it gets in the way of people doing NMUs. It's clearly and
uncontroversially something we should be ensuring, and it fits in with the
autobuilding stuff we already insist on [0].
Second: it's no good introducing new requirements when we're trying to
get a release out the door. And while you can point at policy and say
"it's always been a requirement", that's not really fair when up until
now no one's ever been testing it. The bug reports and patches should
still hopefully mean most of them get fixed before release, though.
Third: having the release-critical requirements in policy has been
an interesting experiment which hasn't been tried before this release
cycle. One one hand it's been a damn success: it's resulted in a *much*
more useful release-critical bug list than we had for the potato release.
On the other hand, policy doesn't appear to be quite the right document
to have this in: it's too static and it's too liable towards literal
interpretations. So we (myself as RM, and Manoj and Julian as policy
editors) are all pretty much agreed that those requirements should
be split out into a separate document, and we'll see where we can go
from there.
> Note: I completely disagree that the bug severity was inflated, Joy.
Well, according to all the documentation you had access to, they weren't.
The documentation can be misleading though.
> There will be several hundred more bug reports to come, and
> I don't think we can ever release woody if we make that a release
> criteria.
This, though, is the final "definition" of whether a bug is inflated. If
it can't reasonably be a release criterion, it's not a serious bug.
Cheers,
aj
--
Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/>
We came. We Saw. We Conferenced. http://linux.conf.au/
``Debian: giving you the power to shoot yourself in each
toe individually.'' -- with kudos to Greg Lehey
Attachment:
pgpdWJpIB38c8.pgp
Description: PGP signature