[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Re[gnu.misc.discuss,gnu.emacs.gnus] Free software: Packagers vs Developers

>> "Per" == Per Abrahamsen <abraham@dina.kvl.dk> writes:

I can't really get your critisism of the Debian BTS.

Per> Adam Di Carlo <adam@onshore.com> writes:

>> This is nonsense.  Assuming you are forwarded the original users
>> report, that is functionally identical to receiving it yourself in the
>> first place.

Per> Then I would have to find a way to explain that user what was going
Per> on, when I was hardly knowing it myself.

Maybe my english is too bad, but I don't understand the meaning of
this sentence.

>> Go a step further -- "train" the Debian maintainer to get bug reports
>> to you in the right format, with the right info.  

Per> Here we go again, Debian creating extra work for the developers.

Would you like to directly receive any bugreport sent by the user,
just as if the BTS would not exist? This is no problem, just a
forwarding rule.

But then, you should be prepared to receive many reports you can't
deal with, because they are integration aka packaging bugs. Some
popular package had such a bug lately, and it produced no less than 20
reports in one day. 

Take it for granted, that the authors of my packages (and the members
of the software developer-mailinglist if there is one) would have been
pissed of on me, if they got these reports because I didn't filter them.

To use your words, this would be "Debian creating extra work for the

I try to make sure, the bug is not caused by me before I pass it to the 

After this, I mark a bug forwarded to the author (the submitter
receives an automatic mail "The bugreport was forwarded by the
maintainer to the author of <packagename>, <author name> <author
email>". I tell the author about this bug, and point it to the BTS
record, where any conversation I had with the submitter about the bug
is recorded. This page contains automatically submitted system info
and info I requested from the submitter, as well as things I have
requested the submitter to do and his answers etc.

So far, the authors were delighted to find these information, and none 
of them sees the BTS as a hinderance. They rather see it as a help as
they already find most information they need available.

The author is asked to Cc the BTS so any further conversation is
recorded as well.

With the BTS, users (this includes me as well) can see if a bug is
known, and what the maintainer, submitter and author have done so
far. I often can find a workaround there, or I can submit further
information I found about this bug. 

This makes bughunting more efficient. None of the programs I maintain
has such an infrastructure. Half of them don't even have a
mailinglist. The feature I like best about the BTS is that you can see 
all open (and closed within the last 30 days) bugs, so you can decide
if it is something known, and if there are work-arounds available.

Someone suggested a questionaire to be sent to the authors of packaged
software, which can be resent anonymously. 

I do believe Debian will finish this quite well. 

There may be situations where developers acted "overly enthuisiastic"
- this happed to me as well, and I resolved this with the author -,
but I believe Debian doesn't do something inheritly evil or bad. Au
contraire, I believe the Debian community works quite well and heads
the right way.

This is why I chose to be part of it.

As a user, I find Debian to be the best constructed distribution I
worked with.

Many of us not only package existing software, but we are also
authors. So we know both sides of bringing software to people.


Reply to: