Menu
IRC Meeting Minutes
Projects
Articles
Notes |
This is the relevant discussion from IRC, reproduced with permission:
[=
< helen> we need a *webpage*, if we want to make it easy < madduck> should be trivial to write one. < madduck> the problem is that it encourages users to submit inferior bug reports < madduck> for there is no easy way to make bug reports include the stuff about
dependencies etc. that reportbug adds
< madduck> automatically. < helen> madduck: yes, but using reportbug is not easy for everyone < madduck> helen: so that should be worked on. < helen> madduck: for starters, not everyone will have their mail set up so
reportbug can email out
< helen> I don't < helen> but I know how to use reportbug -o < helen> but you can't assume that people will actually read and understand the
manpage
< madduck> helen: fair point. can't you use thunderbird for reportbug though? < madduck> i think mail setup in debian is in dire need for improvement. < helen> madduck: my strategy is to use reportbug to generate the bug report, and
then paste the resulting output into thunderbird and email it.
< madduck> helen: uh oh. < madduck> helen: it should be trivial to make reportbug spawn a thunderbird
compose window.
< helen> if there is a thunderbird plugin for reportbug I don't know about it < madduck> it's just a command... < helen> that would be very good < 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 :)
< 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.
< madduck> I'll check out reportbug... < madduck> /usr/share/reportbug/reportbug_ui_gnome.py < madduck> there seems to be a ui for gnome... < 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.
< helen> madduck: not everyone would know how to make it use a proxy < madduck> $http_proxy should be set by d-i, i know. < helen> (again, reading the manpage sorted it, but not every user would do that) < helen> madduck: not if you are using a laptop that is moving around to
different places, I assume
< madduck> true < madduck> netconf... < helen> I'm sure there are better ways to get around all that than what I do < 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
< helen> so it would be great if we can make reporting bugs easy to do with the
tools people are used to
< helen> either with a webpage or with their usual email program < liw> helen, and not everyone uses an email client, but I'm not sure we can
accomodate them
< helen> liw: yes, not everyone. Webpage is the most general thing, I think. < liw> we often need to ask the bug reporter things and debbugs is based on doing
this by email, this leads to complications, hmm
< helen> yes, that is a problem < 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.
< madduck> helen: add to that some nice CSS and users will dig it. < madduck> helen: the problem is that it won't honour the
/usr/share/reportbug/bug scripts
< madduck> and it won't display package-specific stuff, unless stored on the BTS < 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
< madduck> so that could run the package-specific bug scripts and gather
dependency information and other stuff.
< madduck> and best of all: this is really not hard to do, although I am not sure
about the reportbug integration
< madduck> may have to refactor some of the reportbug code. < madduck> still better than a separate, hard-coded series of steps. < helen> that sounds like a good idea to me < 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.
< madduck> helen: it can use cookies to store the information it stores in
~/.reportbugrc...
< helen> madduck: yes, that's a good idea. < madduck> isn't there a #d-w todo list or so? < helen> there is, on the wiki < madduck> question is: can i just paste the IRC log between you and I on there? < helen> it's linked from the involvement page, I think < madduck> or do I have to paraphrase? < helen> madduck: yes, you have my permission to paste whatever I said in there < helen> including that last 
< madduck> and liw? < liw> madduck, things related to a debbugs web interface, yes < 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)
< 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.
< helen> presumably wrongly formatted bug reports already get bounced with an
explanation
< aj> helen: the "installed..." info isn't always needed; reports missing the
"Package:" header (ie, most spam) get bounced
< 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"
=]