Ignored bugs

Ignored bugs

[Boruch Baum]

A little over a month ago, I submitted several bug reports related to
org-mode, and sor most of them haven't seen any action whatsoever, not
even an indication that they were noticed. In many cases, I provided
either a total solution or a suggested implementation of a solution.

BUG REPORT: 42484

+ This is of particular concern to me because when it was submitted it
  was summarily closed AND ANRCHIVED. When I complained, it was unarchived so
  that I could provide a solution and patch of my own, but it has since
  been archived AGAIN, so I can't submit an updated patch. Further, it
  was never removed from the closed state, so it could easily be
  overlooked. (Do I need to explicitly complain that this is awful
  management behavior?) So, I have an updated patch that I tried to
  submit a few minutes ago that was bounced because the thread is in
  read-only archived state.

BUG REPORT: 43954

BUG REPORT: 43955

+ code included

BUG REPORT: 44133

+ code included

--
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0

Re: Ignored bugs

[Daniele Nicolodi]

On 17/11/2020 19:41, Boruch Baum wrote:
> A little over a month ago, I submitted several bug reports related to
> org-mode, and sor most of them haven't seen any action whatsoever, not
> even an indication that they were noticed. In many cases, I provided
> either a total solution or a suggested implementation of a solution.
> 
> BUG REPORT: 42484

I haven't investigated further than reading this email, but the fact
that you are including what look like debbug numbers suggests that you
reported those bugs against Emacs.

Org is mostly developed outside Emacs and has an independent release
cycle. Emacs syncs irregularly with the latest released version of Org.

Bug report affecting the latest release of Org can be submitted to this
mailing list. This is also the best way to make them known to the Org
developers and maintainer. I don't think anyone here really looks into
bugs reported to the Emacs debbugs instance: time is limited and the
version of Org distributed with Emacs is very often not the most current
one, thus the bug reports may anyhow not be relevant anyhow.

I suggest you to try to reproduce these bugs with the latest Org release
(or the latest snapshot from Org ELPA) and report on this list if the
problems persist, see `org-submit-bug-report'.

Please complain with the Emacs maintainers about their handling of the
bugs on the Emacs bug tracking system, I don't think it a discussion
relevant to this mailing list.

Cheers,
Dan

Re: Ignored bugs

[Boruch Baum]

On 2020-11-17 20:51, Daniele Nicolodi wrote:
> Please complain with the Emacs maintainers about their handling of the
> bugs on the Emacs bug tracking system,

How do I know it was "their handling" and not "your handling"? It's
unclear from my view of the thread who performed the actions but all the
other actions on that thread were from a fellow called "Bastien" - is he
one of "theirs" or one of "yours" (or both)?

In any event, it should be of concern to people on this list to make
contributing to org-mode as open and hurdle-free as possible instead of
piling on supplemental demands / requirements. As a case study, you
can review the submissions that I referenced and the elisp content there
that seems would have gone lost had I not taken the extra steps of
engaging on this list. Who knows how many other contributions and
contributors you've "lost" this way...

--
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0

Re: Ignored bugs

[Daniele Nicolodi]

On 17/11/2020 21:15, Boruch Baum wrote:
> On 2020-11-17 20:51, Daniele Nicolodi wrote:
>> Please complain with the Emacs maintainers about their handling of the
>> bugs on the Emacs bug tracking system,
> 
> How do I know it was "their handling" and not "your handling"? It's
> unclear from my view of the thread who performed the actions but all the
> other actions on that thread were from a fellow called "Bastien" - is he
> one of "theirs" or one of "yours" (or both)?
> 
> In any event, it should be of concern to people on this list to make
> contributing to org-mode as open and hurdle-free as possible instead of
> piling on supplemental demands / requirements. As a case study, you
> can review the submissions that I referenced and the elisp content there
> that seems would have gone lost had I not taken the extra steps of
> engaging on this list. Who knows how many other contributions and
> contributors you've "lost" this way...

The page that introduces the Emacs bug tracker already reports that this
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.

I went and read the exchange on bug #42484 and already Bastien told you
that this mailing list is the right place where to report bugs and
submit patches.

You are deliberately ignoring these instructions. What do you expect?

Would you like to elaborate on why making it easy for you to contribute
something to org-mode that solves your problems should be of concerns to
the people of this list, especialy if this comes at extra cost to them?

Cheers,
Dan

Re: Ignored bugs

[Boruch Baum]

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.

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 went and read the exchange on bug #42484 and already Bastien told you
> that this mailing list is the right place where to report bugs and
> submit patches.

Lost that, as probably have others. Ultimately, it's your choice to make
your eco-system friendly or not, convenient or not, considerate or not.


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

> Would you like to elaborate on why making it easy for you to contribute
> something to org-mode that solves your problems should be of concerns to
> the people of this list, especialy if this comes at extra cost to them?

That is such a classic and revealing paragraph you wrote about yourself!
Maybe paste it on your bathroom mirror and read over every once in a while.
Maybe publicize that paragraph as a policy document for the project?

> Cheers,

Not.

--
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0

Re: Ignored bugs

[Jean Louis]

* 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

Re: Ignored bugs

[Tim Cross]

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

Re: Ignored bugs

[Pankaj Jangid]

Daniele Nicolodi <daniele@grinta.net> writes:

> On 17/11/2020 19:41, Boruch Baum wrote:
>> A little over a month ago, I submitted several bug reports related to
>> org-mode, and sor most of them haven't seen any action whatsoever, not
>> even an indication that they were noticed. In many cases, I provided
>> either a total solution or a suggested implementation of a solution.
>> 
>> BUG REPORT: 42484
>
> I haven't investigated further than reading this email, but the fact
> that you are including what look like debbug numbers suggests that you
> reported those bugs against Emacs.
>
> Org is mostly developed outside Emacs and has an independent release
> cycle. Emacs syncs irregularly with the latest released version of Org.

I was completely unaware of this. I also used to report bugs via emacs'
report-emacs-bug fascility.

Moreover, I am building emacs from `master' everyday and assuming
everything is latest on this. If Org is a different beast then probably
we should do two things:

1. Remove Org from built-in packages and distribute only via ELPA

2. And have a completely separate infrastructure for development,
mailing-lists, bug reports. This we already have. But we should follow
convention so that it is easier for user to report-org-bugs.

> Bug report affecting the latest release of Org can be submitted to this
> mailing list. This is also the best way to make them known to the Org
> developers and maintainer.

I don't know how the tracking works if bugs are reported in a mailing
list.

> I don't think anyone here really looks into
> bugs reported to the Emacs debbugs instance: time is limited and the
> version of Org distributed with Emacs is very often not the most current
> one, thus the bug reports may anyhow not be relevant anyhow.
>
> I suggest you to try to reproduce these bugs with the latest Org release
> (or the latest snapshot from Org ELPA) and report on this list if the
> problems persist, see `org-submit-bug-report'.

I am trying to use `use-package' for package management via the init
file. And when I do (use-package org :ensure t) it doesn't install the
latest. It uses the builtin package only. Is this a bug in emacs,
use-package or elpa?

Re: Ignored bugs

[Tim Cross]

Pankaj Jangid <pankaj@codeisgreat.org> writes:

> Daniele Nicolodi <daniele@grinta.net> writes:
>
>> On 17/11/2020 19:41, Boruch Baum wrote:
>>> A little over a month ago, I submitted several bug reports related to
>>> org-mode, and sor most of them haven't seen any action whatsoever, not
>>> even an indication that they were noticed. In many cases, I provided
>>> either a total solution or a suggested implementation of a solution.
>>>
>>> BUG REPORT: 42484
>>
>> I haven't investigated further than reading this email, but the fact
>> that you are including what look like debbug numbers suggests that you
>> reported those bugs against Emacs.
>>
>> Org is mostly developed outside Emacs and has an independent release
>> cycle. Emacs syncs irregularly with the latest released version of Org.
>
> I was completely unaware of this. I also used to report bugs via emacs'
> report-emacs-bug fascility.
>
> Moreover, I am building emacs from `master' everyday and assuming
> everything is latest on this. If Org is a different beast then probably
> we should do two things:
>
> 1. Remove Org from built-in packages and distribute only via ELPA
>
> 2. And have a completely separate infrastructure for development,
> mailing-lists, bug reports. This we already have. But we should follow
> convention so that it is easier for user to report-org-bugs.
>

Org mode is now an official part of Emacs, so that boat has sailed.

If we wanted to have only one official version, it would have to be the
one bundled with Emacs (or in the ELPA repository I think?). However,
that would also slow down the releases to fit with the GNU Emacs release
policy. When I last built Emacs 28 (9th Nov), org was still at 9.3.
Latest version taken from org repository is 9.4

While org development is on-going, most of the changes are refinements
rather than new features. For most people, there will be little
functional difference between 9.3 and 9.4. I started using the org repo
version ages ago, when there were features in the latest version not in
the bundled version. If I was starting again from now, I would be
tempted to stick with the built-in version and prioritise stability over
bleeding edge.

>> Bug report affecting the latest release of Org can be submitted to this
>> mailing list. This is also the best way to make them known to the Org
>> developers and maintainer.
>
> I don't know how the tracking works if bugs are reported in a mailing
> list.
>
>> I don't think anyone here really looks into
>> bugs reported to the Emacs debbugs instance: time is limited and the
>> version of Org distributed with Emacs is very often not the most current
>> one, thus the bug reports may anyhow not be relevant anyhow.
>>
>> I suggest you to try to reproduce these bugs with the latest Org release
>> (or the latest snapshot from Org ELPA) and report on this list if the
>> problems persist, see `org-submit-bug-report'.
>
> I am trying to use `use-package' for package management via the init
> file. And when I do (use-package org :ensure t) it doesn't install the
> latest. It uses the builtin package only. Is this a bug in emacs,
> use-package or elpa?

Not a bug at all. You have to configure your emacs to obtain the latest
version from the org (or MELPA?) repository.

If you really want the most recent org version, you need to add the org
ELPA repository to your packages.el repository list. I have the
following in my setup -

(add-to-list 'package-archives `("melpa" . "https://melpa.org/packages/"))
(add-to-list 'package-archives '("org" . "http://orgmode.org/elpa/"))

If you also want to get the org-plus-contrib version and your using
'use-package', you need something like

(use-package org
    :ensure org-plus-contrib
    ....)

because the package is 'org' but is in org-plus-contrib (there is also
just an 'org' package that does not include all the contrib libs).

Note that it is CRITICAL that the code to load the org package is run
*before* any org functionality is loaded. If you fail to do this, you
will end up with a mixed (and broken) environment where some of the
version bundled with emacs is loaded and some which is part of the newer
version is loaded. Provided nothing has loaded any org stuff before the
use-package stanza for org is run, everything will be OK. For this
reason, it is good to load the package early (first) in case other
packages you load try to load org etc).


--
Tim Cross

Re: Ignored bugs

[Ihor Radchenko]

> 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://orgmode.org/list/87zhfntkwm.fsf@gmail.com/
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 <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

Re: Ignored bugs

[Jean Louis]

* Pankaj Jangid <pankaj@codeisgreat.org> [2020-11-18 05:51]:
> Daniele Nicolodi <daniele@grinta.net> writes:
> 
> > On 17/11/2020 19:41, Boruch Baum wrote:
> >> A little over a month ago, I submitted several bug reports related to
> >> org-mode, and sor most of them haven't seen any action whatsoever, not
> >> even an indication that they were noticed. In many cases, I provided
> >> either a total solution or a suggested implementation of a solution.
> >> 
> >> BUG REPORT: 42484
> >
> > I haven't investigated further than reading this email, but the fact
> > that you are including what look like debbug numbers suggests that you
> > reported those bugs against Emacs.
> >
> > Org is mostly developed outside Emacs and has an independent release
> > cycle. Emacs syncs irregularly with the latest released version of Org.
> 
> I was completely unaware of this. I also used to report bugs via emacs'
> report-emacs-bug fascility.
> 
> Moreover, I am building emacs from `master' everyday and assuming
> everything is latest on this. If Org is a different beast then probably
> we should do two things:
> 
> 1. Remove Org from built-in packages and distribute only via ELPA

No, please that would be detrimental. Please note how many users use
Org who do not have Internet or possibility to update Org. Don't
forget that Emacs run on multi user computers.

Please see example here of who is using Debian GNU/Linux:
https://www.debian.org/users/

I hope you may see many educational institutions and understand that
not every computer may be connected to Internet but many will be used
by multiple users.

> 2. And have a completely separate infrastructure for development,
> mailing-lists, bug reports. This we already have. But we should follow
> convention so that it is easier for user to report-org-bugs.

As long as M-x report-emacs-bug is watched out for Org mode and
handled properly and users nicely and considerately transitioned to
Org mailing list (warmly welcomed), there is no serious problem
there. 

> > I don't think anyone here really looks into bugs reported to the
> > Emacs debbugs instance: time is limited and the version of Org
> > distributed with Emacs is very often not the most current one,
> > thus the bug reports may anyhow not be relevant anyhow.

Those who do not have time, do not have.

There are those who do have time and who will help users.

Re: Ignored bugs

[Pankaj Jangid]

Tim Cross <theophilusx@gmail.com> writes:

>> I am trying to use `use-package' for package management via the init
>> file. And when I do (use-package org :ensure t) it doesn't install the
>> latest. It uses the builtin package only. Is this a bug in emacs,
>> use-package or elpa?
>
> Not a bug at all. You have to configure your emacs to obtain the latest
> version from the org (or MELPA?) repository.
>
> If you really want the most recent org version, you need to add the org
> ELPA repository to your packages.el repository list. I have the
> following in my setup -
>
> (add-to-list 'package-archives `("melpa" . "https://melpa.org/packages/"))
> (add-to-list 'package-archives '("org" . "http://orgmode.org/elpa/"))

Okay. I don't have org-elpa in my list. But Org 9.4 is visible in the
`gnu' archive. I have this in my configuration

(custom-set-variables
 '(package-archives '(("melpa" . "https://melpa.org/packages/")
                      ("gnu"   . "https://elpa.gnu.org/packages/"))))

When I install it manually via package-install it gets installed. But
(use-package org :ensure t) doesn't install it. Probably the order is
affecting it.

Re: Ignored bugs

[Pankaj Jangid]

Jean Louis <bugs@gnu.support> writes:

>> I was completely unaware of this. I also used to report bugs via
>> emacs' report-emacs-bug fascility.
>> 
>> Moreover, I am building emacs from `master' everyday and assuming
>> everything is latest on this. If Org is a different beast then
>> probably we should do two things:
>> 
>> 1. Remove Org from built-in packages and distribute only via ELPA
>
> No, please that would be detrimental. Please note how many users use
> Org who do not have Internet or possibility to update Org. Don't
> forget that Emacs run on multi user computers.
>
> Please see example here of who is using Debian GNU/Linux:
> https://www.debian.org/users/
> 
> I hope you may see many educational institutions and understand that
> not every computer may be connected to Internet but many will be used
> by multiple users.

I completely agree with you. It is important to ship Org along with
Emacs. I was replying to the thought process that insists that org
cannot follow the emacs process. Which was kind of a setback to me.

>> > I don't think anyone here really looks into bugs reported to the
>> > Emacs debbugs instance: time is limited and the version of Org
>> > distributed with Emacs is very often not the most current one, thus
>> > the bug reports may anyhow not be relevant anyhow.
>
> Those who do not have time, do not have.
>
> There are those who do have time and who will help users.

Yes. This one. Like it.

Re: Ignored bugs

[Jean Louis]

* Pankaj Jangid <pankaj@codeisgreat.org> [2020-11-18 09:47]:
> Tim Cross <theophilusx@gmail.com> writes:
> 
> >> I am trying to use `use-package' for package management via the init
> >> file. And when I do (use-package org :ensure t) it doesn't install the
> >> latest. It uses the builtin package only. Is this a bug in emacs,
> >> use-package or elpa?
> >
> > Not a bug at all. You have to configure your emacs to obtain the latest
> > version from the org (or MELPA?) repository.
> >
> > If you really want the most recent org version, you need to add the org
> > ELPA repository to your packages.el repository list. I have the
> > following in my setup -
> >
> > (add-to-list 'package-archives `("melpa" . "https://melpa.org/packages/"))
> > (add-to-list 'package-archives '("org" . "http://orgmode.org/elpa/"))
> 
> Okay. I don't have org-elpa in my list. But Org 9.4 is visible in the
> `gnu' archive. I have this in my configuration
> 
> (custom-set-variables
>  '(package-archives '(("melpa" . "https://melpa.org/packages/")
>                       ("gnu"   . "https://elpa.gnu.org/packages/"))))
> 
> When I install it manually via package-install it gets installed. But
> (use-package org :ensure t) doesn't install it. Probably the order is
> affecting it.

You may try by using Org ELPA:

("org" . "https://orgmode.org/elpa/")

Re: Ignored bugs

[Tim Cross]

Pankaj Jangid <pankaj@codeisgreat.org> writes:

> Tim Cross <theophilusx@gmail.com> writes:
>
>>> I am trying to use `use-package' for package management via the init
>>> file. And when I do (use-package org :ensure t) it doesn't install the
>>> latest. It uses the builtin package only. Is this a bug in emacs,
>>> use-package or elpa?
>>
>> Not a bug at all. You have to configure your emacs to obtain the latest
>> version from the org (or MELPA?) repository.
>>
>> If you really want the most recent org version, you need to add the org
>> ELPA repository to your packages.el repository list. I have the
>> following in my setup -
>>
>> (add-to-list 'package-archives `("melpa" . "https://melpa.org/packages/"))
>> (add-to-list 'package-archives '("org" . "http://orgmode.org/elpa/"))
>
> Okay. I don't have org-elpa in my list. But Org 9.4 is visible in the
> `gnu' archive. I have this in my configuration
>
> (custom-set-variables
>  '(package-archives '(("melpa" . "https://melpa.org/packages/")
>                       ("gnu"   . "https://elpa.gnu.org/packages/"))))
>
> When I install it manually via package-install it gets installed. But
> (use-package org :ensure t) doesn't install it. Probably the order is
> affecting it.

Have a look at the package.el docs. You can 'pin' a package to a
specific repository and version and you can set repository priorities. I
would also check to see when the custom section is actually loaded. It
could be that your customization is not loaded until after your call to
use-package. As I call add-to-lis and that adds entries to the start of
the list, I know both melpa and the org repositories are before the gnu
one and as I do this in my init file, I know it is processed before the
call to use-package, but I also set repository priorities to help
protect against reliance on order in the list.

My full package config is below. Note that things changed in Emacs 27
and I'm not 100% sure it is correct (actually, I recently switched to
using spacemacs, so I don't use that setup anymore!)

#+begin_src emacs-lisp :tangle tangle-init.el
  (require 'package)

  (setq package-enable-at-startup nil
        package-archive-priorities '(("org" . 2) ("melpa" . 1) ("gnu" . 0)))

  (add-to-list 'package-archives `("melpa" . "https://melpa.org/packages/"))
  (add-to-list 'package-archives '("org" . "http://orgmode.org/elpa/"))
  (when (< emacs-major-version 27)
    (package-initialize))

#+end_src

--
Tim Cross

Re: Ignored bugs

[Bastien]

Hi Boruch,

Boruch Baum <boruch_baum@gmx.com> writes:

>> Would you like to elaborate on why making it easy for you to contribute
>> something to org-mode that solves your problems should be of concerns to
>> the people of this list, especialy if this comes at extra cost to them?
>
> That is such a classic and revealing paragraph you wrote about yourself!
> Maybe paste it on your bathroom mirror and read over every once in a while.
> Maybe publicize that paragraph as a policy document for the project?
>
>> Cheers,
>
> Not.

The tone of your answer sounded harsh.  You may have your reasons to
be upset, but please let's try our best to avoid such tone.

You may want to read the GNU Kind Communication Guidelines:
https://www.gnu.org/philosophy/kind-communication.html

I re-read them from time to time, they convey useful hints on how to
have constructive conversations.

Best,

-- 
 Bastien

Re: Ignored bugs

[Bastien]

Hi Boruch,

Boruch Baum <boruch_baum@gmx.com> writes:

> BUG REPORT: 42484
>
> + This is of particular concern to me because when it was submitted it
>   was summarily closed AND ANRCHIVED. When I complained, it was unarchived so
>   that I could provide a solution and patch of my own, but it has since
>   been archived AGAIN, so I can't submit an updated patch. Further, it
>   was never removed from the closed state, so it could easily be
>   overlooked. (Do I need to explicitly complain that this is awful
>   management behavior?) So, I have an updated patch that I tried to
>   submit a few minutes ago that was bounced because the thread is in
>   read-only archived state.

I'm not convinced this should be in Org's core.

I think it could be in https://orgmode.org/worg/org-hacks.html

You can send a patch against https://code.orgmode.org/bzg/worg/ or
ask for an account on https://code.orgmode.org to be able to write
directly to Worg.

> BUG REPORT: 43954

Please use report-emacs-bug for bugs only.

For such suggestions, please discuss them on this list.

> BUG REPORT: 43955
>
> + code included

It looks like 43955 is a better version of 43954.

> BUG REPORT: 44133
>
> + code included

The patch seems interesting.  Can you resend it on this list in a
dedicated thread?  Also, you need to format it as described here:
https://orgmode.org/worg/org-contribute.html

Thanks,

-- 
 Bastien