emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: bug archiving policy


From: Jean Louis
Subject: Re: bug archiving policy
Date: Thu, 10 Dec 2020 14:57:16 +0300
User-agent: Mutt/2.0 (3d08634) (2020-11-07)

* Bastien <bzg@gnu.org> [2020-12-10 14:11]:
> Jean Louis <bugs@gnu.support> writes:
> 
> > There is main Emacs bug tracking system and such shall accept
> > logically bugs that also relate to Org mode. To avoid
> > misunderstandings for people reading advises, it is maybe more useful
> > to say "while Org mode is part of Emacs there is also separate Org bug
> > tracking mailing list" and then to advise users there in gentle
> > manner. This is because not everybody can find that information
> > easily and maintainers will say that maybe Org is not part of Emacs
> > while it is part of Emacs thus confusing mostly new users.
> 
> I would like to introduce M-x report-org-bug as an alias to 
> M-x org-submit-bug-report
> 
> I think it would help enforce the policy of submitting Org bugs to
> emacs-orgmode@gnu.org first.

Good idea.

It will work only for those who know how to use M-x. Many people do
not know, and many will use menu and skip Org and use Help to report
bug.

So better idea would be that you harmonize both org and Emacs and just
have one function to report bug as by its meaning Org is part of
Emacs.

You can keep 2 menues as usual, but one function which would determine
if the bug is related to Org mode, or not, and forward bugs to Org
mode to different mailing list with a different template.

Something like:

If user is in Org mode, then to be asked:

  - is this Org mode bug?

then if no, to proceed to standard bug report.

If user is not in Org mode, then:

- Is this general Emacs bug? Yes

If user answers No:

- Is this Org mode bug? 

The message can be prepared depending of the bug and email address can
be changed appropriately.

Org menu reporting option would work as usual. Help report emacs bug
menu option could work by asking user those questions.

Think about harmonizing user interface and not splitting users over
development of one software between its modes.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]