Hi, On Tue, Dec 18, 2007 at 10:06:21AM +0100, Bastian Venthur wrote: > >> 3. 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. > > > > For any script that is non-interactive the terminal will appear and then > > disappear once the script is done running. On my system it's barely > > noticeable. One thing that I'd be open to is modifying the standard so that > > scripts put something like #BUG_INTERACTIVE in the interactive scripts. We > > could trivially grep for this phrase, launch a terminal in this one case, > > or just run the script and get the output directly if this comment is > > absent. I don't know of any interactive bug scripts that currently exist, > > so this should be a fairly simple thing to require if people are willing > > (I've CC'ed -devel for opinions on this). > > Sounds all very good to me, but I still doubt that there are actually > cases where it is really important for the majority of bugreports that > the user has to answer a specific question. I don't want to sound > ignorant (although I guess I already do...), but please show me a few > packages to convince me.
Well, quoting somewhat my comment to your blog entry: 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. Sune has been filing bugs on packages falling in the first category. 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. It would probably be appropriate to just add a notice somewhere in the GUI saying that possibly sensitive data is being sent and user should review it, no need for a dialog. On the other hand, that would mean the additional data in that case should be rather small, to make that feasable. Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
