Re: Ignored bugs

[Tim Cross <theophilusx@gmail.com>]

Jean Louis <bugs@gnu.support> writes:

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

I agree the bug submission functionality for Emacs needs revision. This
is something which really needs to be taken up on the emacs devel list.

It isn't just org-mode that is faced with this challenge. As Emacs moves
towards greater reliance on ELPA packages and with the addition of the
Non-GNU ELPA repository, this situation is only going to get worse.

M-x report-emacs-bug comes from a time when the majority of code was in
Emacs and any which was not was installed manually by the user. It was
clear to the user what was core and what they had installed. However,
things have moved on now. It isn't a clear to users anymore what is core
emacs and what is not - for them, it is all emacs. For example, I have
over 370 additional ELPA based packages in my configuration. Many are
from repositories other than the official GNU ELPA repository and have a
wide variety of approaches for issue tracking. I'm not sure that
existing M-x submit-emacs-bug is actually up to the task or if even the
Emacs bug tracker is. I suspect the current tracker receives bugs for
many packages which are from repositories like melpa. How are Emacs
developers supposed to manage such bugs (they don't necessarily know
where that package tracks issues or how to pass those issues on etc).

Things become even more complicated when it comes to org as there are
effectively two distinct user bases. You have those org users who just
use the version of org which is bundled with Emacs and those who prefer
to use the current release from org (either via the org repository or
MELPA). Essentially, org has to maintain two versions and bugs reported
in one version may not exist in the other (or more likely, have been
fixed in the older).

This is a very complex issue with many moving parts. Improvements are
likely to be incremental in small steps.

I do think we need to fix some information that is out there. When you
google org-mode bug tracking, you get the following link

https://orgmode.org/worg/org-issues.html

The information on that page is completely out of date. The link to the
bug tracking RSS feed gives a 504 error, the list of old issues are for
2013. This page should probably be removed or replaced with more current
information.

I'm assuming all org bugs are tracked in the Emacs bug tracker? All org
bugs should be tracked in a single repository. While submitting bugs via
this list is probably OK, there does need to be (and probably is?) a
mechanism to ensure they are also added to 'the' bug tracker. We need to
support those 'good' citizens who first try to determine if a bug is
known and then add to it rather than create another issue which is just
a repeat of a known issue. Likewise, we don't want people donating
valuable time resources working on a bug which has already been
resolved (particularly likely when you have two maintained versions).

--
Tim Cross