From: Ihor Radchenko <email@example.com> To: Jean Louis <firstname.lastname@example.org>, Boruch Baum <email@example.com> Cc: Daniele Nicolodi <firstname.lastname@example.org>, email@example.com Subject: Re: Ignored bugs Date: Wed, 18 Nov 2020 12:04:39 +0800 [thread overview] Message-ID: <871rgrnwdk.fsf@localhost> (raw) In-Reply-To: <X7RCbYcBvoNNY/PG@protected.rcdrun.com> > As if that it not acceptable I would then propose these functions: > > M-x report-org-bug > > and > > M-x report-emacs-bug This issue has been discussed in the past in this maillist as well as in the emacs-devel: https://firstname.lastname@example.org/ https://lists.gnu.org/archive/html/emacs-devel/2020-01/msg00011.html I think making the alias you proposed was in Bastein's todo-list, according to that earlier discussion. I guess, there should be no issue accepting relevant patches here (not sure about emacs-devel) if you provide them. Best, Ihor Jean Louis <email@example.com> writes: > * Boruch Baum <firstname.lastname@example.org> [2020-11-17 23:57]: >> On 2020-11-17 21:27, Daniele Nicolodi wrote: >> > The page that introduces the Emacs bug tracker already reports that this >> > ... >> >> The way emacs users behave isn't to go search and find and read that web >> page. It's to perform M-x report-emacs-bug. For people using a command >> completion program, while they type they see similar alternatives but >> org-mode has gone its own way also in its naming convention for >> report-*-bug so its 'submit' function would not appear (nor c nor ffap). >> >> > mailing list is the right place where to report Org bugs (or feature >> > request, as is the case for at least one of the bug you reported), and >> > not the Emacs bug tracker. >> >> That cuts off anyone not wanting to be a subscriber to your mailing list >> / not wanting all the clutter of all the other conversations and threads >> of your mailing list (I certainly don't). That imposes upon them the >> burden of taking the steps to apply to join the list, confirm, post, and >> then unsubscribe any time they want to make a contribution or submit a >> report. > > As Org is part of Emacs one has to understand Boruch's point as > valid. This means it is part of Emacs and M-x report-emacs-bug should > not be ignored. Managers of the mailing list or Org developers could > make sure to read those bug reports as well. A cron job to grep report > for Org bugs can help there. > > It is quite clear when user finds out about M-x org-submit-bug-report > that such will rather use that. But there is plethora of users who may > not find that option and they will simply reach to Help menu to submit > the bug. > > There is menu item Org and Submit bug report. But user may not find > that menu item as first thing to reach could be simply "Help" and > submit bug report. > >> But, let's try out your suggested method of reporting. Here I am on your >> mailing list, reporting that function org-submit-bug-report should >> either be renamed or aliased to something more consistent with function >> report-emacs-bug, possibly report-emacs-org-bug. > > I may join and say I support that alignment with the other function. > > Personally as Org is part of Emacs, I think it should not have special > bug reporting, but it should rather be in M-x report-emacs-bug > together. I say this as I see that bugs sent to mailing list may not > have its proper action cycles, or proper tracking. But I am unsure of > it. You could develop the function report-emacs-bug to have users say > clearly it is Org bug. > > One could detect if user is invoking report-emacs-bug from Org mode > and only then ask user "Is this Org mode bug?" and provide that little > different instructions for Org mode. > > As if that it not acceptable I would then propose these functions: > > M-x report-org-bug > > and > > M-x report-emacs-bug > > As those are more aligned to each other or just as Boruch said. > >> > You are deliberately ignoring these instructions. What do you expect? >> >> For one, I expect you to not unjustly impute to me motive, and not to >> take that 'what do you expect' attitude with me (or with anyone else). > > It is good to be considerate for reason that we should be, and to > consider good faith especially by those reporting bugs. > > GNU Kind Communications Guidelines > https://www.gnu.org/philosophy/kind-communication.html
next prev parent reply other threads:[~2020-11-18 4:08 UTC|newest] Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-11-17 18:41 Boruch Baum 2020-11-17 19:51 ` Daniele Nicolodi 2020-11-17 20:15 ` Boruch Baum 2020-11-17 20:27 ` Daniele Nicolodi 2020-11-17 20:54 ` Boruch Baum 2020-11-17 21:36 ` Jean Louis 2020-11-17 23:42 ` Tim Cross 2020-11-18 4:04 ` Ihor Radchenko [this message] 2020-12-14 6:55 ` Bastien 2020-11-18 2:50 ` Pankaj Jangid 2020-11-18 3:59 ` Tim Cross 2020-11-18 6:44 ` Pankaj Jangid 2020-11-18 6:50 ` Jean Louis 2020-11-18 7:32 ` Tim Cross 2020-11-18 6:03 ` Jean Louis 2020-11-18 6:50 ` Pankaj Jangid 2020-12-14 7:14 ` Bastien
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style List information: https://www.orgmode.org/ * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=871rgrnwdk.fsf@localhost \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --subject='Re: Ignored bugs' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
Code repositories for project(s) associated with this inbox: https://git.savannah.gnu.org/cgit/emacs/org-mode.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).