On Wed, 2006-03-15 at 13:33 -0800, Daniel Robitaille wrote: > *) Malone can receive reports that are related to any of 15,000+ > packages. I'm skeptical that a script could deal for that wide range > of possibility of what went wrong, and what pieces of info are needed
> for the developers.
One possibility would be to have each package provide its own set of bug report scripts and/or other bug reporting policies. The bug reporting application would call these scripts and attach their output while
guiding the user through the bug submission.
On Fri, Mar 17, 2006 at 03:55:16AM +1100, Jamie Jones wrote:
> On Thu, 2006-03-16 at 17:06 +0100, John Nilsson wrote:
> > One possibility would be to have each package provide its own set of bug
> > report scripts and/or other bug reporting policies. The bug reporting
> > application would call these scripts and attach their output while
> > guiding the user through the bug submission.
> That was possible with the reportbug tool, indeed I make use of it for
> my 3rd party .debs, but reportbug does not work with lp. Once I tell
> people about reportbug, they usually use it to send me bug reports, and
> it brings all the useful information with it thanks to my script, eg
> logs, cpu & opengl info. If wanted I could share my bash scripts, but
> they are trivial to make ( cat foo >> bar )
> That functionality would be nice to have for Ubuntu packages as well.
Seconded. I use reportbug scripts to collect package specific
information for the package I maintain in Debian as well. I would love
to see an easy way for user to attach these information to their malone
bug report (reportbug is not a very new-user-friendly tool, after all).
Darren L wrote:
> My suggestion was actually for something simpler. A complete report
> from the application might be too ambitious, but something simple like
> dmesg, and maybe uname, etc.
I think that this type of generic information that helps with a good
percentage of bugs along with the ability to select the application
package (if known) and query some dpkg-query information regarding its
status and history would greatly improve the initial quality of a bug
report and decrease the amount of "needs info" dancing. -mf