Subject: Sociology and the bug tracking system

From: Ian Jackson <[email-masked]>
Date: Tue, 16 Jul 96 01:35 BST

I've noticed that a couple of people have recently become offended
when bugs were reported against some of their packages.  I won't go
into the details of those cases, which have been sorted out by now to
everyone's pacification I hope, but there is something I really want
to say here:

Reporting a bug against a package is _not_ per se a comment on the
character, competence or responsiveness of the maintainer.

It is very often just a way to make sure that a `work item' doesn't
get forgotten, or to make sure that it gets routed to the right
person.

The bug system was concieved to address the problems with bug reports
and similar messages being posted to a mailing list, or sent to a
developer directly.

Even with the best will in the world it is impossible to keep track of
every work item and make sure that it is dealt with, without some kind
of (automatic, because we don't have much available effort)
administrative tracking scheme.  Maintainers change their email
addresses and even go away completely; mailing list traffic is easily
overlooked, and longstanding problems that are hard to fix disappear
into the mounds of email that many of us get.

Putting the bugs in a central database also allows users to see where
problems lie and often what work-arounds are available and helps other
developers to see where a package maintainer might appreciate some
assistance.

You should think of the bug system as a `to do' list - if someone puts
an entry in it for one of your packages they are just doing their
part, passing whatever buck it is on to you to make sure it doesn't
get lost as it might well do if left to the very fallible memories of
us humans.

It does *not* mean that they're in some way unhappy with your
performance as a maintainer.  As we're all aware, every program can
have bugs.  dpkg has 33 outstanding bugs, for example !

New bugs can arise because, for example, packing standards or binary
formats change, other packages are changed.  The fact that these are
not the `fault' of the maintainer doesn't mean that they don't belong
in the bug system.

The bug system is not a register of how delinquent each maintainer is;
please don't respond to bug reports as if it was.

Thanks,
Ian.

---

From: "James A. Robinson" <[email-masked]>
Date: Tue, 16 Jul 1996 16:46:43 -0400

This is a very long message, but it express some things I feel are
important.  If you're not interested in a lot of "How we all get
along?" stuff, feel free to press "D" now.

> [with bug reports...] but there is something I really want to say here:
> 
> [..]
> [...]

Ok, I think it is good this is out in the open for discussion.  I
think that everyone realizes that the bug report is just a to-do list,
and that it is not a bad reflection on them.

I think some friction may arise between people when the maintainer and
bug-reported disagree about whether or no there really is a problem.
This can be for a few reasons.  Either party may not understand the
Guidelines, or similarly the Guidelines may have changed without one
of them realizing it.  But sometimes the bug report is just an
expression of one person's "view" of "how things should be."  And I
think this part causes real problems.

The first two can easily be dealt with by explaining what the
up-to-date Guideline says on the subject, and explaining it in detail
if it is at all obscure (which, of course, is an indication that the
section should be rewritten or amplified).  However, the last one
causes problems -- and may always cause problems.  If the maintainer
doesn't believe it is a bug, they will usually explain why and either
wait for a response, or close the bug (if they are really sure it
isn't a bug).

Now, the bug-reporter needs to answer the e-mail within a reasonable
amount of time, or the maintainer will probably figure that they are
in agreement and close the bug.  But if the bug-reporter doesn't
agree, I think the weight is on him or her to convince the maintainer
that the package was indeed "made the wrong way."  This may cause
tempers to flare, because different people have different ways of
trying to convince others.  Some may detail the reasons in a fairly
logical fashion, some just say "it is just wrong, so please change
it."

Now, the first is obviously the best, probably the only, way -- but
one needs to be careful and not stick too much "I feel" into there. In
other words, it should not come off as the second method in a numbered
list format.  The second method obviously will cause problems.

Now, sometimes the issue gets taken to the whole list. I think this
all right on issues where both parties feel more input is needed, or
on issues where the two simply can't agree.  But if one party sends a
list-message out before either of these stages, I think the other
party is likely to be fairly offended at not being asked in advance.
This is because it _does_ make the maintainer look bad.  It makes it
seem like the maintainer is just being stubborn and not listening to
reason.  And _that_ can cause people to get fairly angry.

A lot of anger in the messages I see between maintainers and
bug-reporters looks like it simply came about from not taking the
other person's feelings into consideration when writing a certain
sentence or performing a certain action.  They may write in a
overbearing or "threatening" manner.  Regardless of whether or not we
are all supposed to be perfect people, feelings _do_ matter, and
_will_ cloud the issues.  I believe this is true no matter _who_ you
are.  So, both sides taking a little time and thinking about what they
are writing will probably resolve a lot of these kinds of issues.

You can see where I got a lot of this from. :) With the AucTeX report,
I didn't think the bug was a bug.  But you managed to partly convince
me. However, instead of responding to my "I partly agree" message, I
saw you post a message to the mailing list!  I was indeed a little
annoyed at not getting a response and a "Do you think people on the
list should discuss this?" message.  I'm always in favor of list
discussion, but I would prefer to hear a heads-up about it when it
concerns me, especially since I hadn't received a reply to my latest
message.  I responded in poor fashion, and I do apologize for it.
Since I hadn't seen a response (logical or otherwise) against my
reasoning on looking in /tmp, and then saw it taken to the list, it
got me mad.  I should have calmed down a bit before I wrote it, but
unfortunately, like I wrote above, people will let emotions cloud
their reasoning.

Jim

---

From: Manoj Srivastava <[email-masked]>
Date: 17 Jul 1996 03:02:41 -0400

Hi,

	Let me first state that I agree with Ian that the bug
 reporting system is in principle a good thing; however, I have sat
 and simmered at the *tone* of  some of the reports that have flashed
 by in the last few days. 

	I like bug reports, I really do, since I'd hate to have a
 buggy piece of work  exist with my name on it; but could we please be
 less abrasive/patronizing when reporting the bugs?

	manoj

>>"Ian" == Ian Jackson <[email-masked]> writes:

Ian> I've noticed that a couple of people have recently become
Ian> offended when bugs were reported against some of their packages.
Ian> I won't go into the details of those cases, which have been
Ian> sorted out by now to everyone's pacification I hope, but there is
Ian> something I really want to say here:

-- 
 Fiery energy lanced out, but the beams struck an intangible wall
 between the Gubru and the rapidly turning Earth ship.  "Water!" it
 shrieked as it read the spectral report.  "A barrier of water vapor!
 A civilized race could not have found such a trick in the Library! A
 civilized race could not have stooped so low!  A civilized race would
 not have..."  It screamed as the Gubru ship hit a cloud of drifting
 snowflakes.  _Startide Rising_, by David Brin
Manoj Srivastava               Systems Research Programmer, Project Pilgrim,
Phone: (413) 545-3918                A143B Lederle Graduate Research Center,
Fax:   (413) 545-1249         University of Massachusetts, Amherst, MA 01003
<[email-masked]> <URL:http://www.pilgrim.umass.edu/%7Esrivasta/>

---

From: [email-masked] (joost witteveen)
Date: Wed, 17 Jul 1996 17:32:15 +0200 (MET DST)

> bug-reported disagree about whether or no there really is a problem.

Also here I couldn't agree more. Very often I see "bug reports" 
(usually against other people's packages, sometimes against mine),
reporting things that are arguably not done TheBestWay at the
moment in a package, but are also clearly not RealBugs (TM).

I know that using the bug-reporting system in such cases doesn't mean
anyone is commenting on the maintainer, but by reporting it as a
bug the maintainer _will_ have to do (some) more work.

In my view it would be better that, if someone dislikes the way a package
handles something (as opposed to finding a RealBug), s/he eighter
mails the maintainer privately, or reports a set of patches to
the bug-tracking system. I mean, if someone really wants something
to be improved, then I think he should spend the time improving it,
not trying to force the maintainer to do the work.

Oh, and before I offend anyone: I don't mean your bug-reports, they're OK!

-- 
joost witteveen
            [email-masked]
          [email-masked]
--
Use Debian/GNU Linux!

---

From: Juergen Menden <[email-masked]>
Date: Thu, 18 Jul 1996 12:11:49 +0200 (MET DST)

> > bug-reported disagree about whether or no there really is a problem.

i don't think this is necesarily a problem. see below.

> [...] reporting things that are arguably not done TheBestWay at the

what's wrong with this? the bug system is a very good tool to 
keep a todo-list. nobody should be offended if such things

> bug the maintainer _will_ have to do (some) more work.

not necessarily. you are the maintainer of the package, so you
are the boss. if you think some suggestions of this type are to 
timeconsuming for you to do, forward it to the upstream maintainer,
if you think (s)he might want to do it.

you just as well can consider this behaviour not a bug, but a feature
and simply close the report. the original reporter can still ask
Bruce to override you, but i don't think Bruce is likely
to do this without need. :-)

> I mean, if someone really wants something

you shouldn't feel forced to do something just because someone
sent it to submit@bugs instead of your adress. just say "no", and
close the report. no problems with that. be strong. :-))

> Oh, and before I offend anyone: I don't mean your bug-reports, they're OK!

:-)

jjm

-- 
Juergen Menden                   | Disclaimer: The opinions expressed by me, 
tel:    +49 (89) 289 - 22387     +-----------+ are (usually) not the opinions 
e-mail: [email-masked]     | of anyone else on this planet.

Hi! I'm a .signature virus!  Add me to your .signature and join in the fun!

---

From: Dale Scheetz <[email-masked]>
Date: Thu, 18 Jul 1996 10:48:57 -0400 (EDT)

Listening to this discussion has been real educational for me. I have come
to a different point of view about the "bug tracking system" than I have
had in the past. From what Ian and others have said, this is a "to do
list" more than an "it's broken" indicator.
My personal problems, have been with the recent use of the bug list by the
m68k developers to blanket report changes for debian.rules that have not
yet made it to the source tree. My major problem stemed from the "glut" of
almost identical bugs messages that flood the list from time to time. Ian
has pointed out the "bugs-quiet" will keep this traffic off the lists. I
strongly suggest that maintainance clean up issues like this be kept off
the list via this method. My other concern stemmed from the bad public
image that results from large quantities of bug reports hitting the system
and the public eye. For the most part using bugs-quite resolves this issue
also.
I have come to a realization that goes way beyond these two trivial
issues. I have had some real problems with the way we do development
design in this group. We talk about the issue from all sides. Sometimes
taking months to reach a conclusion. Bruce, Ian and a few others then
confab over the issues, come to a conclusion, and deliver a terse
statement about the "new" conditions. I have no problem with the way the
discussions run (for the most part, barring fist fights). The synergy
created by the differing views, almost always creates something larger
than any of us could produce on our own. The problem I have, is with how
the decission gets reported. A terse, sometimes confusing, decission
report, via e-mail on the lists, is often either missed or forgotten in
the rush to get the next version of the package out. 
So, here is my suggestion: If Ian is correct (and I have every reason to
believe he is) and the bug reporting system is to be treated as a
to-do-list, then, whenever a design change is made to the package building
proceedure, a bug should be reported out on every package in the system
(maintainer only messages). That bug report should be a complete
description of the changes that need to be made to conform the the new
guidelines (including changes to the guideline docs). I would find this to
be a great help in deciding how up to date my packages are WRT the current
state of the distribution. I think it would also be a better way to
historicaly track the development of the distribution. Having this
historical record would allow clearer information to surface faster in a
discussion/argument of "how we used to do it".

Thoughts?

Dwarf

------------                                          --------------

aka   Dale Scheetz                   Phone:   1 (904) 877-0257
      Flexible Software              Fax:     NONE 
      Black Creek Critters           e-mail:  [email-masked]

------------ If you don't see what you want, just ask --------------

---

From: Michael Alan Dorman <[email-masked]>
Date: Thu, 18 Jul 1996 15:30:44 -0400

>discussion/argument of "how we used to do it".

An additional benefit of this implementing this in the fashion you
suggest is that it will give developers taking over orphaned packages
a good starting point for bringing things in line with the current
standards.

Mike.
--
"Don't let me make you unhappy by failing to be contrary enough...."

---

From: Chris Fearnley <[email-masked]>
Date: Thu, 18 Jul 1996 23:13:40 -0400 (EDT)

'Dale Scheetz wrote:'
>discussion/argument of "how we used to do it".

I like this suggestion.  The person making to bug report would be able
to include a summary of discussions and etc.  If it happens a lot, it
would be nice to have the bug system /not/ send 500 mail messages for
each such bug!

-- 
Christopher J. Fearnley            |    Linux/Internet Consulting
[email-masked], [email-masked]       |    UNIX SIG Leader at PACS
http://www.netaxs.com/~cjf         |    (Philadelphia Area Computer Society)
ftp://ftp.netaxs.com/people/cjf    |    Design Science Revolutionary
"Dare to be Naive" -- Bucky Fuller |    Explorer in Universe

---

From: Juergen Menden <[email-masked]>
Date: Fri, 19 Jul 1996 17:25:55 +0200 (MET DST)

On Thu, 18 Jul 1996, Dale Scheetz wrote:
> 
> whenever a design change is made to the package building
> guidelines

the last weeks i could see some messages from Ian on this list, that 
a script is going to send a bunch of bug reports to maintonly@bugs, for 
the packages XXX are still YYY.

i think this is pretty near to what you suggest. :-)

jjm

---

From: Ian Jackson <[email-masked]>
Date: Fri, 19 Jul 96 22:30 BST

Dale Scheetz writes ("Re: Sociology and the bug tracking system"):
> [...] whenever a design change is made to the package building
> (maintainer only messages). [...]

I don't think this is the best way to manage this.  This will stretch
our procedures rather badly.

How about the following, as an alternative means of doing the same
thing:

1. When we define the new source package format we also ship a `known'
version of the packaging guidelines, with a version number.

2. Make sure that all updates to the guidelines from then on are
recorded in a changelog saying what package maintainers need to
change, and cause the version number to be incremented.

3. Include a `current with standards version' field in the source
package control file.

4. Report bugs against packages that are more than a certain amount
out of date (eg, older major number more than 1 month after change or
older minor number more than 6 months, depending on the change).

This will mean that most packages will not need bugs reported, and
will reduce the amount of chasing around after the bug system that
needs to be done.

Ian.