Discussion on implementing a web based reportbug interface.
This is the relevant discussion from IRC, reproduced with permission:
1 <helen> we need a *webpage*, if we want to make it easy
2 <madduck> should be trivial to write one.
3 <madduck> the problem is that it encourages users to submit inferior bug reports
4 <madduck> for there is no easy way to make bug reports include the stuff about dependencies etc. that reportbug adds
5 <madduck> automatically.
6 <helen> madduck: yes, but using reportbug is not easy for everyone
7 <madduck> helen: so that should be worked on.
8 <helen> madduck: for starters, not everyone will have their mail set up so reportbug can email out
9 <helen> I don't
10 <helen> but I know how to use reportbug -o
11 <helen> but you can't assume that people will actually read and understand the manpage
12 <madduck> helen: fair point. can't you use thunderbird for reportbug though?
13 <madduck> i think mail setup in debian is in dire need for improvement.
14 <helen> madduck: my strategy is to use reportbug to generate the bug report, and then paste the resulting output into thunderbird and email it.
15 <madduck> helen: uh oh.
16 <madduck> helen: it should be trivial to make reportbug spawn a thunderbird compose window.
17 <helen> if there is a thunderbird plugin for reportbug I don't know about it
18 <madduck> it's just a command...
19 <helen> that would be very good
20 <liw> helen, want to whip up a design for a bug reporting web form? i.e., what info it should have? (we can then discuss possibilities of who should actually implement the cgi :)
21 <madduck> please: figure out the command to use to spawn a compose window where i can specify To, Bcc, Subject, and body. Ideally: additional headers.
22 <madduck> I'll check out reportbug...
23 <madduck> /usr/share/reportbug/reportbug_ui_gnome.py
24 <madduck> there seems to be a ui for gnome...
25 <helen> madduck: another hassle I've run into with reportbug was when i tried to run it at work and it needed to get through the proxy to download the package info or whatever else it gets.
26 <helen> madduck: not everyone would know how to make it use a proxy
27 <madduck> $http_proxy should be set by d-i, i know.
28 <helen> (again, reading the manpage sorted it, but not every user would do that)
29 <helen> madduck: not if you are using a laptop that is moving around to different places, I assume
30 <madduck> true
31 <madduck> netconf...
32 <helen> I'm sure there are better ways to get around all that than what I do
33 <helen> but my point is that maybe about the only thing we can assume is that people will be using a browser and some sort of email client
34 <helen> so it would be great if we can make reporting bugs easy to do with the tools people are used to
35 <helen> either with a webpage or with their usual email program
36 <liw> helen, and not everyone uses an email client, but I'm not sure we can accomodate them
37 <helen> liw: yes, not everyone. Webpage is the most general thing, I think.
38 <liw> we often need to ask the bug reporter things and debbugs is based on doing this by email, this leads to complications, hmm
39 <helen> yes, that is a problem
40 <madduck> helen: a web page would be great. it might even be possible to make it *use* reportbug as a backend. and follow the same sequence of steps.
41 <madduck> helen: add to that some nice CSS and users will dig it.
42 <madduck> helen: the problem is that it won't honour the /usr/share/reportbug/bug scripts
43 <madduck> and it won't display package-specific stuff, unless stored on the BTS
44 <madduck> helen: but it would certainly be possible to give the user a command to execute and expect them to paste the output into the browser
45 <madduck> so that could run the package-specific bug scripts and gather dependency information and other stuff.
46 <madduck> and best of all: this is really not hard to do, although I am not sure about the reportbug integration
47 <madduck> may have to refactor some of the reportbug code.
48 <madduck> still better than a separate, hard-coded series of steps.
49 <helen> that sounds like a good idea to me
50 <helen> liw: to answer your previous question, I reckon that asking the same set of things that reportbug asks would be fine, starting with "how experienced a user are you?", like reportbug asks the first time.
51 <madduck> helen: it can use cookies to store the information it stores in ~/.reportbugrc...
52 <helen> madduck: yes, that's a good idea.
53 <madduck> isn't there a #d-w todo list or so?
54 <helen> there is, on the wiki
55 <madduck> question is: can i just paste the IRC log between you and I on there?
56 <helen> it's linked from the involvement page, I think
57 <madduck> or do I have to paraphrase?
58 <helen> madduck: yes, you have my permission to paste whatever I said in there
59 <helen> including that last :)
60 <madduck> and liw?
61 <liw> madduck, things related to a debbugs web interface, yes
62 <aj> also, please don't be overly proactive about a debbugs web interface without being very careful about (a) encouraging duplicate bug reports, or ones that lack necessary information; and (b) encouraging spam (by having a web form that mails submit@ in a way that doesn't get junked as poorly formatted)
63 <helen> aj: I was just wondering now whether it would make sense to implement something that would look for a bugreport that was wrongly formatted (probably this is already there) or that lacked the packages-installed etc info that reportbug uses, and emailed the submitter asking for that info please.
64 <helen> presumably wrongly formatted bug reports already get bounced with an explanation
65 <aj> helen: the "installed..." info isn't always needed; reports missing the "Package:" header (ie, most spam) get bounced
66 <helen> but maybe it would be useful to email submitters with "thanks for the bug report, we'd like to have the dependancy/version information, please use this command to get it and email it back to us"