• ReportbugWeb

   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"