Getting good bug reports
 

schrieb Russ Allbery on 2011-05-24 18:55:
> Patrick Strasser <patrick.strasser@tugraz.at> writes:

First, I want to emphasize that I do not at all advocate for a web
reporting form. IMO most contributors to this thread do so.

I regard the overall process of reporting bugs in Debian very sensible,
no need to change in general.

I see three issues mixed up here:
1) Web bug reporting facility, ala Ubuntu Launchpad
2) Helping reports writing high quality bug reports
3) Improving reportbug to mitigate bug report drafts that end up in /tmp

> Debian bugs tend to be
> of considerably higher quality than I see in other projects (like Ubuntu,
> for example, where the bug quality is remarkably worse). And, like Ian, I
> think some of that may have to do with Debian's bug reporting system,

That's about point 1). Again, I do not think that a web-based bug submit
front end would help to improve the situation.

>> If it is about quality it needs action to educate users or help them
>> writing better bug reports.
>
> Which also no one has time to do. But it turns out that not putting up a
> public web form to submit bugs is a fairly good proxy for user education.
> It doesn't *fix* the problem, but it does weed out a lot of users who
> don't know how to file good bug reports (and some users who do, which is
> indeed a drawback).

Point 2). I do not think about going out and teaching people to report
bugs. I rather think of some helping questions and information for bug
reporting newbies. I usually recommend people to read Eric S. Raymond's
"How To Ask Questions The Smart Way". reportbug tries hard to collect
good information, I think it could improve in helping reports writing
good bug reports.

>> If it is hard to report bugs you will only get the reports of advanced
>> users and only solve problems they can not get around
>
> This isn't my experience. Debian users seem to be fairly good about
> reporting simple problems readily.

Point 3). Still it's too hard for a real novice which would like to help
to get a bug report not at all out. The starting suggestion for this
thread was to add an HTTP based transport path to get around the MTA
thing. In the mid 90ies I was starting with a dial up connection, which
was expensive, and I was glad that I could queue my outgoing mail and
have them shipped together. I needed a working MTA in my box. Nowadays
for me there's no point in having a non-local MTA, I have DSL and alway
access to my ISPs mail transport system, which means I have direct
access to BTS.

I just second the proposal to have a backup to the mail transport in
form of a HTTP or some other direct connection transport. Nothing more.
Mail is fine, having a backup is even better.

Regards

Patrick

[1] http://www.catb.org/~esr/faqs/smart-questions.html
--
Engineers motto: cheap, good, fast: choose any two
Patrick Strasser <patrick dot strasser at student dot tugraz dot at>
Student of Telemati_cs_, Techn. University Graz, Austria


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: irh0mf$tq4$2@dough.gmane.org">http://lists.debian.org/irh0mf$tq4$2@dough.gmane.org

Getting good bug reports
 

On 25 May 2011 05:25, Patrick Strasser <patrick.strasser@tugraz.at> wrote:

Point 3). Still it's too hard for a real novice which would like to help

to get a bug report not at all out. The starting suggestion for this

thread was to add an HTTP based transport path to get around the MTA

thing. In the mid 90ies I was starting with a dial up connection, which

was expensive, and I was glad that I could queue my outgoing mail and

have them shipped together. I needed a working MTA in my box. Nowadays

for me there's no point in having a non-local MTA, I have DSL and alway

access to my ISPs mail transport system, which means I have direct

access to BTS.



I just second the proposal to have a backup to the mail transport in

form of a HTTP or some other direct connection transport. Nothing more.

Mail is fine, having a backup is even better.


Personally I have many Debian desktops and servers under my control. Some of them on private networks without public FQDN. Some of them laptops, which never plugged into the same network, and as such need a different SMTP setup everytime. Some don't even have Internet access.

It is impossible for me to recall which ones have working MTAs, working reportbug SMTP configurations, etc. reportbug needs to be run from the system that encountered the problem or it will generate bad debugging information. When I encounter a bug somewhere, if I get side tracked trying to test my MTA setup on a system that never sends emails under normal conditions, I will run out of time to fill a quality bug report. Or maybe the bug is with the MTA I am trying to configure.

It has happened that I have submitted quality bug reports, only to find they go down a black hole, never to be seen again. The fact the BTS takes a while to respond doesn't help. Sure, maybe this was due to an invalid From address or something, would rather focus on submitting a good quality bug report rather then debug my MTA setup for a computer that normally never sends email however.

As a result, I often end up sending bug reports by hand, using my email client.
Also a good quality web interface gives immediate feedback that (a) the command has been processed, (b) validates the command immediately and (c) outputs the results of the command. None of this resubmitting email after email after email (with considerable delay between each email waiting response) to control@bugs.debian.org trying to get a simple reassign command to do the right thing.

Sure, maybe if you are a heavy user of the BTS, these issues won't apply; as a light/occasional user however I find I am spending more time trying to use the BTS then being able to file/manipulate bugs in the BTS.
--
Brian May <brian@microcomaustralia.com.au>

Getting good bug reports
 

Brian May writes ("Re: Getting good bug reports"):
> [ explanation of how reportbug is broken right now ]

We could solve this if we can avoid the slippery slope problem.

Or to put it another way, I would have no objection to an http
submission interface to the BTS, provided that everyone understands
and agrees that:

* This interface is to be used only by reportbug

* If any other bug reporting tool is written it needs separate
consensus approval here (consensus as determined by owner@bugs)

* Specifically, no-one is to write any web forms or GUIs which allow
users to file bug reports in the Debian BTS.

Ie, we're purely fixing the deficiencies of reportbug.


On a technical level, I would suggest that the submission interface
should contain a submission agent and version string which reportbug
should set to its own package name and version. This string should
not be checked by default by the submission server but there should be
provision for an administratively applied blacklist.

Then if someone (Nabble?) does violate our expectations, we'll be able
to block them (by releasing a new version of reportbug, if the
miscreants hijack our version string).

Obviously the return from the submission interface wouldn't be an HTML
page. It would be a success indication, or a plain text error
message.

Ian.


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 19932.60160.611083.62232@chiark.greenend.org.uk">h ttp://lists.debian.org/19932.60160.611083.62232@chiark.greenend.org.uk

Getting good bug reports
 

I wrote:
> Brian May writes ("Re: Getting good bug reports"):
> > [ explanation of how reportbug is broken right now ]
>
> We could solve this if we can avoid the slippery slope problem.
>
> Or to put it another way, I would have no objection to an http
> submission interface to the BTS, provided that everyone understands
> and agrees that:
>
> * This interface is to be used only by reportbug
>
> * If any other bug reporting tool is written it needs separate
> consensus approval here (consensus as determined by owner@bugs)
>
> * Specifically, no-one is to write any web forms or GUIs which allow
> users to file bug reports in the Debian BTS.

I would also suggest that the protocol documentation should be in the
reportbug package, not on the bugs.debian.org website. And it should
include the restrictions I describe above (or some other wording that
owner@bugs approves of).

Ian.


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 19932.60441.943176.515526@chiark.greenend.org.uk"> http://lists.debian.org/19932.60441.943176.515526@chiark.greenend.org.uk

Getting good bug reports
 

Ian Jackson <ijackson@chiark.greenend.org.uk> writes:

> Brian May writes ("Re: Getting good bug reports"):
>> [ explanation of how reportbug is broken right now ]
>
> We could solve this if we can avoid the slippery slope problem.
>
> Or to put it another way, I would have no objection to an http
> submission interface to the BTS, provided that everyone understands
> and agrees that:
>
> * This interface is to be used only by reportbug
>
> * If any other bug reporting tool is written it needs separate
> consensus approval here (consensus as determined by owner@bugs)
>
> * Specifically, no-one is to write any web forms or GUIs which allow
> users to file bug reports in the Debian BTS.
>
> Ie, we're purely fixing the deficiencies of reportbug.
>
>
> On a technical level, I would suggest that the submission interface
> should contain a submission agent and version string which reportbug
> should set to its own package name and version. This string should
> not be checked by default by the submission server but there should be
> provision for an administratively applied blacklist.
>
> Then if someone (Nabble?) does violate our expectations, we'll be able
> to block them (by releasing a new version of reportbug, if the
> miscreants hijack our version string).
>
> Obviously the return from the submission interface wouldn't be an HTML
> page. It would be a success indication, or a plain text error
> message.
>
> Ian.

So everyone is allowed to write a frontend to report bugs via smtp. But
only reportbug is allowed to use http? That seems a bit stupid. Any tool
generating valid mails to bugs.debian.org should also be allowed to send
them via http. Specifically I would like the "bts" command to work over
http too if reportbug does.

Why not just make it an smtp-over-http tunnel with the clear limit of
only accepting mail to bug.debian.org. I mean the problem is ISPs that
don't allow an smtp connect to bugs.d.o so lets circumvent that
limitation by using http underneath.

MfG
Goswin


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87sjs23ovj.fsf@frosties.localnet">http://lists.debian.org/87sjs23ovj.fsf@frosties.localnet

Getting good bug reports
 

Brian May <brian@microcomaustralia.com.au> writes:

> Some don't even have Internet access.

So, how do you propose reportbug should handle those? Send a fax?

Seriously, what problem do you have that isn't solved by
"reportbug --offline --output=foo"
?



Bjørn


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 8762oyx3t3.fsf@nemi.mork.no">http://lists.debian.org/8762oyx3t3.fsf@nemi.mork.no

Getting good bug reports
 

Goswin von Brederlow writes ("Re: Getting good bug reports"):
> So everyone is allowed to write a frontend to report bugs via smtp. But
> only reportbug is allowed to use http? That seems a bit stupid.

No-one _wants_ to write a frontend to report bugs via smtp, and doing
so as a simple serverless web application is probably nearly
impossible. So that is a moot problem.

The reason why there is a problem with an http submission interface is
that suddenly every idiot will think "oh I must write a cool ui for
this".

> Any tool generating valid mails to bugs.debian.org should also be
> allowed to send them via http. Specifically I would like the "bts"
> command to work over http too if reportbug does.

The "bts" command is less relevant because it is run on your
workstation rather than some kind of installation target.

> Why not just make it an smtp-over-http tunnel with the clear limit of
> only accepting mail to bug.debian.org. I mean the problem is ISPs that
> don't allow an smtp connect to bugs.d.o so lets circumvent that
> limitation by using http underneath.

The opposition to http submission is because of the slippery slope
argument I set out earlier. I think it's a more than hypothetical
problem - see how many people in this thread have advocated precisely
the things that sceptics (like me) don't want.

Ian.


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 19933.10641.671206.437375@chiark.greenend.org.uk"> http://lists.debian.org/19933.10641.671206.437375@chiark.greenend.org.uk

Getting good bug reports
 

Ian Jackson <ijackson@chiark.greenend.org.uk> writes:

> Goswin von Brederlow writes ("Re: Getting good bug reports"):
>> So everyone is allowed to write a frontend to report bugs via smtp. But
>> only reportbug is allowed to use http? That seems a bit stupid.
>
> No-one _wants_ to write a frontend to report bugs via smtp, and doing
> so as a simple serverless web application is probably nearly
> impossible. So that is a moot problem.
>
> The reason why there is a problem with an http submission interface is
> that suddenly every idiot will think "oh I must write a cool ui for
> this".

But with the tunneling suggested below the cool UI would have to talk
smtp as well as http to setup the connection. So actualy doing this via
http would be even harder than with plain smtp. So your argument doesn't
hold.

Note: I'm not proposing bugs.d.o (or anyone else) gets an http
submission interface. Just an interface to talk to the smtpd via http.

>> Any tool generating valid mails to bugs.debian.org should also be
>> allowed to send them via http. Specifically I would like the "bts"
>> command to work over http too if reportbug does.
>
> The "bts" command is less relevant because it is run on your
> workstation rather than some kind of installation target.

If my workstation is behing one of those stupid ISPs that don't allow
smtp ...

>> Why not just make it an smtp-over-http tunnel with the clear limit of
>> only accepting mail to bug.debian.org. I mean the problem is ISPs that
>> don't allow an smtp connect to bugs.d.o so lets circumvent that
>> limitation by using http underneath.
>
> The opposition to http submission is because of the slippery slope
> argument I set out earlier. I think it's a more than hypothetical
> problem - see how many people in this thread have advocated precisely
> the things that sceptics (like me) don't want.
>
> Ian.

And the tunneling would keep your barrier intact.

MfG
Goswin


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87vcwyun0q.fsf@frosties.localnet">http://lists.debian.org/87vcwyun0q.fsf@frosties.localnet

Getting good bug reports
 

Goswin von Brederlow writes ("Re: Getting good bug reports"):
> Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
> > The reason why there is a problem with an http submission interface is
> > that suddenly every idiot will think "oh I must write a cool ui for
> > this".
>
> But with the tunneling suggested below the cool UI would have to talk
> smtp as well as http to setup the connection. So actualy doing this via
> http would be even harder than with plain smtp. So your argument doesn't
> hold.

Oh I see. I'm not sure that implementing a complicated layered thing
like that. How would you do sessions, anyway, or would you present
the whole SMTP session in a single transaction?

I don't think we should be implementing a perverse protocol out of
fear of a sociopolitical problem unless we don't have another way of
addressing the sociopolitical problem.

> Note: I'm not proposing bugs.d.o (or anyone else) gets an http
> submission interface. Just an interface to talk to the smtpd via http.

It should have the reportbug version string in the protocol, as I
described earlier.

> > The "bts" command is less relevant because it is run on your
> > workstation rather than some kind of installation target.
>
> If my workstation is behing one of those stupid ISPs that don't allow
> smtp ...

My point is that you have to do a lot of setup to make your
workstation work like you want it to anyway. Having to provide "bts"
(and indeed perhaps other commands) with a way to send email is just
one of those.

It's much less of a problem than for reportbug, which you often want
to run on some kind of half-broken test setup.

> And the tunneling would keep your barrier intact.

I think it's ugly but that's not really an objection. If the BTS
admins are happy with it.

I still think we need the understanding that this will be used only
by programs which gain consensus here. We can probably get that
consensus for bts, provided bts doesn't grow a way to submit bugs.

Ian.


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 19934.11176.186232.911399@chiark.greenend.org.uk"> http://lists.debian.org/19934.11176.186232.911399@chiark.greenend.org.uk

Getting good bug reports
 

There are plenty of cgi-bin scripts that send email via a web interface. I'm
sure that it wouldn't be difficult to install one of them on a web server for
the purpose of forwarding Debian bug reports. So really anyone who is good at
running web servers can setup a HTTP submission method if they wish.

Would someone who wants to write a HTTP client bug reporting tool really be
prevented because they have to setup their own server too?

--
My Main Blog http://etbe.coker.com.au/
My Documents Blog http://doc.coker.com.au/


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 201105262108.24824.russell@coker.com.au">http://lists.debian.org/201105262108.24824.russell@coker.com.au