Subject: Bug#4164: Ferret extended description has blank lines

From: Heikki Vatiainen <[email-masked]>
Date: Thu, 15 Aug 1996 15:25:36 +0300

Package: ferret
Version: 1.0-eval-1

Ferret extended description field has four empty lines in it.
The correct form is to have a single space followed by
a single full stop character

I noticed this when going through the Packages-master-i386 file.
The Packages master I checked is located in
ftp://ftp.debian.org/pub/debian/indices/ directory.

---

From: "Brian C. White" <[email-masked]>
Date: Thu, 15 Aug 1996 16:00:17 -0400

> a single full stop character

Oops!  Okay, it'll be fixed in the next release (soon, hopefully).

By the way, for such tiny things, it's usually considered better
to just notify the maintainer instead of adding the overhead of
a full bug report.  If the maintainer doesn't fix it, then a bug
report should be submitted so it gets tracked.

                                        Brian
                               ( [email-masked] )

-------------------------------------------------------------------------------
    In theory, theory and practice are the same.  In practice, they're not.

---

From: Lars Wirzenius <[email-masked]>
Date: Fri, 16 Aug 1996 03:22:59 +0300

"Brian C. White":
> a full bug report.  

I disagree. The bug list is not a shame pole! It's a trivial way for
users to reach maintainers -- there's only one address to remember.
The address in the package might be out of date.

This has been discussed before, of course.

-- 
Rural sizes win <[email-masked]> <http://www.iki.fi/liw/>
Please don't Cc: me when replying to my message on a mailing list.

---

From: Dale Scheetz <[email-masked]>
Date: Fri, 16 Aug 1996 09:53:08 -0400 (EDT)

On Fri, 16 Aug 1996, Lars Wirzenius wrote:

> I disagree. 

We seem to be divided fairly evenly on this issue.

> The bug list is not a shame pole!

Objections to reporting something as a bug are not founded on this
concept. No one feels personaly "put down" by a bug report. Those of us
who object to "trivial" bug reports are more concerned about the
distribution's public perception. The new user is apt to see a "security"
bug and a "blanks in description" bug as having equal weight. Large
numbers of outstanding bugs also leave new users feeling uncertain.

> It's a trivial way for

No, the trivial way to reach maintainers is to start with debian-user.
Case in point:
Recently a user reported smtp problems with pine. This problem turned out
to be a configuration issue, unrelated to any functional problems with the
pine software. By reporting the "bug" on debian-user first, a non-bug bug
report was avoided.

> The address in the package might be out of date.
And it might not be...

> This has been discussed before, of course.
And it seems we will continue to disagree. I see no harm in encouraging
users to talk to me first about problems with my packages, and I will
continue to do so. I see no reason for those who disagree with this
attitude to continue to point it out.

If we really need to grind on the differences in our personal philosophy
we should probably do it on debian-private (or maybe just private mail).

Luck,

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: Ian Jackson <[email-masked]>
Date: Sat, 24 Aug 96 18:26 BST

Dale Scheetz writes ("Re: Bug#4164: Ferret extended description has blank lines "):
...
> numbers of outstanding bugs also leave new users feeling uncertain.

The bug tracking system is for _our_ _internal_ use.  I couldn't care
less if the some idiotic users think that two hundred `missing
description' bug reports are vitally important.

We must not allow bugs to go unreported because they'd end up on the
bug list and so be publicly visible.  That's absurd.

...
> No, the trivial way to reach maintainers is to start with debian-user.

No, because debian-user is a high-traffic mailing list.

The best way to report a trivial problem in package foo is to mail
  To: [email-masked]
  Subject: ...

  Package: foo

> pine software. By reporting the "bug" on debian-user first, a non-bug bug

This is a different matter.  Encouraging people to discuss things that
might or might not be bugs is fine.

Discouraging people from reporting things that definitely are bugs is
not fine.

Ian.

---

From: Dale Scheetz <[email-masked]>
Date: Sat, 24 Aug 1996 22:01:28 -0400 (EDT)

> Discouraging people from reporting things that definitely are bugs is
I agree completely, but I will still contend that the appropriate step to
take before submitting a bug is to contact the maintainer. When that can't
be done, or the maintainer is resistant, or the maintainer agrees, then is
the right time to submit the bug report.

Later,

Dwarf

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

---

From: "Susan G. Kleinmann" <[email-masked]>
Date: Sun, 25 Aug 1996 06:12:26 -0400

I agree with Brian that micro-bugs should probably be reported to the 
maintainer, just because it takes more work to contact the reporter and 
close the bug than to fix it.  However, in this case the reporter has to
keep his _own_ bug tracking system, if he wants to make sure that the
maintainer actually fixed the bug.  This may or may not be a big deal,
depending on the responsiveness (read, speed and verbal skills) of
the maintainer.  Also, the reporter then takes the moral responsibility
of (a) having wasted a third person's time who may chance across the bug
(it takes time to identify a bug), and (b) having wasted someone else's 
time reporting a bug.

I agree with Lars that the bug tracking system is not a shame pole.

I agree with Dale that trivial (or incorrect) bugs give a bad and unbalanced
impression of the distribution.  

I agree with Ian that we can't afford to let bugs go unreported because
they might be publicly visible (that's actually a lot of help!).
And I also agree with Ian that debian-user is a bad, bad place to report
bugs because of its traffic.

Having to do with psychology, it seems to me there is another advantage
of using the bug tracking system, and that has to do with the 
less-than-perfect side of humans:  all of Debian's developers are
busy folks who need to save time.  If someone mails a developer a message 
regarding a trivial (or maybe not so trivial) bug fix, and he deems it 
unimportant, he might be tempted to tell the reporter to forget it.
This leaves these possibilities:
A. the reporter agrees it was silly and defers to the maintainer, and no
   one else is ever bothered by this.  
B. the reporter agrees it was silly and defers to the maintainer, and someone
   else does find the same bug, thereby wasting his time and _really_
   giving the Debian distribution a bad name because of real bugs.
C. the reporter doesn't agree with the maintainer, takes the bug to the
   bug tracking system, thereby deliberately turning up the heat on the
   maintainer, and potentially causing a mini-war.

So, except where the ratio of 
      triviality-of-bug / responsiveness-of-maintainer 
is near 0, or (better) where the reporter realizes the maintainer
has his own motivations for fixing the bug right away, I agree with Ian that 
the right thing to do is to log the bug.  I believe the bug tracking system 
may be the single most important aspect of the Debian system.

Even when a reporter isn't sure that an event is a bug, he should report
it, since this eventually leads to FAQ's which can then be aired and 
resolved :-).

(I now feel guilty for not having always used the BTS myself in the past.)

Best regards,
Susan Kleinmann

---

From: Steve Greenland <[email-masked]>
Date: Sun, 25 Aug 1996 13:34:49 -0500 (CDT)

> may be the single most important aspect of the Debian system.

As a maintainer whose responsiveness is probably less than ideal[1],
I must say I rather like having the bug tracking system, and I
would just as soon have people report stuff there. It saves me from
having to keep a separate list of "private" bugs, and while it may
not be a "pole of shame", if the list gets long, it tends to inspire
some effort to reduce it to something a little less personally
embarrasing :-).

One enhancement I would like to see is the ability to access the
buglist by package. No, not sorted by package, but a single page
of the outstanding bugs for a given package, so that I can have a
link to "http://www.debian.org/bugs/bypackage/nvi.html" or some
such. Or maybe a form, so that somebody can enter a package name
and get the appropriate list. I think this would make it much more
likely that people would look to see if a bug has been reported
before submitting a new one, and would make it easier for maintainers.
(I have no idea how hard this would be; I'm just throwing the idea
out there...)

Steve

[1] I enjoy contributing in a small way to a community (both Debian
and the free software community in general) that has provided a
lot of benefit for me over the years, but the reality is that Debian
is a spare time thing for me, and I haven't had much spare time
this year.

-- 
The Mole - I think, therefore I scream 

				"Calling all units!  Leading monster
				 stampede through the bottomlands to lower
				 forty!... Set up ambush on flanks!... Also,
				 do not shoot me!... Repeat!... Do not shoot
				 me!!!"
[FLAMING CARROT vs the Giant Japanese Monsters!]

---

From: Mark Eichin <[email-masked]>
Date: 29 Aug 1996 22:15:16 -0400

> maintainer, just because it takes more work to contact the reporter and 

As you point out later, this means the bug doesn't get tracked, and
thus quite possibly doesn't get fixed.  (I've had some time to clean
up my packages recently, including the ones I promised to maintain for
people but never actually posted... and the by-package web list serves
as a very good todo list...)

As for trivial bugs: if they're trivial, I can just as trivially close
them :-) Lots of reports of trivial bugs add up to a possibility of a
real problem elsewhere, as well...