On #422085 and #417256
Since I received a terrifying amount of insults via mail for not implementing this feature request after my last blog entry, where I asked for help developing rng, I’d like to make my position about this issue clear.
Why I was opposed to implement it:
- I personally hated that some packages sent a huge amount of unrelated info with every bugreport for this package, even if it’s not meaningful for this bugreport. I made a quick check against my favorite package with a very long output and thought (and still think) that this info is not even relevant for the majority of bugreports of this package. So I thought it was not too much to ask, to write the reporter a friendly mail to post the output of this script, if it’s really needed.
- I was personally very annoyed by packages with very long presubj text, which I doubt anyone reads anyway. Since I don’t want rng to be annoying to the users, I decided to leave that feature away. An implementation of this feature would mean to pop up a window with some text the user should read before continuing to report the bug. I don’t like popups and don’t want rng to make use of them.
- I’m definitely opposed to a feature which will pop up a terminal where a user has to do something before he can proceed reporting a bug. Sorry, but this won’t happen in rng. I might consider such a thing if it could be scripted to use QT or even GTK but a terminal popping up in a GUI application is a no-go for me, sorry.
- I was personally very annoyed by some of the reactions on this bugreport. Since we’re all volunteers and stuff and this feature is maybe a nice-to-have but definitely not a must-have, I decided to put this issue very low on my to do list.
However, I agree that the stuff in /usr/share/bug isn’t completely useless. The opposite is true, it makes the life of maintainers easier and rng should make use of it where possible.
So what can we do now? Maybe we can start all over and discuss this issue in a more friendly and constructive way?
Here’s my offer: rng will support bugscripts, but it will not feature a terminal popping up asking a user questions. I’m developing a GUI application and a popping up terminal is not very GUI’ish for me. What can we do about this? Is there a way to implement this?
Supporting presubj might be okay too, but I don’t want rng to be annoying. Popups are annoying and having to read the same stuff again and again when reporting multiple times on the same package is annoying too. Maybe rng could spawn a pop up with a checkbox “Don’t show this text again when reporting a bug against this package”? Maybe we could have an option in the (not yet implemented) preferences window where we could suppress those messages completely?
And please, don’t use abusive language or even insults when contacting me about this issue. My rng-time is currently very limited and my motivation to work especially on this issue is already very low. We’re speaking here about a fully optional feature. Providing the output of some scripts or having to read a presubj is helpful, but not mandatory when reporting a bug. So please, be nice! I really don’t need all that stress right now.
Tags: reportbug-ng
December 18th, 2007 at 1:36 am
Thank’s for this really constructive post!
Hopefully something can be worked out which makes most of the people happy.
December 18th, 2007 at 2:15 am
Well, I am not even sure what “presubj” really is, but if I guess right, why not have a GTK expander (or whatever those triangles are called you can click, and some text/other GUI element pops up, see e.g. the GTK file chooser in save-as mode). That expander could have “Show additional information by the package maintainer” written next to it or something, and would display it that information if the user clicks. That might not address everybody’s need, though, maybe. Annoying presubjs should get fixed anyway.
In any case, not sure what the problem with large automatic package-specific information is, those wouldn’t be visible to the user anyway, would they? Maybe it would be fine to attach them gzipped, if bandwidth is a concern.
Michael
December 18th, 2007 at 8:55 am
I’m probably missing something; why do you care if the bug report contains redundant information or not? Maintainers read the bugs and bug scripts are being put there by the maintainers.
So, if I a particular maintainer decided to put bits and pieces of information to his bug reports, I can’t understand how you can judge this information redundant.
The terminal issue stands though.
December 18th, 2007 at 10:29 am
For the terminal problem, are you looking for something that zenity couldn’t provide? (I realise zenity is GTK+, but there’s surely a Qt equivalent.)
- Chris
December 18th, 2007 at 11:25 am
How about we start using debconf (or something similar) for those scripts? Dunno whether that’s a good idea, but the problem of “I’m not going to use a terminal!” sounds like a problem that’s already been solved to me.
Since I’m here anyway: please consider renaming rng. Calling anything “Next Generation” is generally a bad idea IMO, since it implies a bunch of negative things about the “original” that make no sense.
December 18th, 2007 at 11:26 am
+1 on Wouter’s suggestion. A debconf-like solution, where the scripts in /usr/share/bug did not do terminal IO directly but called some functions, would be best. Then reportbug could hook them into termio and rng could hook them into GUI functions as appropriate.
the place to start would be to tar up the union of all files in /usr/share/bug from all packages and work out what their IO “needs” are, to shape the function interface.
December 18th, 2007 at 11:47 am
I think it would be useful to define use cases for interactive bug scripts first.
The few I looked at seem to make them fall in two categories:
1. Bogus interactivity when it is not really needed (e.g. “Do you want to continue (y/n)?”) and a presubj would be just as fine.
2. Asking the user whether we should send sensitive/private data as well (APT config, exim4 setup)
3. I probably missed something
The second looks like a possibly important use case to me and I am not sure how to solve this.
One possibilty would be to have some standard interface which states the package would send some sensitive data, and queries the user. That could be implemented in either text or GUI independently.
I am not sure we need debconf here at all.
December 21st, 2007 at 12:49 am
Having first read Martin Krafft’s commentary on this post, I’d have to say Wouter should note very closely what the intent of a bug reporting system is: it’s a means to provide useful information to package maintainers and developers on problems with software, and allow them to be rectified. Good bugs take smart users, and some handholding. Increasing the volume of non-actionable bugs reported does _not_ help the Debian project, and will _not_ improve the quality of its packages.
What you need to be asking yourself is: how do I ensure that people who do have useful information to contribute about b0rken behavior can do so correctly, informatively, correctly, and having satisfied those requirements: reasonably easily.
Your comments above strongly suggest you’re not the person to write reportbug-ng, and it isn’t the tool to replace reportbug (which, crufty, old, and text-based as it is remains one hell of a good bug-tracking system, and I’ve seen many).