Bug#422085: Better terminal emulator patch
severity 422085 serious thanks Bastian, On Mon, Jun 09, 2008 at 01:23:50AM +0200, Bastian Venthur wrote: Again, I don't see which part of the policy rng is violating. So downgrading the bug again back to wishlist. You are violating common sense. It's fine if you don't want to work on this bug, but please keep in mind that this is considered RC for Lenny. I.e. if you want your application included in Lenny, it will need to be fixed. We don't want applications producing bugs reports that lack critical information for the maintainers to increase the workload of your fellow developers needlessly. Thanks to the severity ping pong reportbug-ng will be removed from testing and blocked until this bug is fixed. Kind regards, Philipp Kern -- .''`. Philipp Kern Debian Developer : :' : http://philkern.de Debian Release Assistant `. `' xmpp:[EMAIL PROTECTED] `-finger pkern/[EMAIL PROTECTED] signature.asc Description: Digital signature
Bug#422085: Better terminal emulator patch
Philipp Kern wrote: On Mon, Jun 09, 2008 at 01:23:50AM +0200, Bastian Venthur wrote: Again, I don't see which part of the policy rng is violating. So downgrading the bug again back to wishlist. You are violating common sense. It's fine if you don't want to work on this bug, but please keep in mind that this is considered RC for Lenny. I.e. if you want your application included in Lenny, it will need to be fixed. We don't want applications producing bugs reports that lack critical information for the maintainers to increase the workload of your fellow developers needlessly. Thanks to the severity ping pong reportbug-ng will be removed from testing and blocked until this bug is fixed. If you really think this missing feature is an RC bug, then please go ahead. I've better things to do than discussing the severity of this bug. Bastian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#422085: Better terminal emulator patch
severity 422085 serious thanks Hi there, On Tue, Dec 18, 2007 at 10:47:54AM +0100, Sam Hocevar wrote: 1. I *personally* hated that some packages sent a *huge* amount of 2. I *personally* was very annoyed by packages with very long presubj 3. I'm definitely opposed to a feature which will pop up a *terminal* 4. I was *personally* very annoyed by some of the reactions on this Luckily our priorities are Our Users and Free Software, not Bastian Venthur. Applying David's patch *immediately* means that maintainers get more useful bug reports that help them fix bugs, and in the end our users get a better support. I hope you realise that reportbug-ng being non-functional with a handful of packages means that users will have to use reportbug to report a bug on these packages. So they will see the ugly terminal anyway. I don't think anyone is opposed to rethink the way bug scripts are handled (even in reportbug) so that they integrate better with the reportbug-ng interface. But that should not prevent improvements from happening first. So I suggest you do that right now, or let someone else NMU reportbug-ng. I agree with Sam's conclusion. I hereby conclude that reportbug-ng is, in its present condition, unfit for release. Thus I raise the severity of this bug report to serious. reportbug-ng needs to be a good citizen and needs to use the infrastructure currently in place to provide good bug reports. This makes it easier (and faster) to get the bugs fixed. I suppose that your intention behind writing reportbug-ng is to ease bug reporting for our users. It must not ignore information explicitly requested by package maintainers by the means of bug scripts. I do not see how both goals, providing the necessary information to those who handle the bug reports and making it easy for the reporters, collide. Kind regards, Philipp Kern -- .''`. Philipp Kern Debian Developer : :' : http://philkern.de Debian Release Assistant `. `' xmpp:[EMAIL PROTECTED] `-finger pkern/[EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#422085: Better terminal emulator patch
On Tue, Dec 18, 2007 at 02:47:14AM +, David Nusinow wrote: On Tue, Dec 18, 2007 at 12:47:39AM +0100, Bastian Venthur wrote: Since I received a terrifying amount 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 was I opposed to implement this. 1. 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. Is your bandwidth _that_ cheap ? I mean what is the point to stripping informations for users that already send bad bug-reports where it could actually save it ? Your reasoning totally eludes me. 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. It's pretty obvious that you don't package things with a very large user base then. And given the numerous times where David, Julien or myself explained to you why this assertion is wrong, well … 2. I *personally* was 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 haven't implemented presubj text in my patch, so this is a non-issue for that specifically. I'd say that not showing presubj is as wrong. For the libc there is a very usual bug about locales depends. We now have a presubj about that, and we didn't had bug reports for libc 2.7 about locales. Meaning that it works (we had ~10 for the 2.6). The locales package presubj has the tremendous line count of *18* lines. What an aggression ! Its full content is : locales dependencies on glibc = If at some point (in unstable) you get messages like: The following packages have unmet dependencies: locales: Depends: glibc-2.6-1 which is a virtual package. then please check for example on [1] that the glibc of the _same_ version as the `locales` package you are trying to upgrade is in state _installed_ for your architecture, and for how long. If it's not, it is very likely that the corresponding libc has not been built _and_ uploaded to the mirrors for your architecture yet, and that the dependencies will be fixed soon. Please wait for the package to be installed for more than 24 hours before reporting abug about `locales` dependencies. [1] http://buildd.debian.org/~jeroen/status/package.php?p=glibc And if you find the presubj's are too long, then bug the packages. Your [bastian's not david's] reasoning is the same as saying damn 10 Debian packages have too many debconf questions, let's make debconf default priority ultra-high so that this 10 packages that I never install anyway won't bug me with those questions. Huh ? Doesn't make sense. If the maintainer put a presubj (or anything else) then he felt it was necessary. WHO THE HELL ARE YOU TO KNOW HIS JOB BETTER ? 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). Such a script is the one from hibernate for example. Well, I would be surprised if it was used for anything else than questions with yes/no or even a string answer. It would be even better to provide some API that rng could supersede that would be sourced from those scripts so that it even doesn't starts a terminal, and rather show nice X11 queries. I suppose using zenity for that may work e.g. Though it would need to rewrite the couple of interactive scripts out there, I'm sure it's not a
Bug#422085: Better terminal emulator patch
On 18.12.2007 03:47 schrieb David Nusinow: On Tue, Dec 18, 2007 at 12:47:39AM +0100, Bastian Venthur wrote: Why was I opposed to implement this. 2. I *personally* was 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 haven't implemented presubj text in my patch, so this is a non-issue for that specifically. Yes, but I've merged this bug with a similar one where the reporter wanted rng to support presubj. 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. 4. 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? I've offered a partial solution for the terminal above. I think that neutering the interactive scripts is a horrific idea though. Users who can report bugs can handle having a terminal ask them a question or two. That is probably true, but I don't want a *terminal* popping up asking for questions in my (or any other) *GUI* application. Especially since I'm currently not really convinced that those questions are really necessary. That'd be a fine option. I don't know how you'd want to handle storing preferences, but it's probably fairly trivial. I'd be happy to work on that though. A separate textile listing a package per line or something should be sufficient. 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've been nice, polite, and patient, so please stop implying that I've been otherwise. Rather than hurl insults I wrote, tested, and improved the patch Sorry, I didn't mean you. You (and others) where friendly and actually trying to help. But I really received a lot of unfriendly feedback about this issue. Some people seem to forget that I wasted *my* time to make their (the bugreporters) life a bit easier, but as soon as you don't do as they say, you become an asshole, moron and whatnot. for this. Several people have been interested in having this escalated to the tech-ctte, which I am willing to do, at which point it will no longer be a fully optional feature. I don't want to take this to the tech-ctte, As far as I remember I was the one who offered to bring this to tech-ctte, I don't remember why, but I think it was something like: some argued that rng *had* do have this feature, while I insisted that it is not mandatory or something. I think I even offered to implement it if they decided that this feature is mandatory. but this issue
Bug#422085: Better terminal emulator patch
On Tuesday 18 December 2007, Bastian Venthur wrote: I haven't implemented presubj text in my patch, so this is a non-issue for that specifically. Yes, but I've merged this bug with a similar one where the reporter wanted rng to support presubj. And presubj is the most important thing here from my POV (wearing kde packager hat) It is the only way we realistically can try to actually improve the quality of the bug reports we recieve, so we can spend the time fixing the bugs instead of fixing the bug reports. Some people seem to forget that I wasted *my* time to make their (the bugreporters) life a bit easier, but as soon as you don't do as they say, you become an asshole, moron and whatnot. Some people seem to forget that the current implementation of rng is wasting maintainers time. And honestly. I consider maintainer time a bit more valuable than bug reporter time. /Sune -- How can I do for reconfiguring the login on the IRC periferic? From Excel 2.3 you either should never link a tool, or can never turn on the DLL icon, so that you should forward to the coaxial hardware, so that from the file inside Word NT you should get access over a 3X jumper over the system, in such way then you neither can debug the pointer on the 95-bit terminale, nor need to send to a space bar for exploring the provider over a head to a PCI button over a URL on a clock of the LCD OpenGL gadget. signature.asc Description: This is a digitally signed message part.
Bug#422085: Better terminal emulator patch
On Tue, Dec 18, 2007, Bastian Venthur wrote: 1. I *personally* hated that some packages sent a *huge* amount of 2. I *personally* was very annoyed by packages with very long presubj 3. I'm definitely opposed to a feature which will pop up a *terminal* 4. I was *personally* very annoyed by some of the reactions on this Luckily our priorities are Our Users and Free Software, not Bastian Venthur. Applying David's patch *immediately* means that maintainers get more useful bug reports that help them fix bugs, and in the end our users get a better support. I hope you realise that reportbug-ng being non-functional with a handful of packages means that users will have to use reportbug to report a bug on these packages. So they will see the ugly terminal anyway. I don't think anyone is opposed to rethink the way bug scripts are handled (even in reportbug) so that they integrate better with the reportbug-ng interface. But that should not prevent improvements from happening first. So I suggest you do that right now, or let someone else NMU reportbug-ng. 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! Yes, please be nice to your fellow developers. I am sorry you got insulted, but if you only got insults and no offer to help, that may indicate something to rethink about your attitude. Best regards, -- Sam. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#422085: Better terminal emulator patch
Hi Bastian, On Tue, Dec 18, 2007 at 12:47:39AM +0100, Bastian Venthur wrote: David Nusinow wrote: Hi Bastian, On Sun, Dec 16, 2007 at 11:39:03PM +0100, Bastian Venthur wrote: Hi David, thanks for your effort and the patches. Personally, I don't like the idea of a terminal popping up asking the user questions when a user uses a GUI application. Because the scripts can be interactive, I see no other way. Since the output of the bugscripts stuff is AFAIK still not mandatory for bugreports, I ask you do not upload this patch as NMU. May I ask why not? This is a really important feature for many developers and we'd like to see it in ASAP. - David Nusinow Since I received a terrifying amount 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 was I opposed to implement this. 1. 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. It is a great deal to ask when you've got a lot to do. You yourself are busy with real life, so much so that you're asking for help with rng. Well, the rest of us are plenty busy too, and these scripts can be a significant time saver for all of us, both developers and users. Refusing to support them is simply callous. Furthermore, your implementation allows the user to trivially delete all this information in their email client if they're annoyed by it, so this is a non-issue in rng. 2. I *personally* was 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 haven't implemented presubj text in my patch, so this is a non-issue for that specifically. 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). 4. 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? I've offered a partial solution for the terminal above. I think that neutering the interactive scripts is a horrific idea though. Users who can report bugs can handle having a terminal ask them a question or two. One alternate method is to require interactive scripts to use debconf, which should be a good middle ground because they've already used it during the install. We could check what frontend debconf is using, and if it requires a terminal we pop one up and if not then just let the gtk frontend do its thing. Again, this would be something other developers would have to agree to, but I think this is actually a better way to handle these sorts of scripts now that debconf is our standard for interaction. Supporting presubj might
