* Re: bug#13141: please review bug #13141 [not found] ` <415AF94149E240B7BCB28128E45D3135__10998.9037890502$1358637091$gmane$org@us.oracle.com> @ 2013-01-20 0:35 ` Dmitry Gutov 2013-01-20 0:54 ` Xue Fuqiao 2013-01-20 1:03 ` Drew Adams 0 siblings, 2 replies; 9+ messages in thread From: Dmitry Gutov @ 2013-01-20 0:35 UTC (permalink / raw) To: Drew Adams; +Cc: 13141, emacs-devel "Drew Adams" <drew.adams@oracle.com> writes: > This is about the info that gets automatically added to bug reports. > > Stefan granted that most of that info is anyway useless, to him at least. > Jambunathan suggested a Boolean option to skip such info altogether. > > I provided a patch that lets users customize which info to include. > > Glenn simply tagged the bug `wontfix', saying "There is no need for such > complexity." > > > The patch is straightforward. Please reconsider it. > Why not let users set the behavior they want for this? Personally, I disagree that the user should choose what information to include. The report goes to Emacs maintainers, so they should pick the always-useful parts (say, the version, bzr revision and build options) and leave out the noise. While possibly still providing interactive commands allowing to insert the additional information in a follow-up email. I also think this is one of the parts of Emacs where backwards compatibility is the least important, so it's odd that the bug reporting interface hasn't changed much in years. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: bug#13141: please review bug #13141 2013-01-20 0:35 ` bug#13141: please review bug #13141 Dmitry Gutov @ 2013-01-20 0:54 ` Xue Fuqiao 2013-01-20 7:19 ` Stephen J. Turnbull 2013-01-20 1:03 ` Drew Adams 1 sibling, 1 reply; 9+ messages in thread From: Xue Fuqiao @ 2013-01-20 0:54 UTC (permalink / raw) To: Dmitry Gutov; +Cc: 13141, Drew Adams, emacs-devel On Sun, 20 Jan 2013 04:35:24 +0400 Dmitry Gutov <dgutov@yandex.ru> wrote: > Personally, I disagree that the user should choose what information to > include. The report goes to Emacs maintainers, so they should pick the > always-useful parts (say, the version, bzr revision and build options) and > leave out the noise. In (info "(emacs) Checklist"): You may feel that some of the information inserted by `M-x report-emacs-bug' is not relevant, but unless you are absolutely sure it is best to leave it, so that the developers can decide for themselves. But *extensible and customizable* (and self-documenting) are the core of Emacs. Experienced users *know* that what information should be go to the Emacs developers. It also lightens the burden of Emacs developers. -- Best regards, Xue Fuqiao. http://www.emacswiki.org/emacs/XueFuqiao ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: bug#13141: please review bug #13141 2013-01-20 0:54 ` Xue Fuqiao @ 2013-01-20 7:19 ` Stephen J. Turnbull 2013-01-20 19:46 ` Harald Hanche-Olsen 0 siblings, 1 reply; 9+ messages in thread From: Stephen J. Turnbull @ 2013-01-20 7:19 UTC (permalink / raw) To: Xue Fuqiao; +Cc: 13141, emacs-devel, Drew Adams, Dmitry Gutov Xue Fuqiao writes: > But *extensible and customizable* (and self-documenting) are the core > of Emacs. Experienced users *know* that what information should be go > to the Emacs developers. Experienced developers know that what experienced users "know" often enough just ain't so. The only case where users are in a good position to decide is about privacy-sensitive information that might be in traces or keystroke logs, etc. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: bug#13141: please review bug #13141 2013-01-20 7:19 ` Stephen J. Turnbull @ 2013-01-20 19:46 ` Harald Hanche-Olsen 0 siblings, 0 replies; 9+ messages in thread From: Harald Hanche-Olsen @ 2013-01-20 19:46 UTC (permalink / raw) To: emacs-devel ["Stephen J. Turnbull" <stephen@xemacs.org> (2013-01-20 07:19:10 UTC)] > Experienced developers know that what experienced users "know" often > enough just ain't so. > > The only case where users are in a good position to decide is about > privacy-sensitive information that might be in traces or keystroke > logs, etc. I admit to being one of those who routinely deletes much of the noise before submitting a bug report. But then, whenever possible, I try to figure out a way to reproduce the bug starting from emacs -Q. In which case Major and minor modes, recent input, and recent messages are truly irrelevant, and so I delete them before submitting the bug report. (An extreme case is #11358, where I have deleted *all* the predetermined info.) In any case, I hardly ever report a bug immediately after encountering it. I am usually too busy trying to get stuff done, so I finish that first, then investigate the bug, typically in a separate emacs instance, and then submit a bug report. In which case I am quite confident that recent input and messages are beside the point, so I delete them. But perhaps I am very unusual as bug reporters go. In any case, I don't really see the need for more options. If I can delete irrelevant parts from the bug reports, so can anybody else. I don't think we need to make it any easier than it already is, especially as it appears some people are already deleting more than they should. But perhaps they should be told, somehow, to review recent input and messages for private content that they may not wish to reveal to the world. - Harald ^ permalink raw reply [flat|nested] 9+ messages in thread
* RE: bug#13141: please review bug #13141 2013-01-20 0:35 ` bug#13141: please review bug #13141 Dmitry Gutov 2013-01-20 0:54 ` Xue Fuqiao @ 2013-01-20 1:03 ` Drew Adams 1 sibling, 0 replies; 9+ messages in thread From: Drew Adams @ 2013-01-20 1:03 UTC (permalink / raw) To: 'Dmitry Gutov'; +Cc: 13141, emacs-devel > Personally, I disagree that the user should choose what information > to include. Too bad for you, then. The user already chooses that. As well s?he should. A user should _of course_ be able to choose what information s?he sends. This is about the information that is _automatically_ inserted into the report-preparation buffer. If the user does not want to send some of that info then s?he need not, even today, as Xue Fuqiao made clear. All my patch does is make it easier for a user to not send this or that info. > The report goes to Emacs maintainers, so they should pick the > always-useful parts The maintainers should pick the parts that they think should be provided _by default_, just as they do today. They cannot and should not pick, in place of the user, what the user actually sends. And one of the maintainers has already stated, FWIW, that he finds "most of those info useless". > (say, the version, bzr revision and build options) and leave > out the noise. One person's noise is another's important information. That's part of the point of providing this option: if a user so chooses, s?he can easily cut down on what s?he considers noise. Let users decide. Emacs proposes, users dispose. And I repeat, the default behavior - the information that is automatically included by default - does NOT change with this patch. > While possibly still providing interactive commands > allowing to insert the additional information in a follow-up email. Nothing wrong with that, IMO. Consider submitting an enhancement request for the addition of such commands. > I also think this is one of the parts of Emacs where backwards > compatibility is the least important, so it's odd that the > bug reporting interface hasn't changed much in years. You are welcome to submit an enhancement request to change the set of info that gets inserted by default. My patch is not so radical as what you are requesting. It maintains the status quo wrt that set of info - the default behavior. It simply makes it easy for a user to customize what which info gets inserted by default. There already is a user option, `report-emacs-bug-no-explanations', that turns it all off. My patch just gives users more control than an on/off switch. ^ permalink raw reply [flat|nested] 9+ messages in thread
* please review bug #13141 @ 2013-01-19 23:10 Drew Adams 2013-01-19 23:20 ` Alan Mackenzie 0 siblings, 1 reply; 9+ messages in thread From: Drew Adams @ 2013-01-19 23:10 UTC (permalink / raw) To: emacs-devel; +Cc: 13141 This is about the info that gets automatically added to bug reports. Stefan granted that most of that info is anyway useless, to him at least. Jambunathan suggested a Boolean option to skip such info altogether. I provided a patch that lets users customize which info to include. Glenn simply tagged the bug `wontfix', saying "There is no need for such complexity." The patch is straightforward. Please reconsider it. Why not let users set the behavior they want for this? http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13141#43 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: please review bug #13141 2013-01-19 23:10 Drew Adams @ 2013-01-19 23:20 ` Alan Mackenzie 2013-01-19 23:59 ` Drew Adams 0 siblings, 1 reply; 9+ messages in thread From: Alan Mackenzie @ 2013-01-19 23:20 UTC (permalink / raw) To: Drew Adams; +Cc: 13141, emacs-devel Hi, Drew. On Sat, Jan 19, 2013 at 03:10:09PM -0800, Drew Adams wrote: > This is about the info that gets automatically added to bug reports. > Stefan granted that most of that info is anyway useless, to him at least. > Jambunathan suggested a Boolean option to skip such info altogether. > I provided a patch that lets users customize which info to include. > Glenn simply tagged the bug `wontfix', saying "There is no need for such > complexity." > The patch is straightforward. Please reconsider it. > Why not let users set the behavior they want for this? I have to side with Glenn here. We need to make Bug reporters' jobs as simple as possible. Sadly, there is a tendency for things which one _can_ configure to become things that one _must_ configure - we know all about this in Emacs - which would be most unfriendly for novice bug reporters. Let's keep this as simple as possible. > http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13141#43 -- Alan Mackenzie (Nuremberg, Germany). ^ permalink raw reply [flat|nested] 9+ messages in thread
* RE: please review bug #13141 2013-01-19 23:20 ` Alan Mackenzie @ 2013-01-19 23:59 ` Drew Adams 2013-01-20 7:16 ` Stephen J. Turnbull 0 siblings, 1 reply; 9+ messages in thread From: Drew Adams @ 2013-01-19 23:59 UTC (permalink / raw) To: 'Alan Mackenzie'; +Cc: 13141, emacs-devel > > The patch is straightforward. Please reconsider it. > > Why not let users set the behavior they want for this? > > I have to side with Glenn here. We need to make Bug > reporters' jobs as simple as possible. Why not give the individual bug reporters a say in what they think is simple? Your idea of making their life easier might not be their idea. Why does giving other users a choice bother you? The default behavior would be the same as now. > Sadly, there is a tendency for things which one _can_ > configure to become things that one _must_ configure - I don't recognize any such tendency. Give one example. > we know all about this in Emacs Well I don't know about it. I've never seen the addition of a user option, with no change to the default behavior, require any user to configure that option. That's logically impossible. If you do nothing then there is no change in behavior. If you are unaware of the option then your life is as simple as before. If you are aware of it and IF you want to take advantage of it, then you might even make life simpler for yourself than before - but that's your choice. > - which would be most unfriendly for novice bug reporters. What would? Giving a choice to any user who wants it? > Let's keep this as simple as possible. Let's give _users_ the choice. Let's let them decide what is "as simple as possible" for themselves, individually. > > http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13141#43 ^ permalink raw reply [flat|nested] 9+ messages in thread
* RE: please review bug #13141 2013-01-19 23:59 ` Drew Adams @ 2013-01-20 7:16 ` Stephen J. Turnbull 2013-01-20 18:41 ` bug#13141: " Richard Stallman 0 siblings, 1 reply; 9+ messages in thread From: Stephen J. Turnbull @ 2013-01-20 7:16 UTC (permalink / raw) To: Drew Adams; +Cc: 'Alan Mackenzie', 13141, emacs-devel Drew Adams writes: > Why not give the individual bug reporters a say in what they think > is simple? Your idea of making their life easier might not be > their idea. Why in the world do you think making life easier for bug *reporters* deserves precedence? The first principle of bug reporting is to get useful information for the debuggers. Over the 15 years that I've been responding to bug reports, I've had at least half a dozen cases where users deleted automatically added information which I then requested -- to no avail, since the reporters never responded. The cases where users fail to include useful and readily available information in plain ol' mail are legion. In general, users are notoriously poor judges of what information is useful. It might be useful to hide the automatically generated information in a MIME attachment, or add it at send time, and allow the user the option of displaying/editing it. > Let's give _users_ the choice. Let's let them decide what is "as > simple as possible" for themselves, individually. Bug reporting is not an individual activity. It is a community activity, and the needs of developers must take precedence over users' ideas of what's useful. If you think some information is unnecessary, argue it shouldn't be in the report in the first place, and get the developers to agree. Note that just because Stefan never uses the information doesn't mean that other developers don't. ^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#13141: please review bug #13141 2013-01-20 7:16 ` Stephen J. Turnbull @ 2013-01-20 18:41 ` Richard Stallman 2013-01-21 1:03 ` Dmitry Gutov 0 siblings, 1 reply; 9+ messages in thread From: Richard Stallman @ 2013-01-20 18:41 UTC (permalink / raw) To: Stephen J. Turnbull; +Cc: acm, 13141, emacs-devel I've had at least half a dozen cases where users deleted automatically added information which I then requested -- to no avail, since the reporters never responded. To go out of their way to delete it makes me wonder why. Maybe it was a valid reason. Could it be that there was something private in that information which they specifically did not want to send? Because of this consideration it would not be right to hide that information. We should not try to trick our users into sending us something they did not want to send. -- Dr Richard Stallman President, Free Software Foundation 51 Franklin St Boston MA 02110 USA www.fsf.org www.gnu.org Skype: No way! That's nonfree (freedom-denying) software. Use Ekiga or an ordinary phone call ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: bug#13141: please review bug #13141 2013-01-20 18:41 ` bug#13141: " Richard Stallman @ 2013-01-21 1:03 ` Dmitry Gutov 2013-01-21 3:02 ` Stephen J. Turnbull 2013-01-21 3:26 ` Stephen J. Turnbull 0 siblings, 2 replies; 9+ messages in thread From: Dmitry Gutov @ 2013-01-21 1:03 UTC (permalink / raw) To: Richard Stallman; +Cc: acm, Stephen J. Turnbull, 13141, emacs-devel Richard Stallman <rms@gnu.org> writes: > Stephen J. Turnbull writes: > > I've had at least half a dozen cases > where users deleted automatically added information which I then > requested -- to no avail, since the reporters never responded. If there's no information at all, maybe the users didn't go through the Emacs bug reporting interface, writing the report directly in the email client. > To go out of their way to delete it makes me wonder why. Maybe it was > a valid reason. Could it be that there was something private in that > information which they specifically did not want to send? I usually delete most of it, because the default text looks messy, and I don't like sending emails that look untidy. Also, it's harder to find the actual report description if it's surrounded by auto-generated text. It's better now that some parts of it are just shown through the display property, but the user might not know/understand that. > Because of this consideration it would not be right to hide > that information. We should not try to trick our users into sending > us something they did not want to send. As it is, the exact information the user's sending is not immediately obvious, they'd have to carefully scroll though a fairly large chunk of text to know that. IMO, it would be better to ask about each potentially-sensitive section (last keystrokes, obviously; local paths, recent messages? maybe), and then include them as attachment or several. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: bug#13141: please review bug #13141 2013-01-21 1:03 ` Dmitry Gutov @ 2013-01-21 3:02 ` Stephen J. Turnbull 2013-01-21 3:26 ` Stephen J. Turnbull 1 sibling, 0 replies; 9+ messages in thread From: Stephen J. Turnbull @ 2013-01-21 3:02 UTC (permalink / raw) To: Dmitry Gutov; +Cc: acm, Richard Stallman, emacs-devel Dmitry Gutov writes: > Richard Stallman <rms@gnu.org> writes: > > Stephen J. Turnbull writes: > > I've had at least half a dozen cases where users deleted > > automatically added information which I then requested -- to > > no avail, since the reporters never responded. > If there's no information at all, That's not the case. Another suggestion, especially for the tidy reporter: a special minor mode for editing and viewing bug reports with commands to skip to specific sections of generated data and to reduce the amount of screen space they occupy (a la outline mode, or perhaps the "MIME buttons" displayed by Gnus and VM). ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: bug#13141: please review bug #13141 2013-01-21 1:03 ` Dmitry Gutov 2013-01-21 3:02 ` Stephen J. Turnbull @ 2013-01-21 3:26 ` Stephen J. Turnbull 1 sibling, 0 replies; 9+ messages in thread From: Stephen J. Turnbull @ 2013-01-21 3:26 UTC (permalink / raw) To: Dmitry Gutov; +Cc: acm, Richard Stallman, emacs-devel Not Ccing <13141@debbugs.gnu.org> per Glenn's request. Dmitry Gutov writes: > I usually delete most of it, because the default text looks messy, and I > don't like sending emails that look untidy. Also, it's harder to find > the actual report description if it's surrounded by auto-generated text. Ah, I forgot about that. Steve Youngs fixed that for us ages ago. M-x report-xemacs-bug now pops up *two* buffers. One is a mail composition buffer which looks like this for message mode users: ------------------------------------------------------------------------ To: XEmacs Beta <xemacs-beta@xemacs.org> Subject: [Bug: 21.5-b32] Nothing works in the latest beta --text follows this line-- ================================================================ Dear Bug Team! ================================================================ System Info to help track down your bug: --------------------------------------- ------------------------------------------------------------------------ followed by the generated information. The other buffer is a help buffer explaining good style and desired content for bug reports, appended below in full just in case it has useful ideas. (Of course it is tainted from a legal viewpoint, but it wouldn't be hard to rewrite in a more GNU-y style.) The help buffer can be manipulated with the usual commands for such buffers, or suppressed completely. Steve ------------------------------------------------------------------------ This bug report will be sent to the XEmacs Development Team, not to your local site managers!! The working language of XEmacs development is English. Bug reports in English will be dealt with most promptly and most effectively. However, the XEmacs maintainers as a group speak most of the major Western languages and Japanese, so if communicating in English is a problem for you, please feel free to report your bug using one of those other languages. Please describe as succinctly as possible: - What happened. - What you thought should have happened. - Precisely what you were doing at the time. Also include a reliable recipe for triggering the bug, as well as any C and lisp back-traces that you may have. (setq stack-trace-on-error t), or (setq debug-on-error t) if you are familiar with the debugger, to get a lisp back-trace. To get a core file for the C back-trace on a GNU/Linux system do 'ulimit -c unlimited' in the shell prior to starting XEmacs. Type C-c tab to visit in Info the XEmacs Manual section about when and how to write a bug report, and what information to supply so that the bug can be fixed. Type SPC to scroll through this section and its subsections. You are very welcome to scan through the bug report and remove any potentially sensitive data. Turn off this help buffer permanently by adding: (setq report-xemacs-bug-no-explanations t) To your ~/.xemacs/init.el ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2013-01-21 3:26 UTC | newest] Thread overview: 9+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- [not found] <DA0FC7AC1D94402A949DC683C8E88CF0@us.oracle.com> [not found] ` <415AF94149E240B7BCB28128E45D3135__10998.9037890502$1358637091$gmane$org@us.oracle.com> 2013-01-20 0:35 ` bug#13141: please review bug #13141 Dmitry Gutov 2013-01-20 0:54 ` Xue Fuqiao 2013-01-20 7:19 ` Stephen J. Turnbull 2013-01-20 19:46 ` Harald Hanche-Olsen 2013-01-20 1:03 ` Drew Adams 2013-01-19 23:10 Drew Adams 2013-01-19 23:20 ` Alan Mackenzie 2013-01-19 23:59 ` Drew Adams 2013-01-20 7:16 ` Stephen J. Turnbull 2013-01-20 18:41 ` bug#13141: " Richard Stallman 2013-01-21 1:03 ` Dmitry Gutov 2013-01-21 3:02 ` Stephen J. Turnbull 2013-01-21 3:26 ` Stephen J. Turnbull
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).