Debian Bug report logs - #97671
xutils: why is rstart.real a conffile?

Package: project; Maintainer for project is debian-project@lists.debian.org;

Reported by: Tollef Fog Heen <tollef@add.no>

Date: Wed, 16 May 2001 12:03:01 UTC

Severity: normal

Tags: help, upstream

Done: Anthony Towns <aj@azure.humbug.org.au>

Bug is archived. No further changes may be made.

Toggle useless messages

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to debian-bugs-dist@lists.debian.org, Branden Robinson <branden@debian.org>:
Bug#97671; Package xutils. Full text and rfc822 format available.

Acknowledgement sent to Tollef Fog Heen <tollef@add.no>:
New Bug report received and forwarded. Copy sent to Branden Robinson <branden@debian.org>. Full text and rfc822 format available.

Message #5 received at submit@bugs.debian.org (full text, mbox):

From: Tollef Fog Heen <tollef@add.no>
To: submit@bugs.debian.org
Subject: ELF file as conffile?
Date: 16 May 2001 13:53:51 +0200
Package: xutils
Version: 4.03-3

It seems like /etc/X11/rstart/rsartd.real is both an ELF file and
conffile.  This seems strange to me - and what is a runnable, compiled
program doing in /etc?  Shouldn't that go into /usr/X11R6 somewhere?

-- 

Tollef Fog Heen
Unix _IS_ user friendly... It's just selective about who its friends are.



Changed Bug title. Request was from Branden Robinson <branden@debian.org> to control@bugs.debian.org. Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Branden Robinson <branden@debian.org>, xfree86@packages.qa.debian.org:
Bug#97671; Package xutils. Full text and rfc822 format available.

Acknowledgement sent to Josip Rodin <joy@cibalia.gkvk.hr>:
Extra info received and forwarded to list. Copy sent to Branden Robinson <branden@debian.org>, xfree86@packages.qa.debian.org. Full text and rfc822 format available.

Message #12 received at 97671@bugs.debian.org (full text, mbox):

From: Josip Rodin <joy@cibalia.gkvk.hr>
To: 97671@bugs.debian.org
Cc: control@bugs.debian.org
Subject: xutils still ships a binary into /etc
Date: Sat, 13 Apr 2002 16:33:27 +0200
severity 97671 serious
thanks

Hi,

% find /etc | xargs file | grep ELF
/etc/X11/rstart/rstartd.real:                                    ELF 32-bit LSB
executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), stripped
% 

The FHS says "No binaries should be located under /etc.", and the Policy
says "The location of all installed files and directories must comply with
the Filesystem Hierarchy Standard (FHS), version 2.1, except where doing so
would violate other terms of Debian Policy".

According to my reading of the "must"/"should not" stuff in both the Policy
and the FHS, this is a serious violation. This doesn't fall under the
exception AFAICT, /usr/share/doc/xutils/README.Debian doesn't explain it,
and the Debian changelog doesn't seem to mention it, either.

This looks to be a byproduct of moving /usr/X11R6/lib/X11/rstart into
/etc/X11 and symlinking the former to the latter...

-- 
     2. That which causes joy or happiness.



Severity set to `serious'. Request was from Josip Rodin <joy@cibalia.gkvk.hr> to control@bugs.debian.org. Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Branden Robinson <branden@debian.org>, xfree86@packages.qa.debian.org:
Bug#97671; Package xutils. Full text and rfc822 format available.

Acknowledgement sent to Thomas Hood <jdthood@yahoo.co.uk>:
Extra info received and forwarded to list. Copy sent to Branden Robinson <branden@debian.org>, xfree86@packages.qa.debian.org. Full text and rfc822 format available.

Message #19 received at 97671@bugs.debian.org (full text, mbox):

From: Thomas Hood <jdthood@yahoo.co.uk>
To: 97671@bugs.debian.org
Subject: still a bug
Date: 15 Apr 2002 07:53:19 -0400
[Message part 1 (text/plain, inline)]
This is still a bug in 4.1.0-15 .
[signature.asc (application/pgp-signature, inline)]

Severity set to `normal'. Request was from Branden Robinson <branden@debian.org> to control@bugs.debian.org. Full text and rfc822 format available.

Severity set to `serious'. Request was from Anthony Towns <aj@azure.humbug.org.au> to control@bugs.debian.org. Full text and rfc822 format available.

Severity set to `important'. Request was from Branden Robinson <branden@debian.org> to control@bugs.debian.org. Full text and rfc822 format available.

Tags added: pending Request was from Branden Robinson <branden@debian.org> to control@bugs.debian.org. Full text and rfc822 format available.

Information forwarded to xfree86@packages.qa.debian.org:
Bug#97671; Package xutils. Full text and rfc822 format available.

Acknowledgement sent to Branden Robinson <branden@debian.org>:
Extra info received and filed, but not forwarded. Copy sent to xfree86@packages.qa.debian.org. Full text and rfc822 format available.

Message #32 received at 97671-quiet@bugs.debian.org (full text, mbox):

From: Branden Robinson <branden@debian.org>
To: 97671-quiet@bugs.debian.org
Cc: control@bugs.debian.org
Subject: adjusting severity
Date: Thu, 18 Apr 2002 00:31:38 -0500
[Message part 1 (text/plain, inline)]
severity 97671 important
tags 97671 + pending
thanks

In actual practice, this isn't being treated as a release-critical bug
because the Release Manager doesn't feel it should hold up the release.
(See below for a quote.)

Below are some excerpts from IRC that address my planned strategy for
addressing this bug...*after* the woody release.  It will be high on my
priority list (hence the "important" severity) for resolution, after
woody releases, at approximately the same time I'm getting XFree86 4.2
packaged.

11:26PM|<Overfiend> aj: what a wonderful idea.  I'd welcome a patch to
xc/programs/rstart/Imakefile that would make a distinction between real
config files and "miscellaneous" program data files
11:42PM|<Overfiend> I'm dead serious about that.  It is the correct
solution.
11:50PM|<aj> Overfiend: i was asking you to see if you had a good reason
for doing what you have so i could downgrade it, but it appears you
don't. but i'm not going to remove X or leave it as -14 out of spite or
anything.
11:50PM|<Overfiend> aj: the "good reason" is that most things under
/usr/X11R6/lib/X11 are de facto configuration files and have been used
that way.
11:51PM|<Overfiend> aj: when I reorganized the X packaging for 4.0, I
changed the scheme of having tons of symlinks from /etc into
/usr/X11R6/lib/X11, and went the other way
11:51PM|<Overfiend> aj: the X11 SI, when originally written, wasn't even
cognizant of an "/etc" directory.
11:56PM|<Overfiend> aj: my *preference* is to fix this bug in
conjunction with a general walk over a bunch of Imakefiles in
xc/programs that will recognize the FHS
11:58PM|<Overfiend> aj: would it make you feel better if I roll a -17
that kills off rstartd entirely?
11:59PM|<Overfiend> though of course, this leaves a problem.
De-registering a conffile is nasty with dpkg.
11:59PM|<Overfiend> in fact, it doesn't work at all, in general.  You
have to write your own mechanism.
11:59PM|<aj> Overfiend: nah, leave it 'til after woody now

Bug list perusers: please don't fool with the severity of this bug.

-- 
G. Branden Robinson                |
Debian GNU/Linux                   |       "Bother," said Pooh, as he was
branden@debian.org                 |       assimilated by the Borg.
http://people.debian.org/~branden/ |
[Message part 2 (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Branden Robinson <branden@debian.org>, xfree86@packages.qa.debian.org:
Bug#97671; Package xutils. Full text and rfc822 format available.

Acknowledgement sent to Anthony Towns <aj@azure.humbug.org.au>:
Extra info received and forwarded to list. Copy sent to Branden Robinson <branden@debian.org>, xfree86@packages.qa.debian.org. Full text and rfc822 format available.

Message #37 received at 97671@bugs.debian.org (full text, mbox):

From: Anthony Towns <aj@azure.humbug.org.au>
To: 97671@bugs.debian.org, control@bugs.debian.org
Subject: Re: adjusting severity
Date: Thu, 18 Apr 2002 23:48:32 +1000
severity 97671 serious
thanks

Some classes of bugs, such as "programs crashing lose the data you were
working on" and "the program doesn't work for me no matter what I do,
but works fine for others" aren't treated as the severity you might think
they should be on a first reading. Putting ELF executables in /etc, though,
isn't one of these sorts of bugs.

That X gets special exceptions for some bugs that'd get most other packages
removed doesn't change the severity of this bug.

Cheers,
aj

-- 
Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. GPG signed mail preferred.

     ``BAM! Science triumphs again!'' 
                    -- http://www.angryflower.com/vegeta.gif



Severity set to `serious'. Request was from Anthony Towns <aj@azure.humbug.org.au> to control@bugs.debian.org. Full text and rfc822 format available.

Severity set to `important'. Request was from Branden Robinson <branden@debian.org> to control@bugs.debian.org. Full text and rfc822 format available.

Information forwarded to xfree86@packages.qa.debian.org:
Bug#97671; Package xutils. Full text and rfc822 format available.

Acknowledgement sent to Branden Robinson <branden@debian.org>:
Extra info received and filed, but not forwarded. Copy sent to xfree86@packages.qa.debian.org.

Your message did not contain a Subject field. They are recommended and useful because the title of a Bug is determined using this field. Please remember to include a Subject field in your messages in future.

Full text and rfc822 format available.


Message #46 received at 97671-quiet@bugs.debian.org (full text, mbox):

From: Branden Robinson <branden@debian.org>
To: control@bugs.debian.org, 97671-quiet@bugs.debian.org
Date: Thu, 18 Apr 2002 11:26:06 -0500
[Message part 1 (text/plain, inline)]
severity 97671 important
thanks

Please, please, please stop interfering with my ability to perform
proper triage on my bug list.  Anthony Towns was present when a proper
solution to the "bug triage" problem was discussed on IRC with Adam
Heath, and no one has the time to implement such a proper solution at
present.  (There appeared to be a shared assumption that the Debian BTS
should separare "priority" from "severity", as Bugzilla does.)

I'm sorry that my awareness of a bug, and my intention to fix it on a
timetable that is acceptable to the Release Manager, is insufficient to
satisfy his esthetic.  This bug clearly is not a release-critical issue,
as the Release Manager himself acknowledged, and should not be treated as
such.  I am aware of Anthony's and Manoj's discussions of how
release-criticality is orthogonal to bug severity.  Again, no one
appears to have the time to implement mechanisms communicating this
orthogonality -- or, at least, not at the level where the individual
package maintainer can take advantage of it (there is no report
generated that shows me my actual release-critical bugs followed by my
non-release-critical bugs).

Until these absences of mechanism in our Bug Tracking System are
addressed, I think the package maintainer needs to retain the level of
control over his bug list that I am asserting.  After these mechanisms
have been implemented, "release-critical" bugs can be assigned the
highest "priority", regardless of their "severity".

In the meantime, I need to be permitted to manage my bug list as I have
done for the past four years.

Please do not change this bug severity again or I will be forced to
appeal to the Technical Committee under section 6.1 of the Debian
Constitution.

-- 
G. Branden Robinson                |          You live and learn.
Debian GNU/Linux                   |          Or you don't live long.
branden@debian.org                 |          -- Robert Heinlein
http://people.debian.org/~branden/ |
[Message part 2 (application/pgp-signature, inline)]

Severity set to `serious'. Request was from Anthony Towns <aj@azure.humbug.org.au> to control@bugs.debian.org. Full text and rfc822 format available.

Bug reassigned from package `xutils' to `tech-ctte,xutils'. Request was from Branden Robinson <branden@debian.org> to control@bugs.debian.org. Full text and rfc822 format available.

Bug 97671 cloned as bug 143825. Request was from Manoj Srivastava <srivasta@acm.org> to control@bugs.debian.org. Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>, Branden Robinson <branden@debian.org>, tech-ctte@packages.qa.debian.org, xfree86@packages.qa.debian.org:
Bug#97671; Package tech-ctte,xutils. Full text and rfc822 format available.

Acknowledgement sent to Anthony Towns <ajt@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>, Branden Robinson <branden@debian.org>, tech-ctte@packages.qa.debian.org, xfree86@packages.qa.debian.org. Full text and rfc822 format available.

Message #57 received at 97671@bugs.debian.org (full text, mbox):

From: Anthony Towns <ajt@debian.org>
To: Manoj Srivastava <srivasta@debian.org>
Cc: Branden Robinson <branden@debian.org>, debian-ctte@lists.debian.org, leader@debian.org, debian-devel@lists.debian.org
Subject: "Release-critical" bugs (was: Re: Processed: yawn)
Date: Thu, 25 Apr 2002 23:10:35 +1000
[Message part 1 (text/plain, inline)]
On Sat, Apr 20, 2002 at 09:57:12PM -0500, Manoj Srivastava wrote:
>         It is my considered optinion that this is a serious
>  bug. Whether or not the bug is release critical depends purely on the
>  release manager. 

It seems some clarification about this might be helpful.

For those tuning in late, the context is in bug #97671. It's not
particularly needed to grok the rest of this mail, though.

Critical, grave and serious bugs are intended to be tied to particular
types of errors and to be relatively objective.

Further, there's intended to be a one-one correspondence between issues
matching the criteria for critical, grave, and serious and issues that
make packages unsuitable for release with Debian.

Most of the time how this is dealt with is relatively straightforward:
effort and attention is focussed on fixing it, or, if the bug is too
hard and the package doesn't matter much, it's dropped.

When the release gets down to a couple of weeks away, though, this
attitude changes, and some classes of bugs that are considered critical,
grave, or serious get set aside rather than dealt with. As woody's release
approaches, eg, the following bugs are being ignored in this manner:

     * #144330: gcl: FTBFS: tk-dev does not exist (hppa/unstable)   
     * #144380: gnotepad+ has typo in Conflicts: line
     * #141922: ldirectord: lvs is renamed to ipvsadm 
     * #144299: libwmf0 and libwmf-dev have file overlap
     * #139689: mesag-dev: version 3.4.2.1-4 install fails (conflicts
       with mesag-widgets-dev) on ppc
     * #144254: setserial: maintainer scripts modify conffile
       /etc/serial.conf
     * #144255: squid: maintainer scripts modify conffile /etc/squid.conf
     * #129819: syslog-ng: klogd stops working after syslog-ng is
       reloaded or restarted
     * #137752: xfree86v3 fails to build from source on powerpc
     * #139523: building on arm (and probably others) fails
     * #143825: xutils: why is rstart.real a conffile?

The argument for this way of doing things is pretty straightforward,
and you may've seen it before. A set of severities is need to precisely
identify release-critical issues so that they can be appropriately
dealt with -- nothing else is feasible. These severities need to be as
objectively determined as possible, as we have far too many bugs to run
them all past an oracle to decide what severity they should be. We need to
fix or remove packages with these problems so that, generally speaking,
our releases meet our standards. And, finally, we need to have special
exemptions because, quite frankly, our standards are marginally higher
than our abilities.

For comparison with how this was working with potato, you might like to
look at:

    http://lists.debian.org/debian-devel-announce/2000/
	debian-devel-announce-200008/msg00004.html

Unfortunately there's no similarly annotated list of the RC bugs
affecting woody.

Cheers,
aj

-- 
Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. GPG signed mail preferred.

     ``BAM! Science triumphs again!'' 
                    -- http://www.angryflower.com/vegeta.gif
[Message part 2 (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>, tech-ctte@packages.qa.debian.org, xfree86@packages.qa.debian.org:
Bug#97671; Package tech-ctte,xutils. Full text and rfc822 format available.

Acknowledgement sent to Branden Robinson <branden@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>, tech-ctte@packages.qa.debian.org, xfree86@packages.qa.debian.org. Full text and rfc822 format available.

Message #62 received at 97671@bugs.debian.org (full text, mbox):

From: Branden Robinson <branden@debian.org>
To: debian-devel@lists.debian.org
Cc: 97671@bugs.debian.org
Subject: Re: 88 Priority violations in woody
Date: Tue, 30 Apr 2002 17:08:43 -0500
[Message part 1 (text/plain, inline)]
On Tue, Apr 30, 2002 at 02:48:15PM -0500, Manoj Srivastava wrote:
> >>"Andreas" == Andreas Metzler <ametzler@downhill.at.eu.org> writes:
> 
>  Andreas> What is the best way to deal with these bugs and help the
>  Andreas> release of woody?
>  Andreas> -simply close it.
> 
> 	They are still serious bugs.

Well, tell it to Anthony Towns.

http://bugs.debian.org/cgi-bin/bugreport.cgi?archive=no&bug=145142

>  Andreas> -reassign to ftp.debian.org
> 
> 	Having 88 bugs on ftp.debian.org is not helpful. *ONE* report
>  shall suffice.

Well, tell it to Junichi Uekawa.

http://bugs.debian.org/cgi-bin/bugreport.cgi?archive=no&bug=145068

>  Andreas> -make an urgency-high-upload
> 
> 	These are not serious bugs, and testing is now closed.

Uh, don't you mean Release Critical?  You just said they "are still
serious bugs".

>  Andreas> -a combination of the above.
> 
> 	None of the above? These bugs are already in the override file
>  for RC bugs.

Perhaps so, but some people who have taken it upon themselves to
manipulate the bugs do not appear to share your understanding of how the
BTS should be used.  Note that I'm not saying you're wrong.  It may be
that people are simply exceeding their authority.  (That Thomas Hood may
have done so in filing them does not, presumably, justify any possible
response one might be able to conceive.)

Perhaps the Technical Committee's eventual resolution of
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=97671&repeatmerged=yes
will help to shed light on matters like this.

-- 
G. Branden Robinson                |    Intellectual property is neither
Debian GNU/Linux                   |    intellectual nor property.
branden@debian.org                 |    Discuss.           -- Linda Richman
http://people.debian.org/~branden/ |
[Message part 2 (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>, tech-ctte@packages.qa.debian.org, xfree86@packages.qa.debian.org:
Bug#97671; Package tech-ctte,xutils. Full text and rfc822 format available.

Acknowledgement sent to Branden Robinson <branden@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>, tech-ctte@packages.qa.debian.org, xfree86@packages.qa.debian.org. Full text and rfc822 format available.

Message #67 received at 97671@bugs.debian.org (full text, mbox):

From: Branden Robinson <branden@debian.org>
To: debian-devel@lists.debian.org
Cc: 97671@bugs.debian.org
Subject: Re: 88 Priority violations in woody
Date: Tue, 30 Apr 2002 17:18:09 -0500
[Message part 1 (text/plain, inline)]
On Tue, Apr 30, 2002 at 10:07:07PM +0200, Josip Rodin wrote:
> On Tue, Apr 30, 2002 at 11:52:20AM -0500, Branden Robinson wrote:
> > > * Policy is not a stick to beat people with.  It's a guideline, that should be
> > >   followed closely, but not exactly.
> > 
> > Doesn't stop people from whacking my packages with it;
> > bugs.debian.org/97671.
> 
> I hope you're not referring to my initial raising it to serious...?

Yes, and aj's insistence that it should stay there, which does not
appear consistent with his decision that 88 other serious policy
violations should be closed outright.

I don't have have a personal beef with you or Anthony, or your
respective interpretations of the Policy manual or the "true meaning" of
documents like http://www.debian.org/Bugs/Developer, which contains
blatant falsehoods and needs revision[1].  The issue to my mind is the
nature of the BTS itself, and the audience it is most intended to serve:
users, developers, or the Release Manager.

My personal opinion is that the BTS should serve the developers first
and foremost.  It *should* also be able to serve the users, but until it
has a conception of bugs against versions of packages as opposed to a
non-temporal notion of a package, it's going to fill that role only
poorly.  I think the Release Manager has other tools at his disposal for
discernment of release-criticality.  Whether those tools work to the
satisfaction of a given Release Manager or not is another question.

[1] "Problems in packages can only be considered fixed once a package
that includes the bug fix enters the Debian archive."  At best this is
misleading when the changelog-bug-auto-closing feature is used in
conjunction with the "New Incoming" system.

-- 
G. Branden Robinson                |    I am sorry, but what you have
Debian GNU/Linux                   |    mistaken for malicious intent is
branden@debian.org                 |    nothing more than sheer
http://people.debian.org/~branden/ |    incompetence!     -- J. L. Rizzo II
[Message part 2 (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>, Branden Robinson <branden@debian.org>, tech-ctte@packages.qa.debian.org, xfree86@packages.qa.debian.org:
Bug#97671; Package tech-ctte,xutils. Full text and rfc822 format available.

Acknowledgement sent to Josip Rodin <joy@cibalia.gkvk.hr>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>, Branden Robinson <branden@debian.org>, tech-ctte@packages.qa.debian.org, xfree86@packages.qa.debian.org. Full text and rfc822 format available.

Message #72 received at 97671@bugs.debian.org (full text, mbox):

From: Josip Rodin <joy@cibalia.gkvk.hr>
To: debian-devel@lists.debian.org, 97671@bugs.debian.org
Subject: Re: 88 Priority violations in woody
Date: Wed, 1 May 2002 00:48:43 +0200
On Tue, Apr 30, 2002 at 05:18:09PM -0500, Branden Robinson wrote:
> > > > * Policy is not a stick to beat people with.  It's a guideline, that should be
> > > >   followed closely, but not exactly.
> > > 
> > > Doesn't stop people from whacking my packages with it;
> > > bugs.debian.org/97671.
> > 
> > I hope you're not referring to my initial raising it to serious...?
> 
> Yes,

Well, I think it is serious, and not merely because someone somewhere has
made a document that says so, but because of the de facto standard that you
don't mesh binaries and configuration files. Of all seven hundred packages
on my system, there was one single "black sheep" that placed a binary among
the configuration files. In the large scheme of over a thousand
configuration files in my /etc/, there was this little deviant binary.
It crossed the line no other package crossed. This made me think it was a
serious bug, rather than normal.

> [1] "Problems in packages can only be considered fixed once a package
> that includes the bug fix enters the Debian archive."  At best this is
> misleading when the changelog-bug-auto-closing feature is used in
> conjunction with the "New Incoming" system.

That's not true, katie sends out the closing messages when the package is in
the Debian archive. It's not propagated to all the mirrors of the same
archive, but it nevertheless is in the archive. Even before NI, it sent the
bug-closing messages before the mirror sync was started.

-- 
     2. That which causes joy or happiness.



Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>, tech-ctte@packages.qa.debian.org, xfree86@packages.qa.debian.org:
Bug#97671; Package tech-ctte,xutils. Full text and rfc822 format available.

Acknowledgement sent to Branden Robinson <branden@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>, tech-ctte@packages.qa.debian.org, xfree86@packages.qa.debian.org. Full text and rfc822 format available.

Message #77 received at 97671@bugs.debian.org (full text, mbox):

From: Branden Robinson <branden@debian.org>
To: debian-devel@lists.debian.org
Cc: 97671@bugs.debian.org
Subject: Re: Bug#97671: 88 Priority violations in woody
Date: Tue, 30 Apr 2002 18:58:57 -0500
[Message part 1 (text/plain, inline)]
On Wed, May 01, 2002 at 12:48:43AM +0200, Josip Rodin wrote:
> Well, I think it is serious, and not merely because someone somewhere has
> made a document that says so, but because of the de facto standard that you
> don't mesh binaries and configuration files. Of all seven hundred packages
> on my system, there was one single "black sheep" that placed a binary among
> the configuration files. In the large scheme of over a thousand
> configuration files in my /etc/, there was this little deviant binary.
> It crossed the line no other package crossed. This made me think it was a
> serious bug, rather than normal.

I already said I wasn't arguing about the severity of the bug vis a vis
the official definition list.  I'll stipulate that the problem is as
gross, inelegant, and personally offensive as you please.

The issue is for me is twofold: about the package maintainer being
empowered to manage his own bug list for triage purposes, and about the
limits of the Release Manager' or another developer's power to make
decisions for another developer.

> That's not true, katie sends out the closing messages when the package
> is in the Debian archive.

In my experience, it sends out the closing messages roughly
contemporaneously with the time the package is moved into
queue/accepted.  Or has this changed very recently?  Earlier this week,
it was still the case.

> It's not propagated to all the mirrors of the same archive, but it
> nevertheless is in the archive. Even before NI, it sent the
> bug-closing messages before the mirror sync was started.

Which subdirectories of queue/ are part of the "archive" and which are
not?

-- 
G. Branden Robinson                |    I have a truly elegant proof of the
Debian GNU/Linux                   |    above, but it is too long to fit
branden@debian.org                 |    into this .signature file.
http://people.debian.org/~branden/ |
[Message part 2 (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>, Branden Robinson <branden@debian.org>, tech-ctte@packages.qa.debian.org, xfree86@packages.qa.debian.org:
Bug#97671; Package tech-ctte,xutils. Full text and rfc822 format available.

Acknowledgement sent to Manoj Srivastava <srivasta@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>, Branden Robinson <branden@debian.org>, tech-ctte@packages.qa.debian.org, xfree86@packages.qa.debian.org. Full text and rfc822 format available.

Message #82 received at 97671@bugs.debian.org (full text, mbox):

From: Manoj Srivastava <srivasta@debian.org>
To: debian-devel@lists.debian.org
Cc: 97671@bugs.debian.org
Subject: Re: 88 Priority violations in woody
Date: Tue, 30 Apr 2002 20:08:44 -0500
>>"Branden" == Branden Robinson <branden@debian.org> writes:

 Branden> Yes, and aj's insistence that it should stay there, which does not
 Branden> appear consistent with his decision that 88 other serious policy
 Branden> violations should be closed outright.

	Quite. In the tech ctte mailing list, I am a proponent of the
 idea that bug severities, since they are set and changed by a large
 number of people (reporters, who may not be be debian developoers,
 and maintainers), the criteria for the bug severity ought to be as
 objective as possible. 

	Whether a bug has enough impact on the system that releasing
 it would be detrimental is a judgment call, and we have appointed a
 single person whose judgment we all have agreed to trust for the
 duration on matters related to the release.  These criteria is where
 a human can exercise common sense, and involves a number of criteria
 (some thing that is RC before may not longer be deemed to be such as
 the release nears).

	Based on his posting on -ctte, I thought aj agreed with me.


	But if the bug severity is supposed to be fixed and objective,
 and RCness is separate, I am confused why the xutils bug was
 _upgraded_ to serious, and these other serious bugs are
 downgraded. (We already have bugscan to prevent the count from
 getting confusing due to all these serious but not rc bugs).

 Branden> My personal opinion is that the BTS should serve the
 Branden> developers first and foremost.  It *should* also be able to
 Branden> serve the users, but until it has a conception of bugs
 Branden> against versions of packages as opposed to a non-temporal
 Branden> notion of a package, it's going to fill that role only
 Branden> poorly.  I think the Release Manager has other tools at his
 Branden> disposal for discernment of release-criticality.  Whether
 Branden> those tools work to the satisfaction of a given Release
 Branden> Manager or not is another question.

	Quite so. But I think a serious bug should still be a serious
 bug, and no subject to anyone whims -- including the package
 maintainer.

	manoj
-- 
 Spelling is a lossed art.
Manoj Srivastava   <srivasta@debian.org>  <http://www.debian.org/%7Esrivasta/>
1024R/C7261095 print CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C



Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>, Branden Robinson <branden@debian.org>, tech-ctte@packages.qa.debian.org, xfree86@packages.qa.debian.org:
Bug#97671; Package tech-ctte,xutils. Full text and rfc822 format available.

Acknowledgement sent to Manoj Srivastava <srivasta@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>, Branden Robinson <branden@debian.org>, tech-ctte@packages.qa.debian.org, xfree86@packages.qa.debian.org. Full text and rfc822 format available.

Message #87 received at 97671@bugs.debian.org (full text, mbox):

From: Manoj Srivastava <srivasta@debian.org>
To: debian-devel@lists.debian.org
Cc: 97671@bugs.debian.org
Subject: Re: 88 Priority violations in woody
Date: Tue, 30 Apr 2002 20:40:37 -0500
Hi,

	I hate following up my own post.  I should also mention that I
 understand that release management is a stressful job, and often a
 thankless one.  Add to that this release followed a whole new
 protocol, and processes have not yet stabilized. 

	manoj
-- 
 It's great to be smart 'cause then you know stuff.
Manoj Srivastava   <srivasta@debian.org>  <http://www.debian.org/%7Esrivasta/>
1024R/C7261095 print CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C



Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>, Branden Robinson <branden@debian.org>, tech-ctte@packages.qa.debian.org, xfree86@packages.qa.debian.org:
Bug#97671; Package tech-ctte,xutils. Full text and rfc822 format available.

Acknowledgement sent to Manoj Srivastava <srivasta@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>, Branden Robinson <branden@debian.org>, tech-ctte@packages.qa.debian.org, xfree86@packages.qa.debian.org. Full text and rfc822 format available.

Message #92 received at 97671@bugs.debian.org (full text, mbox):

From: Manoj Srivastava <srivasta@debian.org>
To: debian-devel@lists.debian.org
Cc: 97671@bugs.debian.org
Subject: Re: Bug#97671: 88 Priority violations in woody
Date: Tue, 30 Apr 2002 20:36:16 -0500
>>"Branden" == Branden Robinson <branden@debian.org> writes:

 Branden> The issue is for me is twofold: about the package maintainer
 Branden> being empowered to manage his own bug list for triage
 Branden> purposes, and about the limits of the Release Manager' or
 Branden> another developer's power to make decisions for another
 Branden> developer.

	The bug severity is well defined: it violates a must directive
 of policy, and this makes it a serious bug, no matter what anyone,
 including the maintainer, thinks. (If my postinst does rm -rf /; it
 is a critical bug, no matter what I think)

	manoj
-- 
 Never put off till run-time what you can do at compile-time. Gries
Manoj Srivastava   <srivasta@debian.org>  <http://www.debian.org/%7Esrivasta/>
1024R/C7261095 print CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C



Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>, Branden Robinson <branden@debian.org>, tech-ctte@packages.qa.debian.org, xfree86@packages.qa.debian.org:
Bug#97671; Package tech-ctte,xutils. Full text and rfc822 format available.

Acknowledgement sent to Anthony Towns <aj@azure.humbug.org.au>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>, Branden Robinson <branden@debian.org>, tech-ctte@packages.qa.debian.org, xfree86@packages.qa.debian.org. Full text and rfc822 format available.

Message #97 received at 97671@bugs.debian.org (full text, mbox):

From: Anthony Towns <aj@azure.humbug.org.au>
To: debian-devel@lists.debian.org
Subject: Re: Bug#97671: 88 Priority violations in woody
Date: Wed, 1 May 2002 15:32:04 +1000
On Tue, Apr 30, 2002 at 08:08:44PM -0500, Manoj Srivastava wrote:
> 	But if the bug severity is supposed to be fixed and objective,
>  and RCness is separate, I am confused why the xutils bug was
>  _upgraded_ to serious, and these other serious bugs are
>  downgraded. (We already have bugscan to prevent the count from
>  getting confusing due to all these serious but not rc bugs).

The "Priority mismatch" bugs were closed, not downgraded, and that was
done because they're already being tracked outside of the BTS in a much
more convenient way. One problem with them is that we simply can't fix
many of them (the hppa libstdc++ bugs) -- it's more important to have
i386 not have non-standard packages marked as standard than to have
hppa's priorities consistent. Another problem is that to have the bugs
fixed, ftpmaster needs to handle them, and having 80 bugs reassigned
to ftpmaster over the next couple of days is unhelpful in the extreme.
Another problem, really, is that that clause should never have been
made a "must" in the first place -- it led existing practice rather
than following it (see bug 64437, greping for "not depend on packages"
for historical context, if you like).

Cheers,
aj

-- 
Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. GPG signed mail preferred.

     ``BAM! Science triumphs again!'' 
                    -- http://www.angryflower.com/vegeta.gif


-- 
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org





Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>, tech-ctte@packages.qa.debian.org, xfree86@packages.qa.debian.org:
Bug#97671; Package tech-ctte,xutils. Full text and rfc822 format available.

Acknowledgement sent to Branden Robinson <branden@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>, tech-ctte@packages.qa.debian.org, xfree86@packages.qa.debian.org. Full text and rfc822 format available.

Message #102 received at 97671@bugs.debian.org (full text, mbox):

From: Branden Robinson <branden@debian.org>
To: debian-devel@lists.debian.org
Cc: Clint Adams <schizo@debian.org>, 97671@bugs.debian.org
Subject: Re: command -v in postinsts violating policy
Date: Sun, 26 May 2002 16:03:44 -0500
[Message part 1 (text/plain, inline)]
On Sun, May 26, 2002 at 03:25:14PM +1000, Anthony Towns wrote:
> On Sat, May 25, 2002 at 04:30:58PM -0400, Clint Adams wrote:
> > > - recheck a month or two after woody's release, then file serious bugs for
> > >   packages that haven't been fixed by then.
> > That works for me.
> 
> For reference, these shouldn't even be filed as serious bugs: they don't
> break anything.

I'd like to invite Manoj Srivastava to dispute this assertion.

http://bugs.debian.org/97671

(From a conversation Anthony and I had in IRC, Anthony has changed his
stance on that bug report, though I am not sure he made that clear to
the Technical Committee.)

-- 
G. Branden Robinson                |    I'm sorry if the following sounds
Debian GNU/Linux                   |    combative and excessively personal,
branden@debian.org                 |    but that's my general style.
http://people.debian.org/~branden/ |    -- Ian Jackson
[Message part 2 (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>, tech-ctte@packages.qa.debian.org, xfree86@packages.qa.debian.org:
Bug#97671; Package tech-ctte,xutils. Full text and rfc822 format available.

Acknowledgement sent to Branden Robinson <branden@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>, tech-ctte@packages.qa.debian.org, xfree86@packages.qa.debian.org. Full text and rfc822 format available.

Message #107 received at 97671@bugs.debian.org (full text, mbox):

From: Branden Robinson <branden@debian.org>
To: debian-policy@lists.debian.org
Cc: 97671@bugs.debian.org
Subject: Re: RFD: Essential packages, /, and /usr
Date: Fri, 21 Jun 2002 12:27:47 -0500
[Message part 1 (text/plain, inline)]
On Sat, Jun 22, 2002 at 01:13:47AM +1000, Anthony Towns wrote:
> Then please, pay attention. I've explained this a dozen times on this
> list already, so if you need a different wording surely there's someone
> out there how can provide it.
> 
> Release critical bugs are _very_ rare. They're not for problems that we're
> annoyed or embarrased about having, they're not for policy violations
> in general, they're not for setting goals that need to be done in lots
> of packages.
> 
> They are *purely* for those issues which are so severe that they're worth
> removing packages because of, or saying "I'm sorry, we can't release on the
> day I said, because these issues are unresolved."
> 
> I had hoped that letting policy have some influence on which policy issues
> should be considered release-critical would help ensure consistency
> and a deeper analysis of potential release-critical issues. Instead it
> seems to be an excuse for people to raise every other policy issue to
> release-critical status, and I have to either repeatedly argue against
> it and live with all the mistakes made anyway (like the "must" idiocy
> related to /bin/sh).
> 
> And yes, after eighteen months to two years of having to explain this
> again and again and again and again -- in spite of it being pretty
> clearly written in policy itself -- my patience is pretty short on the
> whole issue.

If Mohammed cannot go to the mountain, perhaps the mountain must come to
Mohammed.

We discussed this on IRC a month or so ago.  For the benefit of everyone
else here, I'll re-hash it as I remember it.  Feel free to correct me if
I've misremembered.

If:

* "Release critical bugs are _very_ rare."; and
* Release critical bugs should be the domain of the Release Manager,

Then we really don't need a tight connection between the "serious"
severity and release-criticality at all.  Release-criticality can be a
tag -- whether that is expressed in debbugs along with "security",
"moreinfo", "patch" and so forth or in a webpage like bugscan is
immaterial.

This tag -- no matter how it is expressed -- is the Release Manager's
domain.  People can propose that a bug be treated as release-critical
and, perhaps, if it seems warranted, we can make this a debbugs tag and
possibly automatically set it for all critical, grave, and serious bugs.

The Release Manager can strip the "release-critical" tag off of any bug
he wants.  This is how things have *always* worked in reality.  If a bug
is truly a showstopper for a release, we don't release with it.  We
either wait, fix the bug, or drop the package.

I honestly believe this mechanism would head off most of these catfights
at the pass.  Proper usage of "must" vs. "should" in the Policy manual?
Immaterial.  Mass-filing of serious bugs as public service or
masturbatory frenzy?  Immaterial.  Release-critical?  Release Manager's
call, period (unless someone bothers to appeal to the Technical
Committee -- not a process that is likely to get one a speedy remedy :).

And, while we're at it, this would enable us to re-establish a
maintainer's discretionary power over bug severities, even "serious"
ones.  As Josip Rodin noted in debian-devel, sometimes even a violation
of a "must" directive really isn't a big deal.  Sometimes it just
doesn't make that much difference.  Whether that's due to policy
inflating the importance of compliance with a certain detail, or due to
unusual circumstances doesn't matter.  The Release Manager gets to
attach the "release-critical" tag to any bug he wants, and the package
maintainer is expected to act on that bug if he wants his package to
release with Debian.  If he doesn't, he can alter the severities of his
bugs pretty much at his discretion.

There is a lot more discussion of this issue in the logs of Bug #97671.

http://bugs.debian.org/97671

N.B.: the above is my recollection of a conversation, and should not be
construed as representing the opinions of anyone else unless they say
so.

-- 
G. Branden Robinson                |    I've made up my mind.  Don't try to
Debian GNU/Linux                   |    confuse me with the facts.
branden@debian.org                 |    -- Indiana Senator Earl Landgrebe
http://people.debian.org/~branden/ |
[Message part 2 (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>, Branden Robinson <branden@debian.org>, tech-ctte@packages.qa.debian.org, xfree86@packages.qa.debian.org:
Bug#97671; Package tech-ctte,xutils. Full text and rfc822 format available.

Acknowledgement sent to Manoj Srivastava <srivasta@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>, Branden Robinson <branden@debian.org>, tech-ctte@packages.qa.debian.org, xfree86@packages.qa.debian.org. Full text and rfc822 format available.

Message #112 received at 97671@bugs.debian.org (full text, mbox):

From: Manoj Srivastava <srivasta@debian.org>
To: debian-policy@lists.debian.org
Cc: 97671@bugs.debian.org
Subject: Re: RFD: Essential packages, /, and /usr
Date: Sat, 22 Jun 2002 02:02:00 -0500
>>"Branden" == Branden Robinson <branden@debian.org> writes:

 Branden> If:

 Branden> * "Release critical bugs are _very_ rare."; and
 Branden> * Release critical bugs should be the domain of the Release Manager,

 Branden> Then we really don't need a tight connection between the
 Branden> "serious" severity and release-criticality at all.
 Branden> Release-criticality can be a tag -- whether that is
 Branden> expressed in debbugs along with "security", "moreinfo",
 Branden> "patch" and so forth or in a webpage like bugscan is
 Branden> immaterial.

 Branden> This tag -- no matter how it is expressed -- is the Release
 Branden> Manager's domain.  People can propose that a bug be treated
 Branden> as release-critical and, perhaps, if it seems warranted, we
 Branden> can make this a debbugs tag and possibly automatically set
 Branden> it for all critical, grave, and serious bugs.

 Branden> The Release Manager can strip the "release-critical" tag off
 Branden> of any bug he wants.  This is how things have *always*
 Branden> worked in reality.  If a bug is truly a showstopper for a
 Branden> release, we don't release with it.  We either wait, fix the
 Branden> bug, or drop the package.

	I find myself in strong and vehement agrement with Branden on
 this point.

	manoj

-- 
 "I think the sky is blue because it's a shift from black through
 purple to blue, and it has to do with where the light is.  You know,
 the farther we get into darkness, and there's a shifting of color of
 light into the blueness, and I think as you go farther and farther
 away from the reflected light we have from the sun or the light
 that's bouncing off this earth, uh, the darker it gets ... I think if
 you look at the color scale, you start at black, move it through
 purple, move it on out, it's the shifting of color.  We mentioned
 before about the stars singing, and that's one of the effects of the
 shifting of colors." Pat Robertson, The 700 Club
Manoj Srivastava   <srivasta@debian.org>  <http://www.debian.org/%7Esrivasta/>
1024R/C7261095 print CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C



Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>, Branden Robinson <branden@debian.org>, tech-ctte@packages.qa.debian.org, xfree86@packages.qa.debian.org:
Bug#97671; Package tech-ctte,xutils. Full text and rfc822 format available.

Acknowledgement sent to Anthony Towns <aj@azure.humbug.org.au>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>, Branden Robinson <branden@debian.org>, tech-ctte@packages.qa.debian.org, xfree86@packages.qa.debian.org. Full text and rfc822 format available.

Message #117 received at 97671@bugs.debian.org (full text, mbox):

From: Anthony Towns <aj@azure.humbug.org.au>
To: Manoj Srivastava <srivasta@debian.org>, 97671@bugs.debian.org
Cc: debian-policy@lists.debian.org
Subject: Re: Bug#97671: RFD: Essential packages, /, and /usr
Date: Sat, 22 Jun 2002 21:29:42 +1000
[Message part 1 (text/plain, inline)]
On Sat, Jun 22, 2002 at 02:02:00AM -0500, Manoj Srivastava wrote:
> >>"Branden" == Branden Robinson <branden@debian.org> writes:
>  Branden> * "Release critical bugs are _very_ rare."; and
>  Branden> * Release critical bugs should be the domain of the Release Manager,
>  Branden> Then we really don't need a tight connection between the
>  Branden> "serious" severity and release-criticality at all.

Sorry, but this doesn't follow. Treating "serious" as a severity or a
tag is largely immaterial, and the fundamental point of the "serious"
severity or tag is as an aid to release management.

>  Branden> The Release Manager can strip the "release-critical" tag off
>  Branden> of any bug he wants.  This is how things have *always*
>  Branden> worked in reality.  

No, it's not. In reality, things have always just been ignored, rather
than being formally stripped of "release-criticality".

> 	I find myself in strong and vehement agrement with Branden on
>  this point.

Branden brought up a number of interesting and good points (and, even
better, simple) in the discussion he's referencing, but it was at the end
of a pretty long winded and vicious argument about the referenced bug,
and there was too much of an "agree to anything just to get this over
with" on my behalf. Which isn't to say I don't agree with much of it,
but I need some time to sit and look at this calmly before I can have
a considered opinion on it.

OTOH, there is one part that I have had plenty of opportunity to think
about: and personally I don't believe debian-policy should have _any_
influence over the severity of a bug. If there're already good reasons for
increasing the severity of a bug without policy, then that's good enough.
If there aren't, policy shouldn't be forcing them on people.

There're plenty of ways we can improve Debian without raising the members
of the policy list as being better or more powerful than other developers.

Beyond _all_ other things, this is the major problem with the serious
severity and release-critical bugs (and debian-policy@) at the moment.

And as much as I'd like to be able to say it's better to have -policy be
"better and more powerful" than the release manager for general democratic
and consensus principles, I'm sorry, but it simply hasn't worked, and
I'm yet to see *anyone* even remotely interested in making it work.

Cheers,
aj

-- 
Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. GPG signed mail preferred.

     ``BAM! Science triumphs again!'' 
                    -- http://www.angryflower.com/vegeta.gif
[Message part 2 (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>, tech-ctte@packages.qa.debian.org, xfree86@packages.qa.debian.org:
Bug#97671; Package tech-ctte,xutils. Full text and rfc822 format available.

Acknowledgement sent to Branden Robinson <branden@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>, tech-ctte@packages.qa.debian.org, xfree86@packages.qa.debian.org. Full text and rfc822 format available.

Message #122 received at 97671@bugs.debian.org (full text, mbox):

From: Branden Robinson <branden@debian.org>
To: debian-policy@lists.debian.org
Cc: 97671@bugs.debian.org, debian-ctte@lists.debian.org
Subject: Re: Bug#97671: RFD: Essential packages, /, and /usr
Date: Sat, 22 Jun 2002 14:28:16 -0500
[Message part 1 (text/plain, inline)]
On Sat, Jun 22, 2002 at 09:29:42PM +1000, Anthony Towns wrote:
> Sorry, but this doesn't follow. Treating "serious" as a severity or a
> tag is largely immaterial, and the fundamental point of the "serious"
> severity or tag is as an aid to release management.

That may be its intent, but apparently that's not how it's being used a
large proportion of the time.

> >  Branden> The Release Manager can strip the "release-critical" tag off
> >  Branden> of any bug he wants.  This is how things have *always*
> >  Branden> worked in reality.  
> 
> No, it's not. In reality, things have always just been ignored, rather
> than being formally stripped of "release-criticality".

My statement does not assert that the Release Manager has undertaken any
formal procedure.  I'm saying that it is the case that a bug isn't de
facto release critical if the Release Manager doesn't treat it thus.

> And as much as I'd like to be able to say it's better to have -policy be
> "better and more powerful" than the release manager for general democratic
> and consensus principles, I'm sorry, but it simply hasn't worked, and
> I'm yet to see *anyone* even remotely interested in making it work.

I think these are largely orthogonal issues.  Debian Policy is a great
tool, but ill-suited to determining release viability for an individual
package or for the distribution as a whole.

In my opinion and experience, a Debian Policy is better suited to
establishing and enforcing objective criteria that ultimately serve to
improve the quality of Debian packages, and of the distribution as a
whole.  Due to the objectivity and specificity of the criteria it
establishes, it is easy for a large number of people to participate in
the process of crafting Policy in a democratical and consensus-driven
manner.

Release management is a highly subjective process -- at least the way
Debian does it -- because we always settle for something significantly
less than perfection (IMO that's a good thing).  The establishment of
subjective criteria for "good enough" is often influenced by external
factors like upstream releases, security issues, Debian's non-package
infrastructure (automated security builds, the mirror network, etc.) and
the date on the calendar.  Due to that, I think it makes more sense for
release management by an individual or a small team of people who work
together well.

The bottom line for me is that it's difficult to achieve consensus on
subjective issues.  I think our approach to the twin nemeses of policy
and release management need to reflect this fact better than they do at
present.

-- 
G. Branden Robinson                |
Debian GNU/Linux                   |      If encryption is outlawed, only
branden@debian.org                 |      outlaws will @goH7Ok=<q4fDj]Kz?.
http://people.debian.org/~branden/ |
[Message part 2 (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>, Branden Robinson <branden@debian.org>, tech-ctte@packages.qa.debian.org, xfree86@packages.qa.debian.org:
Bug#97671; Package tech-ctte,xutils. Full text and rfc822 format available.

Acknowledgement sent to Ian Jackson <ian@davenant.greenend.org.uk>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>, Branden Robinson <branden@debian.org>, tech-ctte@packages.qa.debian.org, xfree86@packages.qa.debian.org. Full text and rfc822 format available.

Message #127 received at 97671@bugs.debian.org (full text, mbox):

From: Ian Jackson <ian@davenant.greenend.org.uk>
To: Manoj Srivastava <srivasta@debian.org>, 97671@bugs.debian.org, Anthony Towns <aj@azure.humbug.org.au>, Branden Robinson <branden@debian.org>
Cc: debian-ctte@lists.debian.org, leader@debian.org, debian-policy@lists.debian.org
Subject: Re: Release-critical bugs, and #97671
Date: Mon, 24 Jun 2002 00:02:34 +0100
This discussion makes it clear to me that the decision here is not
technical, it is a question of process.  As such it should be made by
the project leadership and/or bug tracking administrators.

I therefore hereby propose the following resolution of the Technical
Committee:

 We note that

 * This dispute contains both technical and process (ie political)
   elements; however, it has not been possible to identify a clear
   technical dispute which as at the heart of the problem.
 * The heart of the problem seems to be a disagreement over the proper
   use of various tagging features of the bug tracking system.  This
   is a process matter.
 * We do not feel that this decision is within our normal remit; the
   constitution suggests that the project leader and delegates would
   be responsible.
 * The bug system administrators would seem to be the most relevant
   delegates.
 * We are not sufficiently united in our opinions that we feel that
   the Committee should issue any formal advice or opinion.
 * Should a disputed technical question be raised, we would be happy
   to answer it.

 We therefore recommend that

 * The bug system administrators and/or the project leader or some
   other delegates appointed by the project leader decide on the
   proper use of the bug system features.

Ian.



Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>, Branden Robinson <branden@debian.org>, tech-ctte@packages.qa.debian.org, xfree86@packages.qa.debian.org:
Bug#97671; Package tech-ctte,xutils. Full text and rfc822 format available.

Acknowledgement sent to Ian Jackson <ian@davenant.greenend.org.uk>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>, Branden Robinson <branden@debian.org>, tech-ctte@packages.qa.debian.org, xfree86@packages.qa.debian.org. Full text and rfc822 format available.

Message #132 received at 97671@bugs.debian.org (full text, mbox):

From: Ian Jackson <ian@davenant.greenend.org.uk>
To: 97671@bugs.debian.org, Anthony Towns <aj@azure.humbug.org.au>, Branden Robinson <branden@debian.org>, debian-ctte@lists.debian.org, leader@debian.org
Subject: Re: Release-critical bugs, and #97671
Date: Wed, 26 Jun 2002 21:14:33 +0100
Ian Jackson writes ("Re: Release-critical bugs, and #97671"):
> I therefore hereby propose the following resolution of the Technical
> Committee:

(Full resolution below.)

No-one has commented to say they object to us punting on this one, so
I hereby call for a vote on the resolution I proposed on Monday.  If
anyone votes against, or proposes an amendment, I'll probably withdraw
the resolution so we can talk about it.

Ian.

-8<-

We note that

* This dispute contains both technical and process (ie political)
  elements; however, it has not been possible to identify a clear
  technical dispute which as at the heart of the problem.
* The heart of the problem seems to be a disagreement over the proper
  use of various tagging features of the bug tracking system.  This
  is a process matter.
* We do not feel that this decision is within our normal remit; the
  constitution suggests that the project leader and delegates would
  be responsible.
* The bug system administrators would seem to be the most relevant
  delegates.
* We are not sufficiently united in our opinions that we feel that
  the Committee should issue any formal advice or opinion.
* Should a disputed technical question be raised, we would be happy
  to answer it.

We therefore recommend that

* The bug system administrators and/or the project leader or some
  other delegates appointed by the project leader decide on the
  proper use of the bug system features.

-- 
Ian Jackson, at home.           Local/personal: ijackson@chiark.greenend.org.uk
ian@davenant.greenend.org.uk       http://www.chiark.greenend.org.uk/~ijackson/



Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>, Branden Robinson <branden@debian.org>, tech-ctte@packages.qa.debian.org, xfree86@packages.qa.debian.org:
Bug#97671; Package tech-ctte,xutils. Full text and rfc822 format available.

Acknowledgement sent to Ian Jackson <ian@davenant.greenend.org.uk>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>, Branden Robinson <branden@debian.org>, tech-ctte@packages.qa.debian.org, xfree86@packages.qa.debian.org. Full text and rfc822 format available.

Message #137 received at 97671@bugs.debian.org (full text, mbox):

From: Ian Jackson <ian@davenant.greenend.org.uk>
To: 97671@bugs.debian.org, Anthony Towns <aj@azure.humbug.org.au>, Branden Robinson <branden@debian.org>, debian-ctte@lists.debian.org, owner@bugs.debian.org, leader@debian.org
Subject: Re: Release-critical bugs, and #97671
Date: Fri, 5 Jul 2002 19:25:06 +0100
The Technical Committee has passed the following resolution, regarding
the dispute surrounding Bug#97671 and the proper use of the Severity
tag and other BTS features:

   We note that

   * This dispute contains both technical and process (ie political)
     elements; however, it has not been possible to identify a clear
     technical dispute which as at the heart of the problem.
   * The heart of the problem seems to be a disagreement over the proper
     use of various tagging features of the bug tracking system.  This
     is a process matter.
   * We do not feel that this decision is within our normal remit; the
     constitution suggests that the project leader and delegates would
     be responsible.
   * The bug system administrators would seem to be the most relevant
     delegates.
   * We are not sufficiently united in our opinions that we feel that
     the Committee should issue any formal advice or opinion.
   * Should a disputed technical question be raised, we would be happy
     to answer it.

   We therefore recommend that

   * The bug system administrators and/or the project leader or some
     other delegates appointed by the project leader decide on the
     proper use of the bug system features.

As Chairman, I shall arrange for this decision to be appropriately
documented and work out the disposition of the bug report.

Thanks for your attention,
Ian.



Bug reassigned from package `tech-ctte,xutils' to `bugs.debian.org, project'. Request was from Ian Jackson <ian@davenant.greenend.org.uk> to control@bugs.debian.org. Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, owner@bugs.debian.org (Darren O. Benham and others), debian-project@lists.debian.org, bugs.debian.org@packages.qa.debian.org, project@packages.qa.debian.org:
Bug#97671; Package bugs.debian.org, project. Full text and rfc822 format available.

Acknowledgement sent to Anthony Towns <aj@azure.humbug.org.au>:
Extra info received and forwarded to list. Copy sent to owner@bugs.debian.org (Darren O. Benham and others), debian-project@lists.debian.org, bugs.debian.org@packages.qa.debian.org, project@packages.qa.debian.org. Full text and rfc822 format available.

Message #144 received at 97671@bugs.debian.org (full text, mbox):

From: Anthony Towns <aj@azure.humbug.org.au>
To: 97671@bugs.debian.org
Cc: control@bugs.debian.org, leader@debian.org, debian-ctte@lists.debian.org, Branden Robinson <branden@debian.org>
Subject: Re: Bug#97671: xutils: why is rstart.real a conffile?
Date: Tue, 12 Nov 2002 02:28:34 +1000
reassign 97671 tech-ctte
thanks

> Anthony has offered no basis for his latest manipulation of my bug list
> aside from the derisive remark in the Subject:.
> 
> I am requesting the Technical Committee's resolution of this dispute
> under Section 6.1 of the Constitution.  Both parties stipulate that the
> bug in question is not release critical.  Therefore, this bug does not
> fall within the Release Manager's jurisdiction, and I am not aware of
> any other grounds upon which the package maintainer's discretion can be
> overridden on issues like this.

>   We therefore recommend that
>
>   * The bug system administrators and/or the project leader or some
>     other delegates appointed by the project leader decide on the
>     proper use of the bug system features.

I believe I speak for everyone on owner@bugs.debian.org in saying that
the bug system administrators do not have an opinion on this matter,
or other policy matters for use of the BTS in general.

Obviously, I, personally, do, and if you want to punt to the release
manager, you can make use of that. It's not clear that's particularly
appropriate, since the question is surely as much "was this the right
thing to do" as "does Anthony have any right to do it". My opinion on
the use of severities and the consideration of bugs as release-critical
or not is as follows:

	(1) All bugs have an objectively defined severity, which can be
	    determined by reference to the bug submission guidelines,
	    policy, and similar resources. The principle is that bugs
	    that have a similar effect should have a similar severity.

	    Unfortunately, this "objective reality" is somewhat poorly
	    documented, and can be readily misinterpreted; eg the policy
	    for woody was that as long as the package had ever been
	    built on an architecture, "doesn't autobuild" bugs were
	    not RC, whereas this is not the case for sarge; without any
	    documentation changing. The only particularly effective way of
	    finding this out is to ask on debian-devel@lists.debian.org.

	(2) By default, the release manager will consider all bugs that
	    have a severity of serious, grave or critical to be
	    show-stoppers: either on a per-package basis, or for the
	    entire release. This default can and often will be overriden
	    by the subjective judgement of the release manager: either
	    to say that some less severe bugs will also be considered
	    show-stoppers, or that some serious, grave or critical bugs
	    will not be considered show-stoppers.

	(3) As such, the issue in question should remain filed as
	    "serious" (as it is a clear violation of the FHS), and
	    should not have been considered a show-stopper bug for
	    woody's release (based on the release manager's judgement,
	    with the support of the package maintainer).

At this point, afaics, the tech-ctte may wish to do any of:

	* Decide that use of severities in the BTS is a technical issue,
	  and determine a policy for this, and apply that policy to the
	  bug in question.

	* Decide on what the appropriate resolution of the matter for
	  this bug is, without reaching a conclusion in the general case,
	  and implement it.

	* If I'm the appropriate delegate for setting the policy for
	  use of severities at issue here, determine if the policy as
	  I've presented has been followed for this bug.

	* Punt to the DPL under 5.1(4) ("Make any decision for whom noone
	  else has responsibility").



For your interest, I'm now with it enough to comment on some of the
alternatives that've been discussed, that I've avoided being drawn
on previously.

Branden suggested:

] The Release Manager can strip the "release-critical" tag off of any bug
] he wants.  This is how things have *always* worked in reality.  If a bug
] is truly a showstopper for a release, we don't release with it.  We
] either wait, fix the bug, or drop the package.
] 
] I honestly believe this mechanism would head off most of these catfights
] at the pass.  Proper usage of "must" vs. "should" in the Policy manual?
] Immaterial.  Mass-filing of serious bugs as public service or
] masturbatory frenzy?  Immaterial.  Release-critical?  Release Manager's
] call, period (unless someone bothers to appeal to the Technical
] Committee -- not a process that is likely to get one a speedy remedy :).

This doesn't work -- we've already tried it with the "important" severity.
The result is that all these things that Branden claims don't matter
really end up not mattering, but that stops them helping too -- people
file their bugs at whatever severity they think is appropriate and
frequently get it wrong. The release manager then spends an hour or two
*every single day* correcting the errors. It's frustrating, horribly time
consuming, and a thoroughly ineffective use of time. It also seems likely
to increase the risk of people marking a bug with too low a severity,
and thus increasing the chance an unacceptably buggy package will be
released without the release manager being able to do anything about it
(whether that be encourage other people to fix it, or just stop the
package from being released).

What we do now is, effectively, add an additional tag to release-critical
bugs that aren't going to be treated as such: for potato it was an
[IGNORE] in the release critical bug list, for woody it should've been
the same except some scripts were broken, and for sarge it will probably
a real "ignore" or "allow-release" tag. The benefit of doing it this
way rather than dropping the severity is that it makes it easy for the
release manager to keep track of the bugs he needs to be responsible for;
even the ones he's decided to allow remain unfixed.

( Hrm, an "allow-release" tag might be a better way of doing things than )
( checking there aren't more bugs in unstable than there are in testing. )
             O
          o    (thought bubble, no response nor even comprehension required)
       . 



I don't believe there's any real value in changing the BTS to treat
"ignored" bugs specially in a way that would be useful for Branden's
triage; although generalising it to allow the maintainer to arbitrarily
re-prioritise bugs would probably be a win -- the idea being you could use
a different URL and get the bugs in the order in which the maintainer will
be focussing on them. (Which is to say, I won't be writing or applying
any patches for the former, although someone else on owner@bugs might, but
I'd probably be interested in seeing patches or good ideas for the latter)

Assuming the "pending" tag on Bug#143825 is for triage (since it hasn't
been closed in any of the uploads since the tag was applied) it's probably
better to add [lowpri] to the bug's subject, then use

  http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=xutils&exclude=subj:[lowpri]

to get the sanitized page. An inaccurate "pending" tag probably makes it
less likely for people to provide patches, etc, which would presumably
be a loss. Apologies if the assumption's incorrect, of course.

Cheers,
aj

-- 
Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. GPG signed mail preferred.

 ``If you don't do it now, you'll be one year older when you do.''



Bug reassigned from package `bugs.debian.org, project' to `tech-ctte'. Request was from Anthony Towns <aj@azure.humbug.org.au> to control@bugs.debian.org. Full text and rfc822 format available.

Information forwarded to tech-ctte@packages.qa.debian.org:
Bug#97671; Package tech-ctte. Full text and rfc822 format available.

Acknowledgement sent to Branden Robinson <branden@debian.org>:
Extra info received and filed, but not forwarded. Copy sent to tech-ctte@packages.qa.debian.org. Full text and rfc822 format available.

Message #151 received at 97671-quiet@bugs.debian.org (full text, mbox):

From: Branden Robinson <branden@debian.org>
To: leader@debian.org, debian-ctte@lists.debian.org
Cc: 97671-quiet@bugs.debian.org, debian-project@lists.debian.org, debian-policy@lists.debian.org
Subject: Re: Bug#97671: xutils: why is rstart.real a conffile?
Date: Mon, 11 Nov 2002 14:36:44 -0500
[Message part 1 (text/plain, inline)]
[-project and -policy, I CCed you because I'm raising issues relevant to
you; *please* honor the Mail-Followup-To: header!]

On Tue, Nov 12, 2002 at 02:28:34AM +1000, Anthony Towns wrote:
> >   We therefore recommend that
> >
> >   * The bug system administrators and/or the project leader or some
> >     other delegates appointed by the project leader decide on the
> >     proper use of the bug system features.

Would this include guidance on features like the opening vs. closing of
reports, which territory currently claimed by Ian Jackson's disputes
resolution document?

> Obviously, I, personally, do, and if you want to punt to the release
> manager, you can make use of that. It's not clear that's particularly
> appropriate, since the question is surely as much "was this the right
> thing to do" as "does Anthony have any right to do it".

My feeling as package maintainer is that, if you as Release Manager
don't regard it is a show-stopper for release, then I should be
permitted to prioritize the bug as I see fit.

> 	(1) All bugs have an objectively defined severity, which can be
> 	    determined by reference to the bug submission guidelines,
> 	    policy, and similar resources. The principle is that bugs
> 	    that have a similar effect should have a similar severity.
> 
> 	    Unfortunately, this "objective reality" is somewhat poorly
> 	    documented, and can be readily misinterpreted; eg the policy
> 	    for woody was that as long as the package had ever been
> 	    built on an architecture, "doesn't autobuild" bugs were
> 	    not RC, whereas this is not the case for sarge; without any
> 	    documentation changing. The only particularly effective way of
> 	    finding this out is to ask on debian-devel@lists.debian.org.

This is a pretty low level of objectivity, in practice.  So much so that
I think it's overstating the case to assert that "all bugs have an
objectively defined severity".

Furthermore, even excluding your second paragraph above, the definitions
of the bug severities do not apply consistent standards for evaluation.

"critical", "grave", and the first half of "serious" are fairly
objective standards.  Not pefectly, though: consider the fact that
folks routinely file grave or even critical bugs aginst X server
packages because the X server doesn't support their video hardware.
For them, "the package in question is unusable".

I worked with Chris Lawrence to sneak slightly improved definitions of
the bug severities into the reportbug package, and this has in fact
helped with severity inflation for X server bugs.

At any rate, we start to slip into subjectivity with the other
definitions.

serious
  ...or, in the package maintainer's opinion, makes the package
  unsuitable for release.
important
  a bug which has a major effect on the usability of a package...

What's a "major effect"?

minor
  a problem which doesn't affect the package's usefulness...

Some people feel that defects in manpages affect the package's
usefulness (if, for instance, the manpage really sucks).  Other people
may feel that no error in a manpage can possibly result in a bug of
severity other than "minor" or "wishlist".

wishlist
  for any feature request, and also for any bugs that are very difficult
  to fix due to major design considerations.

One man's grave bug is another man's feature request ("I want
accelerated 3D support on my NVidia card!").

Some people have trumpted loud and long about the "objectivity" of
the bug severities in the BTS.  I think, with all due respect, that
they're visualizing idealized Debian BTS, not the one we've actually
bothered to document.

Until and unless we have an algorithmic process for determining bug
severity that is largely[1] free of human judgement, we will not have
objectively defined bug severities.

Perhaps we can achieve this.  Perhaps we could have a tool like
reportbug ask the user a series of yes/no questions, and set of answers
would map to a severity.  To be a reliable mapping, of course, we're
going to have to do away with broad language like "usefulness" and
"major effect".

I propose something different, however.  I suggest we split the
difference.

How about having only *some* of the bug severities be deliberately
objective?  How about leaving the others to the maintainer's discretion?

I propose something like this:

critical
grave
-------------- objectivity threshold
serious
-------------- "RCness" threshold
important
normal
minor
wishlist

Furthermore, I suggest decoupling policy violations from bug severities.
Make a "policy-violation" tag that can be applied to bugs.

The "serious" definition would thus be rewritten to simply:

serious
  A bug which, in the package maintainer's opinion, makes the package
  unsuitable for usage in a production environment.

Consider the benefits to be gained by the above proposal:

* We have objectivity where we most need it.  We have little time for
  arguments about the severity of bugs that almost everyone can agree
  are Bad News.  Data loss?  Security holes?  Kernel panics?  Resolving
  these sorts of problems should be our highest priority.
* We don't try to impose objectivity where we may not really need it.
  Why have severity wars over "minor" versus "wishlist"?  (Or even, I'd
  suggest, "important" versus "normal".)  By holding to a principle of
  a completely objective set of bug severities, we will front-load a ton
  of arguments that we don't really have time for, and that I submit we
  don't really need to worry about.  I don't really have a problem,
  personally, with the existing definitions of "important", "normal",
  "minor", and "wishlist".  That the declaration is made by some that
  the BTS *already* has an objective set of bug severities suggests to
  me that other folks are happy with the current definitions as well.
  So my proposal is limited in its intrusiveness.
* The package maintainer has a way of flagging bugs for special
  attention by the Release Manager, "serious".  Once the package
  maintainer is satisfied with a package, if there are no grave or
  critical bugs, there is a simple mechanism for him to tell the Release
  Manager (and the katie suite), that it satisfies his standards of
  quality.
* Manoj has, if I recall correctively, derisively complained about usage
  of the Debian BTS as a personal to-do list for package maintainers.
  But that's what, in part, I think the BTS *should* be.  Let the
  package maintainer use it to triage problems, focus his energies, and
  drop hints to other developers about what he most needs help with.  It
  is not *necessarily* true that having the Debian BTS function as a
  to-do list for package maintainers means that it *cannot* serve other
  functions for the broader project as well.  Perhaps Manoj fears a
  scenario where a package maintainer swats a security hole bug down to
  "wishlist" because the maintainer would enjoy working on other things
  in the package more.  That is not legitimate use of the BTS at present
  and my proposal would not render it legitimate.

[The next point is a long one.]

* The current imperfection of the Debian Policy Manual causes us to lend
  more gravity to certain bugs, as a result of "a severe violation of
  Debian policy (that is, it violates a "must" or "required"
  directive)," than they deserve.  I know that Manoj has big plans for
  the Policy Manual.  I also know that some of his plans for the Policy
  Manual are not uncontroversial, and this fact plus the constraints on
  his time and the lack of other policy editors means that a
  re-realization of the Policy Manual as Manoj would like to see it is a
  ways down the road.  I suggest that until that day comes, or at least
  until it's visible on the horizon, we not have the "serious" severity
  drafted into service as a maul wielded to enforce Policy.  I share
  Manoj's concern that developers will scoff at Policy if there aren't
  any "consequences" for ignoring it; that's why I suggest a
  "policy-violation" tag (which, if we want, can be the sole domain of a
  delegated team of Policy Enforcers).  Mechanisms independent of the
  Debian BTS are thus easily employed to gauge a package's compliance
  with Policy, or at least how successful it's been at attracting the
  scornful attention of bugs with policy-violation tags.  The Release
  Manager can cooperate with the Policy Enforcers, or use his own
  mechanism, to decide whether or not to exclude a package from the
  release based upon the nature of quality of policy-violation tags
  against it.  It is uncontroversial that the Release Manager has this
  discretion, and I don't propose to remove it.

  As far as I can recall, I have yet to encounter anyone who can tell me
  with a straight face that #97671 is a big deal.  It's unappealing and
  unesthetic, but its practical consequences are extremely small,
  especially given that the functionality in question is virtually
  unused.  If we have a BTS that leads me, or other people, to spend
  time on this bug rather than, say, finding racy symlink-attack
  vulnerabilities in xdm, I think that's a misfeature of the BTS.  I
  *know* policy says I'm a bad person for letting #97671 exist.  I plead
  guilty to that.  However, Policy also mandates a lot of things more
  strongly than it should, perhaps.  A long time ago, Anthony Towns
  spent a lot of time trying to persuade me not to go nuts with "must"s
  versus "shoulds" in a policy proposal regarding fonts of the X Windows
  System.  I was intransigent on the point, and after some other changes
  to the proposed policy he withdrew his objection (maybe even seconded
  it, I don't recall).  The result today, however, is that some font
  packages for X might be subjected to severity inflation which is
  *objectively* accurate.  This makes no sense.  A bug should only be of
  serious severity if it's a serious bug.  Clobbering an existing
  fonts.dir file in your postinst is Serious.  Failing to put your fonts
  in the correct directory isn't (it doesn't break anything, it just
  might make your package worthless or tricky to use.)  The proper usage
  of MUST versus SHOULD in Policy is another long-running flamewar that
  hasn't been resolved yet, as far as I know.

  Please, let's isolate the damage from Policy flamewars.  I don't know
  what the Policy Manual will look like in a year or two years, but I do
  know that its current imperfections, or the threat of it falling into
  an unmaintained state if something bad should happen to Manoj, should
  not have disruptive effects on the Debian BTS.  With a
  "policy-violation" tag, policy violation bugs will be taken as
  seriously as the people responsible for managing them are assiduous.
  With a disciplined team of policy enforcers working hand-in-hand with
  the release manager, egregious policy violations will not be permitted
  to creep into a production release.  If we have no policy enforcers
  and the Policy manual lies fallow, the underutilized tag can do no
  harm, and can be categorically ignored by the RM because he knows no
  one is keeping up with them.  Furthermore, with this tag under the
  control of a team, deficiencies in the Policy Manual can be corrected
  on a discretionary basis; see my X font example above.  If they know
  that a "MUST" is in the Policy Manual that shouldn't be, they can act
  accordingly.

[Whew.]

> 	(2) By default, the release manager will consider all bugs that
> 	    have a severity of serious, grave or critical to be
> 	    show-stoppers: either on a per-package basis, or for the
> 	    entire release. This default can and often will be overriden
> 	    by the subjective judgement of the release manager: either
> 	    to say that some less severe bugs will also be considered
> 	    show-stoppers, or that some serious, grave or critical bugs
> 	    will not be considered show-stoppers.

Yup, that's the status quo, and it sounds fine to me.

> 	(3) As such, the issue in question should remain filed as
> 	    "serious" (as it is a clear violation of the FHS), and
> 	    should not have been considered a show-stopper bug for
> 	    woody's release (based on the release manager's judgement,
> 	    with the support of the package maintainer).

I disagree; see above.  :)

I think that because:

* the release manager feels it should not be considered a show-stopper
  bug; and
* the package maintainer feels it should not be considered a
  show-stopper bug; and
* no one has yet (IIRC) been willing to argue that the bug is more
  deserving of attention than several other important (or even normal)
  bugs currently filed against the same source package; and

any criterion which compels the bug to be regarded as "serious" in spite
of all of the above is flawed.

Therefore, we should change our criteria.  We should not mislead people
into thinking a non-serious (in its standard English usage) bug is
serious.

> Branden suggested:
> ] The Release Manager can strip the "release-critical" tag off of any bug
> ] he wants.  This is how things have *always* worked in reality.  If a bug
> ] is truly a showstopper for a release, we don't release with it.  We
> ] either wait, fix the bug, or drop the package.
[...]
> This doesn't work -- we've already tried it with the "important" severity.
[...]
> What we do now is, effectively, add an additional tag to release-critical
> bugs that aren't going to be treated as such: for potato it was an
> [IGNORE] in the release critical bug list, for woody it should've been
> the same except some scripts were broken, and for sarge it will probably
> a real "ignore" or "allow-release" tag.  The benefit of doing it this
> way rather than dropping the severity is that it makes it easy for the
> release manager to keep track of the bugs he needs to be responsible
> for; even the ones he's decided to allow remain unfixed.

Well, why not encapsulate this information into the BTS via tags?

The point I keep hammering on is that "releasability" is in actual fact
orthogonal to severity.  There is a strong correlation between high bug
severity and unsuitability for release, but it is no *more* than a
correlation.  This is a problem because the Release Manager -- at least
historically -- has not made release decisions based solely on
aggregated data.  He hasn't decided ("well, once we get down below 20 RC
bugs, we'll be good enough for release") without letting the nature of
those 20 bugs influence him in anyway.

The Release Manager, historically, has *always* cared about the specific
nature of each release-critical bug, and acted accordingly.  I think
this is sound policy, and I encourage you to stick to it (I haven't
gotten the impression you intend to do otherwise).

A high severity is good for getting your (the RM's) attention.  You
often want to keep track of a bug so filed, sometimes regardless of
whether the severity was inflated in the first place -- even according
to objective criteria -- or not.  The severity may go up or down, but
that's not in and of itself determinative of whether you care about it
or not.  Sounds like a good candidate for a tag, to me.  You care about
the bug, you put (or keep) the tag on.  You stop caring about the bug,
you tear the tag off.  Your tag, your call.  The package maintainer will
know that your eyes are on that bug.

[Consider our recent discussion regarding 4.2.1-3, #97671, and
propagation testing.  Among other things I didn't know, I didn't know if
you were still paying attention to that bug or not.  With this tag, I'd
have known.  Unless you stopped caring and forgot to take it off.  :)
But that's more easily rectified (I mail you about it and you reply "I
don't care about this anymore" and CC control@bugs to strip the tag)
than the converse, where you care about some bugs but the package
maintainer doesn't know you do.]

> ( Hrm, an "allow-release" tag might be a better way of doing things than )
> ( checking there aren't more bugs in unstable than there are in testing. )

I'm not wedded to the name or semantics of a "release-critical" tag.
I think the right thing to do is to equip the BTS with a device that
lets the Release Manager do his job efficiently.  I think a tag is it.
What it's named and what it means should be left mostly up to the RM.
(I say "mostly" because I think I might object to a tag called "fucked"
being applied to one of my packages.  :) )

> I don't believe there's any real value in changing the BTS to treat
> "ignored" bugs specially in a way that would be useful for Branden's
> triage;

By the same token, I don't think there's any real value in having the
BTS treat policy violations specially for triage purposes.  At least not
with Policy in its current form.  I may very well feel differently if
Manoj succeeds in thrusting his trident into the sea, threading the
conch shell, and bringing down a new Policy from Mount Sinai that's so
elegant it makes me weep in admiration.  :)

> although generalising it to allow the maintainer to arbitrarily
> re-prioritise bugs would probably be a win -- the idea being you could use
> a different URL and get the bugs in the order in which the maintainer will
> be focussing on them. (Which is to say, I won't be writing or applying
> any patches for the former, although someone else on owner@bugs might, but
> I'd probably be interested in seeing patches or good ideas for the latter)

Bugzilla has two different fields.  "Severity" and "Priority".  I'm
pretty sure I think that's a good idea, but as you say, you're not
willing to do it.  I don't know of anyone else who is, either.

Let us not let the vision of an ideal future BTS hamstring its operation
for us now.  We should not aggravate our suffering of miserable severity
flamewars as some sort of masochistic punishment for not implementing
certain features in the BTS.

Let the BTS be designed to work well for us today, not against a future
where we have a universally-agreed upon Policy Manual in which "must" is
never used where "should" will suffice.  When that day comes, it's easy
to tighten up the definition of "serious" if we want to.

> Assuming the "pending" tag on Bug#143825 is for triage (since it hasn't
> been closed in any of the uploads since the tag was applied) it's probably
> better to add [lowpri] to the bug's subject, then use
> 
>   http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=xutils&exclude=subj:[lowpri]
> 
> to get the sanitized page. An inaccurate "pending" tag probably makes it
> less likely for people to provide patches, etc, which would presumably
> be a loss. Apologies if the assumption's incorrect, of course.

It's not inaccurate; it's there to tell people curious about the bug
that I agree that it's a bug, it's been triaged, I'm aware of it, and
that I intend to fix it.  It's just not a high-priority item.  I want to
fix it right, which means Imake tweakage.  Imake doesn't really
know about FHS[2], which is suboptimal.  If it did, this problem, along
with others I dare not point out for fear of more and redundant serious
bugs getting filed, will go away.  Such a fix might also make it easier
for Debian to transition to shipping XFree86 in /usr instead of
/usr/X11R6.  Ooh, now *there's* a way to get Manoj to support lowering
the severity of this bug.  ;-)

It won't be hard to fix Imake in this way.  Just tedious.  I intend to
get to it before the next freeze.

[1] I qualify with "largely" because there will always be people who
split hairs over the meanings of simple words.  In arguing against the
concept of objective severities, I won't be so cruel to my opposition as
to hold them to a standard of *perfect* objectivity.  I just think that
it's very hard to attain even a moderate level of objectivity, and that
at present we haven't reached it.

[2] It knows about bits of it.  My plan is to have a "UseFHS" expando
and set a bunch of defines, probably in X11.tmpl, if it evaluates true.
Then of course one has to change linux.cf and any other .cf for which
the FHS might be relevant.

-- 
G. Branden Robinson                |     If you have the slightest bit of
Debian GNU/Linux                   |     intellectual integrity you cannot
branden@debian.org                 |     support the government.
http://people.debian.org/~branden/ |     -- anonymous
[Message part 2 (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>, tech-ctte@packages.qa.debian.org:
Bug#97671; Package tech-ctte. Full text and rfc822 format available.

Acknowledgement sent to Ian Jackson <ian@davenant.greenend.org.uk>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>, tech-ctte@packages.qa.debian.org. Full text and rfc822 format available.

Message #156 received at 97671@bugs.debian.org (full text, mbox):

From: Ian Jackson <ian@davenant.greenend.org.uk>
To: Anthony Towns <aj@azure.humbug.org.au>
Cc: 97671@bugs.debian.org, control@bugs.debian.org, leader@debian.org, debian-ctte@lists.debian.org, Branden Robinson <branden@debian.org>
Subject: Re: Bug#97671: xutils: why is rstart.real a conffile?
Date: Tue, 12 Nov 2002 19:19:09 +0000
Everyone: please do not CC debian-ctte on this discussion.

Anthony Towns writes ("Re: Bug#97671: xutils: why is rstart.real a conffile?"):
> reassign 97671 tech-ctte
> thanks

The Technical Committee has already referred this question to the
Bug System Administrators and the Project Leadership.  Quoting from
our resolution on the matter:

  We therefore recommend that

   * The bug system administrators and/or the project leader or some
     other delegates appointed by the project leader decide on the
     proper use of the bug system features.

While we did say

   * Should a disputed technical question be raised, we would be happy
     to answer it.

no disputed technical question has been clearly stated.

Please do not reassign this bug back to the Technical Committee.
The Technical Committee is not the correct body even for deciding who
should decide this.

Ie, take this damn thing away !

I'm going to reassign this bug to `project'.  Bdale, I think it'll
have to be up to you to sort out this inane turf war.

Ian.
(tetchy)



Bug reassigned from package `tech-ctte' to `project'. Request was from Ian Jackson <ian@davenant.greenend.org.uk> to control@bugs.debian.org. Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, debian-project@lists.debian.org:
Bug#97671; Package project. Full text and rfc822 format available.

Acknowledgement sent to Anthony Towns <aj@azure.humbug.org.au>:
Extra info received and forwarded to list. Copy sent to debian-project@lists.debian.org. Full text and rfc822 format available.

Message #163 received at 97671@bugs.debian.org (full text, mbox):

From: Anthony Towns <aj@azure.humbug.org.au>
To: control@bugs.debian.org
Cc: 169264@bugs.debian.org, 155374@bugs.debian.org, 169413@bugs.debian.org, 196234@bugs.debian.org, 189832@bugs.debian.org, 188877@bugs.debian.org, 190592@bugs.debian.org, 170820@bugs.debian.org, 97671@bugs.debian.org, 198337@bugs.debian.org, 143825@bugs.debian.org
Subject: pending meaning change
Date: Thu, 24 Jul 2003 17:08:23 +1000
tags 97671 - pending
tags 143825 - pending
tags 155374 - pending
tags 169264 - pending
tags 169413 - pending
tags 170820 - pending
tags 188877 - pending
tags 189832 - pending
tags 190592 - pending
tags 196234 - pending
tags 198337 - pending

thanks

The definition of the "pending" tag has been changed to:

]   pending
]          A solution to this bug has been found and an upload will be
]          made soon.                  

The (release critical) bugs above have been tagged pending for over a
month, so by the new definition the tag appears to not apply to the above
bugs.

-- 
Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. GPG signed mail preferred.

       ``Is this some kind of psych test?
                      Am I getting paid for this?''




Tags removed: pending Request was from Anthony Towns <aj@azure.humbug.org.au> to control@bugs.debian.org. Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, debian-project@lists.debian.org:
Bug#97671; Package project. Full text and rfc822 format available.

Acknowledgement sent to Branden Robinson <branden@debian.org>:
Extra info received and forwarded to list. Copy sent to debian-project@lists.debian.org. Full text and rfc822 format available.

Message #170 received at 97671@bugs.debian.org (full text, mbox):

From: Branden Robinson <branden@debian.org>
To: control@bugs.debian.org, 97671@bugs.debian.org, 143825-quiet@bugs.debian.org
Subject: this old thing again
Date: Thu, 24 Jul 2003 15:43:06 -0500
[Message part 1 (text/plain, inline)]
merge 97671 143825
severity normal
tag 97671 + help upstream
thanks

Unless the Release Manager intends to force (at least) the following
packages to play by the same rules ostensibly being enforced against
XFree86:

console-tools[1]
ncurses-base[2]
libc6[3]
ssh[4]
postfix[5]
gnome-libs-data[6]
various MTAs[7]

...this bug can't be release-critical except by the sheerest caprice.

[1] /etc/console-tools/default*.gz
[2] /etc/terminfo/*
[3] /etc/ld.so.cache
[4] /etc/ssh/ssh_host_key
[5] /etc/postfix/prng_exch
[6] /etc/mime-magic.dat
[7] /etc/aliases.db*

-- 
G. Branden Robinson                |
Debian GNU/Linux                   |     Cogitationis poenam nemo meretur.
branden@debian.org                 |
http://people.debian.org/~branden/ |
[Message part 2 (application/pgp-signature, inline)]

Tags added: help, upstream Request was from Branden Robinson <branden@debian.org> to control@bugs.debian.org. Full text and rfc822 format available.

Reply sent to Anthony Towns <aj@azure.humbug.org.au>:
You have taken responsibility. Full text and rfc822 format available.

Notification sent to Tollef Fog Heen <tollef@add.no>:
Bug acknowledged by developer. Full text and rfc822 format available.

Message #177 received at 97671-done@bugs.debian.org (full text, mbox):

From: Anthony Towns <aj@azure.humbug.org.au>
To: 97671-done@bugs.debian.org
Subject: Re: Bug#97671: tech ctte resolution requested re: severity of bug#97671/143825
Date: Fri, 25 Jul 2003 21:40:22 +1000
[Message part 1 (text/plain, inline)]
Branden,

Ian Jackson, as tech ctte chairman, wrote:
> The Technical Committee has already referred this question to the
> Bug System Administrators and the Project Leadership.  Quoting from
> our resolution on the matter:

Branden Robinson, in a mail to control@bugs.debian.org, wrote:
> merge 97671 143825
> severity normal
> tag 97671 + help upstream
> thanks

As the tech ctte have resolved not to do anything about this bug,
and two project leaders have refrained from touching it at all, you're
evidently not going to get a more authoritative judgement on the severity
of Bug#143825, than mine whether taken as either release manager or one
of the BTS maintainers. If you choose not to accept this, and cannot
get either the tech ctte or the DPL to actively support your position
overruling my judgement, but try to downgrade the bug nevertheless,
I'll add technical measures to stop that from happening. I'd appreciate
it if you refrain from wasting my time or your own in such a manner.

Closing this report with this message.

Cheers,
aj

-- 
Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. GPG signed mail preferred.

       ``Is this some kind of psych test?
                      Am I getting paid for this?''
[Message part 2 (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, debian-project@lists.debian.org:
Bug#97671; Package project. Full text and rfc822 format available.

Acknowledgement sent to Josip Rodin <joy@srce.hr>:
Extra info received and forwarded to list. Copy sent to debian-project@lists.debian.org. Full text and rfc822 format available.

Message #182 received at 97671@bugs.debian.org (full text, mbox):

From: Josip Rodin <joy@srce.hr>
To: 97671@bugs.debian.org
Subject: Re: Bug#97671: this old thing again
Date: Fri, 25 Jul 2003 14:26:34 +0200
On Thu, Jul 24, 2003 at 03:43:06PM -0500, Branden Robinson wrote:
> merge 97671 143825
> severity normal
> tag 97671 + help upstream
> thanks
> 
> Unless the Release Manager intends to force (at least) the following
> packages to play by the same rules ostensibly being enforced against
> XFree86:
> 
> console-tools[1]
> ncurses-base[2]
> libc6[3]
> ssh[4]
> postfix[5]
> gnome-libs-data[6]
> various MTAs[7]
> 
> ...this bug can't be release-critical except by the sheerest caprice.
> 
> [1] /etc/console-tools/default*.gz
> [2] /etc/terminfo/*
> [3] /etc/ld.so.cache
> [4] /etc/ssh/ssh_host_key
> [5] /etc/postfix/prng_exch
> [6] /etc/mime-magic.dat
> [7] /etc/aliases.db*

Those things may be binaries, but they're not programs. The rstart binary is
a program and those go into /usr/bin or equivalent, not in /etc. If the
reason for this program to be in /etc is that it needs basic configuration
to be done via recompiling, it's substandard for this time and age and needs
to be withdrawn. If not, it needs to be put into /usr/bin or equivalent.

Why don't you simply fix the bug, rather than continuing to argue about its
severity or priority? It shouldn't be more than a few interventions in the
build system, how hard can it be?

-- 
     2. That which causes joy or happiness.



Severity set to `normal'. Request was from Branden Robinson <branden@debian.org> to control@bugs.debian.org. Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, debian-project@lists.debian.org:
Bug#97671; Package project. Full text and rfc822 format available.

Acknowledgement sent to Branden Robinson <branden@debian.org>:
Extra info received and forwarded to list. Copy sent to debian-project@lists.debian.org. Full text and rfc822 format available.

Message #189 received at 97671@bugs.debian.org (full text, mbox):

From: Branden Robinson <branden@debian.org>
To: 97671@bugs.debian.org, ajt@debian.org, debian-x@lists.debian.org
Subject: Re: Bug#97671: marked as done (xutils: why is rstart.real a conffile?)
Date: Tue, 29 Jul 2003 11:31:17 -0500
[Message part 1 (text/plain, inline)]
On Fri, Jul 25, 2003 at 06:48:15AM -0500, Debian Bug Tracking System wrote:
> Branden Robinson, in a mail to control@bugs.debian.org, wrote:
> > merge 97671 143825
> > severity normal
> > tag 97671 + help upstream
> > thanks
> 
> As the tech ctte have resolved not to do anything about this bug,
> and two project leaders have refrained from touching it at all, you're
> evidently not going to get a more authoritative judgement on the severity
> of Bug#143825, than mine whether taken as either release manager or one
> of the BTS maintainers. If you choose not to accept this, and cannot
> get either the tech ctte or the DPL to actively support your position
> overruling my judgement, but try to downgrade the bug nevertheless,
> I'll add technical measures to stop that from happening. I'd appreciate
> it if you refrain from wasting my time or your own in such a manner.
> 
> Closing this report with this message.

I guess you missed the part where I said:

tag 97671 + help upstream

Because 1) it is an upstream problem (the X Window System, being very
old, has some pretty stale ideas about filesystem layout) and 2) I'd
appreciate help with this bug since I have more important things to do
like get 4.3.0 into experimental (and ultimately unstable).

So, volunteers are cordially invited to take a crack at the Imake
modifications that would be necessary to fix this.  In the Release
Manager's opinion, sarge should not ship with this awful, awful,
horrible bug (hence "release-critical").

You never know what back-channel favors might accrue if you do something
to make both me *and* the Release Manager happy.  :)

(TINC)

-- 
G. Branden Robinson                |    Optimists believe we live in the
Debian GNU/Linux                   |    best of all possible worlds.
branden@debian.org                 |    Pessimists are afraid the optimists
http://people.debian.org/~branden/ |    are right about that.
[Message part 2 (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, debian-project@lists.debian.org:
Bug#97671; Package project. Full text and rfc822 format available.

Acknowledgement sent to Andreas Tille <tillea@rki.de>:
Extra info received and forwarded to list. Copy sent to debian-project@lists.debian.org. Full text and rfc822 format available.

Message #194 received at 97671@bugs.debian.org (full text, mbox):

From: Andreas Tille <tillea@rki.de>
To: Anthony Towns <aj@azure.humbug.org.au>, <190592@bugs.debian.org>
Cc: control@bugs.debian.org, <169264@bugs.debian.org>, <155374@bugs.debian.org>, <169413@bugs.debian.org>, <196234@bugs.debian.org>, <189832@bugs.debian.org>, <188877@bugs.debian.org>, <170820@bugs.debian.org>, <97671@bugs.debian.org>, <198337@bugs.debian.org>, <143825@bugs.debian.org>, <debian-bugs-dist@lists.debian.org>, Andreas Tille <tille@debian.org>
Subject: Re: Bug#190592: pending meaning change
Date: Tue, 5 Aug 2003 08:38:28 +0200 (CEST)
On Thu, 24 Jul 2003, Anthony Towns wrote:

> The definition of the "pending" tag has been changed to:
>
> ]   pending
> ]          A solution to this bug has been found and an upload will be
> ]          made soon.
>
> The (release critical) bugs above have been tagged pending for over a
> month, so by the new definition the tag appears to not apply to the above
> bugs.
Thanks for reminding me.  It was intended in exactly this meaning but unfortunately
I did not managed before Debconf and my vacation.  I think I'll settle down with
this (not to hard because I'm also upstream author) problem ion this week.

Kind regards and see you on next Debconf :)

          Andreas.




Send a report that this bug log contains spam.


Debian bug tracking system administrator <owner@bugs.debian.org>. Last modified: Sat Apr 19 07:19:12 2014; Machine Name: beach.debian.org

Debian Bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.