Comments on: On #422085 and #417256 http://blog.venthur.de/2007/12/18/on-422085-and-417256/ and no tagline either Mon, 06 Sep 2010 10:18:39 +0000 http://wordpress.org/?v=2.5.1 By: Karsten M. Self http://blog.venthur.de/2007/12/18/on-422085-and-417256/#comment-29841 Karsten M. Self Thu, 20 Dec 2007 23:49:52 +0000 http://blog.venthur.de/2007/12/18/on-422085-and-417256/#comment-29841 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). 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).

]]> By: Michael Banck http://blog.venthur.de/2007/12/18/on-422085-and-417256/#comment-29571 Michael Banck Tue, 18 Dec 2007 10:47:22 +0000 http://blog.venthur.de/2007/12/18/on-422085-and-417256/#comment-29571 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. 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.

]]> By: Jon http://blog.venthur.de/2007/12/18/on-422085-and-417256/#comment-29566 Jon Tue, 18 Dec 2007 10:26:56 +0000 http://blog.venthur.de/2007/12/18/on-422085-and-417256/#comment-29566 +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. +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.

]]> By: Wouter Verhelst http://blog.venthur.de/2007/12/18/on-422085-and-417256/#comment-29565 Wouter Verhelst Tue, 18 Dec 2007 10:25:00 +0000 http://blog.venthur.de/2007/12/18/on-422085-and-417256/#comment-29565 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. 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.

]]> By: Chris Cunningham http://blog.venthur.de/2007/12/18/on-422085-and-417256/#comment-29559 Chris Cunningham Tue, 18 Dec 2007 09:29:56 +0000 http://blog.venthur.de/2007/12/18/on-422085-and-417256/#comment-29559 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 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

]]> By: Faidon Liambotis http://blog.venthur.de/2007/12/18/on-422085-and-417256/#comment-29546 Faidon Liambotis Tue, 18 Dec 2007 07:55:17 +0000 http://blog.venthur.de/2007/12/18/on-422085-and-417256/#comment-29546 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. 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.

]]> By: Michael Banck http://blog.venthur.de/2007/12/18/on-422085-and-417256/#comment-29485 Michael Banck Tue, 18 Dec 2007 01:15:21 +0000 http://blog.venthur.de/2007/12/18/on-422085-and-417256/#comment-29485 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 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

]]> By: Trigger http://blog.venthur.de/2007/12/18/on-422085-and-417256/#comment-29477 Trigger Tue, 18 Dec 2007 00:36:36 +0000 http://blog.venthur.de/2007/12/18/on-422085-and-417256/#comment-29477 Thank's for this really constructive post! Hopefully something can be worked out which makes most of the people happy. Thank’s for this really constructive post!
Hopefully something can be worked out which makes most of the people happy.

]]>