emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Ihor Radchenko <yantar92@gmail.com>
To: Jean Louis <bugs@gnu.support>, Boruch Baum <boruch_baum@gmx.com>
Cc: Daniele Nicolodi <daniele@grinta.net>, emacs-orgmode@gnu.org
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:


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.


Jean Louis <bugs@gnu.support> writes:

> * Boruch Baum <boruch_baum@gmx.com> [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

  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:

  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 \
    --to=yantar92@gmail.com \
    --cc=boruch_baum@gmx.com \
    --cc=bugs@gnu.support \
    --cc=daniele@grinta.net \
    --cc=emacs-orgmode@gnu.org \
    --subject='Re: Ignored bugs' \


* 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:


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).