Hunting the culprit package

Hunting the culprit package

[Pankaj Jangid]

I am trying to find out which package inside my ~/.emacs.d/elpa is the
culprit. One of the packages is introducing a bug. I know this because
when I move my ~/.emacs.d/elpa directory and launch emacs without any
packages installed then it works fine.

Also, when I install all the packages afresh, then also emacs works fine
i.e. a freshly created ~/.emacs.d/elpa is *not* creating any issue. So
something is wrong in my old ~/.emacs.d/elpa. So I tried to figure out
what is happening in my old ~/.emacs.d/elpa directory.

Before that I restored my old ~/.emacs.d/elpa and upgraded all the
packages to latest. And then compared old an new directories using "diff
-r". Strangely, the diff output is 900+ lines.

My question is that - why there is a difference? I have refreshed all
the packages in old ~/.emacs.d/elpa directory and comparing it with a
freshly created ~/.emacs.d/elpa. And the difference is not in cache
etc. "diff -r" is clearly showing differences in source files. Sample,

--8<---------------cut here---------------start------------->8---
diff -r elpa/dash-20220608.1931/dash-autoloads.el elnew/dash-20220608.1931/dash-autoloads.el
42c42
< (fn &optional ARG)" t nil)
---
> (fn &optional ARG)" t)
66c66
< (fn &optional ARG)" t nil)
---
> (fn &optional ARG)" t)
69c69
< This allows Dash symbols to be looked up with \\[info-lookup-symbol]." t nil)
---
> This allows Dash symbols to be looked up with \\[info-lookup-symbol]." t)

...


diff -r elpa/yaml-mode-20220104.1503/yaml-mode-pkg.el elnew/yaml-mode-20220104.1503/yaml-mode-pkg.el
2c2
< (define-package "yaml-mode" "20220104.1503" "Major mode for editing YAML files" '((emacs "24.1")) :commit "535273d5a1eb76999d20afbcf4d9f056d8ffd2da" :authors '(("Yoshiki Kurihara" . "clouder@gmail.com") ("Marshall T. Vandegrift" . "llasram@gmail.com")) :maintainer '("Vasilij Schneidermann" . "mail@vasilij.de") :keywords '("data" "yaml") :url "https://github.com/yoshiki/yaml-mode")
---
> (define-package "yaml-mode" "20220104.1503" "Major mode for editing YAML files" '((emacs "24.1")) :commit "a79d2a7b9281f8c56f461d717b1ba40fc58e22fd" :authors '(("Yoshiki Kurihara" . "clouder@gmail.com") ("Marshall T. Vandegrift" . "llasram@gmail.com")) :maintainer '("Vasilij Schneidermann" . "mail@vasilij.de") :keywords '("data" "yaml") :url "https://github.com/yoshiki/yaml-mode")
--8<---------------cut here---------------end--------------->8---

Also, if this is not the correct way to approach then how to find which
the old package that was creating the issue. This is in addition to my
earlier question - why there are differences between refreshed upgraded
packages and packages installed from scratch.

All clues will help.

Regards
Pankaj

Re: Hunting the culprit package

[Stefan Monnier]

> Also, when I install all the packages afresh, then also emacs works fine
> i.e. a freshly created ~/.emacs.d/elpa is *not* creating any issue.  So
> something is wrong in my old ~/.emacs.d/elpa.  So I tried to figure out
> what is happening in my old ~/.emacs.d/elpa directory.

In my experience, the problem in such circumstances is most of the time
a file that was miscompiled for some reason.

> --8<---------------cut here---------------start------------->8---
> diff -r elpa/dash-20220608.1931/dash-autoloads.el elnew/dash-20220608.1931/dash-autoloads.el
> 42c42
> < (fn &optional ARG)" t nil)
> ---
>> (fn &optional ARG)" t)
> 66c66
> < (fn &optional ARG)" t nil)
> ---
>> (fn &optional ARG)" t)
> 69c69
> < This allows Dash symbols to be looked up with \\[info-lookup-symbol]." t nil)
> ---
>> This allows Dash symbols to be looked up with \\[info-lookup-symbol]." t)

Changes to `<PKG>-autoloads.el` are normal: those files are generated
locally during the package's installation, so they can be different
depending on the version of Emacs used to install the package.
The above differences should have no impact since they just add/remove
explicit nil values for optional arguments.

> diff -r elpa/yaml-mode-20220104.1503/yaml-mode-pkg.el elnew/yaml-mode-20220104.1503/yaml-mode-pkg.el
> 2c2
> < (define-package "yaml-mode" "20220104.1503" "Major mode for editing YAML
> files" '((emacs "24.1")) :commit
> "535273d5a1eb76999d20afbcf4d9f056d8ffd2da" :authors '(("Yoshiki Kurihara"
> . "clouder@gmail.com") ("Marshall T. Vandegrift"
> . "llasram@gmail.com")) :maintainer '("Vasilij Schneidermann"
> . "mail@vasilij.de") :keywords '("data" "yaml") :url
> "https://github.com/yoshiki/yaml-mode")
> ---
>> (define-package "yaml-mode" "20220104.1503" "Major mode for editing YAML
>> files" '((emacs "24.1")) :commit
>> "a79d2a7b9281f8c56f461d717b1ba40fc58e22fd" :authors '(("Yoshiki Kurihara"
>> . "clouder@gmail.com") ("Marshall T. Vandegrift"
>> . "llasram@gmail.com")) :maintainer '("Vasilij Schneidermann"
>> . "mail@vasilij.de") :keywords '("data" "yaml") :url
>> "https://github.com/yoshiki/yaml-mode")
> --8<---------------cut here---------------end--------------->8---

This is not expected: the `<PGK>-pkg.el` files are not generated
locally, they come straight from the tarballs (i.e. they're generated
once and for all when the tarball is created).  This said, this is
a MELPA package and it may be that MELPA re-builds all its tarballs "all
the time", so it's possible that the `yaml-mode-20220104.1503` from
a month ago holds a different `<PKG>-pkg.el` than the
`yaml-mode-20220104.1503` from today if the scripts used to build that
tarball have changed in-between.
NOTE: I said "may be", because I don't know whether it's the case
or not.  On `elpa.(non)gnu.org` tarballs are not *re*built, so for
(Non)GNU ELPA packages this should never happen.

> Also, if this is not the correct way to approach then how to find which
> the old package that was creating the issue.

Do the usual debugging from the details of issue itself, walking our way
back to its source?


        Stefan

Re: Hunting the culprit package

[Pankaj Jangid]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> In my experience, the problem in such circumstances is most of the time
> a file that was miscompiled for some reason.
>

Probably something like this happened.

> NOTE: I said "may be", because I don't know whether it's the case
> or not.  On `elpa.(non)gnu.org` tarballs are not *re*built, so for
> (Non)GNU ELPA packages this should never happen.

Makes sense.

>> Also, if this is not the correct way to approach then how to find which
>> the old package that was creating the issue.
>
> Do the usual debugging from the details of issue itself, walking our way
> back to its source?

I noted this first in magit; so I reported there as well. I was informed
that uninstalling "compat" and "magit" and then reinstalling "magit" and
then restarting Emacs could solve the issue.

This did the trick.

Because magit is hooked into so many places, every part of Emacs was
giving some error. For example, pressing RET on an info node was also
not working.

An external package can cause so much damage. Can this be prevented?

Re: Hunting the culprit package

[Stefan Monnier]

> Because magit is hooked into so many places, every part of Emacs was
> giving some error. For example, pressing RET on an info node was also
> not working.
>
> An external package can cause so much damage. Can this be prevented?

:-)

Emacs tries to make a lot of things possible.  It also tries to prevent
bad things, but it tends to be pretty conservative in this respect since
the two goals are in conflict.

To the extent that your problem prevented you from using Emacs but
did not make you lose work (presumably), then I'd consider that the
efforts we make to "prevent bad things" were successful.
Maybe not a resounding success, admittedly.


        Stefan

Re: Hunting the culprit package

[T.V Raman]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=gb18030, Size: 1046 bytes --]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

I disagreethat we were not a "resounding" success; 

1. We were successful as you pointed out.
2. We were still making noise -- so that meets the "resounding" bar.
>> Because magit is hooked into so many places, every part of Emacs was
>> giving some error. For example, pressing RET on an info node was also
>> not working.
>>
>> An external package can cause so much damage. Can this be prevented?
>
> :-)
>
> Emacs tries to make a lot of things possible.  It also tries to prevent
> bad things, but it tends to be pretty conservative in this respect since
> the two goals are in conflict.
>
> To the extent that your problem prevented you from using Emacs but
> did not make you lose work (presumably), then I'd consider that the
> efforts we make to "prevent bad things" were successful.
> Maybe not a resounding success, admittedly.
>
>
>         Stefan
>
>

-- 

Thanks,

--Raman(I Search, I Find, I Misplace, I Research)
7©4 Id: kg:/m/0285kf1  •0Ü8

Magit

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

What is the situation with preparing to include Magit in Emacs?

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Magit

[Akib Azmain Turja]

[-- Attachment #1: Type: text/plain, Size: 723 bytes --]

Richard Stallman <rms@gnu.org> writes:

> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
> What is the situation with preparing to include Magit in Emacs?

I don't think that will ever happen.  Magit has many contributors, and
many of them hasn't completed the paperwork.  So including Magit in
Emacs would be pretty hard (if possible)?

-- 
Akib Azmain Turja

Find me on Mastodon at @akib@hostux.social.

This message is signed by me with my GnuPG key.  Its fingerprint is:

    7001 8CE5 819F 17A3 BBA6  66AF E74F 0EFA 922A E7F5

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: Magit

[Stefan Monnier]

Akib Azmain Turja [2022-09-03 12:29:08] wrote:
> Richard Stallman <rms@gnu.org> writes:
>> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
>> [[[ whether defending the US Constitution against all enemies,     ]]]
>> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>>
>> What is the situation with preparing to include Magit in Emacs?
>
> I don't think that will ever happen.  Magit has many contributors, and
> many of them hasn't completed the paperwork.  So including Magit in
> Emacs would be pretty hard (if possible)?

Actually, in a sense it's pretty easy: just make an exception for the
rule that all code needs to have its copyright assigned to the FSF.

Whether we want to make such an exception here of course is
another question.

But even if we do make such an exception, having a copy of Magit in
`emacs.git` would add extra maintenance burden to keep that copy in sync
with the one maintained elsewhere.  So for administrative reasons, it's
probably preferable to keep it outside of `emacs.git`.


        Stefan

Re: Magit

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Richard Stallman <rms@gnu.org>,  emacs-devel@gnu.org
> Date: Sat, 03 Sep 2022 10:20:23 -0400
> 
> But even if we do make such an exception, having a copy of Magit in
> `emacs.git` would add extra maintenance burden to keep that copy in sync
> with the one maintained elsewhere.  So for administrative reasons, it's
> probably preferable to keep it outside of `emacs.git`.

We've decided long ago that whenever it will be possible, we'll add
Magit to Emacs.

Re: Magit

[Akib Azmain Turja]

[-- Attachment #1: Type: text/plain, Size: 829 bytes --]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Stefan Monnier <monnier@iro.umontreal.ca>
>> Cc: Richard Stallman <rms@gnu.org>,  emacs-devel@gnu.org
>> Date: Sat, 03 Sep 2022 10:20:23 -0400
>> 
>> But even if we do make such an exception, having a copy of Magit in
>> `emacs.git` would add extra maintenance burden to keep that copy in sync
>> with the one maintained elsewhere.  So for administrative reasons, it's
>> probably preferable to keep it outside of `emacs.git`.
>
> We've decided long ago that whenever it will be possible, we'll add
> Magit to Emacs.

What about VC?  Why people don't use it much?

-- 
Akib Azmain Turja

Find me on Mastodon at @akib@hostux.social.

This message is signed by me with my GnuPG key.  Its fingerprint is:

    7001 8CE5 819F 17A3 BBA6  66AF E74F 0EFA 922A E7F5

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: Magit

[Eli Zaretskii]

> From: Akib Azmain Turja <akib@disroot.org>
> Cc: Stefan Monnier <monnier@iro.umontreal.ca>,  rms@gnu.org,
>   emacs-devel@gnu.org
> Date: Sun, 04 Sep 2022 00:22:43 +0600
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > We've decided long ago that whenever it will be possible, we'll add
> > Magit to Emacs.
> 
> What about VC?  Why people don't use it much?

People do use VC quite a lot.

Re: Magit

[Akib Azmain Turja]

[-- Attachment #1: Type: text/plain, Size: 747 bytes --]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Akib Azmain Turja <akib@disroot.org>
>> Cc: Stefan Monnier <monnier@iro.umontreal.ca>,  rms@gnu.org,
>>   emacs-devel@gnu.org
>> Date: Sun, 04 Sep 2022 00:22:43 +0600
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> > We've decided long ago that whenever it will be possible, we'll add
>> > Magit to Emacs.
>> 
>> What about VC?  Why people don't use it much?
>
> People do use VC quite a lot.

Maybe my wordings were not clear.  I meant - why people don't talk about
VC much?

-- 
Akib Azmain Turja

Find me on Mastodon at @akib@hostux.social.

This message is signed by me with my GnuPG key.  Its fingerprint is:

    7001 8CE5 819F 17A3 BBA6  66AF E74F 0EFA 922A E7F5

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: Magit

[Eli Zaretskii]

> From: Akib Azmain Turja <akib@disroot.org>
> Cc: monnier@iro.umontreal.ca,  rms@gnu.org,  emacs-devel@gnu.org
> Date: Sun, 04 Sep 2022 08:47:13 +0600
> 
> >> What about VC?  Why people don't use it much?
> >
> > People do use VC quite a lot.
> 
> Maybe my wordings were not clear.  I meant - why people don't talk about
> VC much?

Why do you say that?  VC is discussed here quite a lot, and the rate
of changes committed to VC files is also quite high.

Re: Magit

[Stefan Kangas]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> Actually, in a sense it's pretty easy: just make an exception for the
> rule that all code needs to have its copyright assigned to the FSF.

Sounds good to me, FWIW.

> But even if we do make such an exception, having a copy of Magit in
> `emacs.git` would add extra maintenance burden to keep that copy in sync
> with the one maintained elsewhere.  So for administrative reasons, it's
> probably preferable to keep it outside of `emacs.git`.

I'm not sure I understand the objection.  Is it not just a question of
popping something like this in a shell script that runs every N days:

  git clone <MAGIT-URL> magit
  cp magit/*.el lisp/magit
  rm -rf magit
  git commit -a -m "; Auto-update Magit"
  git push

If we want to be a bit more conservative, we have code in NonGNU ELPA to
check out the latest tagged package version.

Re: Magit

[Akib Azmain Turja]

[-- Attachment #1: Type: text/plain, Size: 1729 bytes --]

Stefan Kangas <stefankangas@gmail.com> writes:

> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
>> Actually, in a sense it's pretty easy: just make an exception for the
>> rule that all code needs to have its copyright assigned to the FSF.
>
> Sounds good to me, FWIW.
>
>> But even if we do make such an exception, having a copy of Magit in
>> `emacs.git` would add extra maintenance burden to keep that copy in sync
>> with the one maintained elsewhere.  So for administrative reasons, it's
>> probably preferable to keep it outside of `emacs.git`.
>
> I'm not sure I understand the objection.  Is it not just a question of
> popping something like this in a shell script that runs every N days:
>
>   git clone <MAGIT-URL> magit
>   cp magit/*.el lisp/magit
>   rm -rf magit
>   git commit -a -m "; Auto-update Magit"
>   git push

Yeah, I also think it isn't a too big problem.  I also think we should
take the portable packages (i.e. the packages which don't depend on
Emacs internals, e.g. term, artist, comint (maybe), doctor) out of the
main Emacs repository and make them available through GNU ELPA (while
still keeping a copy in main Emacs repository).  That way Emacs 28.1
users (and possibly Emacs 27.2 users) will get the latest updates to
those packages.

>
> If we want to be a bit more conservative, we have code in NonGNU ELPA to
> check out the latest tagged package version.

The last time I checked, the Magit version hosted on NonGNU ELPA was
completely broken.

-- 
Akib Azmain Turja

Find me on Mastodon at @akib@hostux.social.

This message is signed by me with my GnuPG key.  Its fingerprint is:

    7001 8CE5 819F 17A3 BBA6  66AF E74F 0EFA 922A E7F5

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Magit broken in NonGNU ELPA

[Stefan Kangas]

Akib Azmain Turja <akib@disroot.org> writes:

> The last time I checked, the Magit version hosted on NonGNU ELPA was
> completely broken.

Did you report it as a bug?

(Copying in the Magit maintainer Jonas Bernoulli.)

Re: Magit

[Philip Kaludercic]

Akib Azmain Turja <akib@disroot.org> writes:

> Stefan Kangas <stefankangas@gmail.com> writes:
>
>> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>>
>>> Actually, in a sense it's pretty easy: just make an exception for the
>>> rule that all code needs to have its copyright assigned to the FSF.
>>
>> Sounds good to me, FWIW.
>>
>>> But even if we do make such an exception, having a copy of Magit in
>>> `emacs.git` would add extra maintenance burden to keep that copy in sync
>>> with the one maintained elsewhere.  So for administrative reasons, it's
>>> probably preferable to keep it outside of `emacs.git`.
>>
>> I'm not sure I understand the objection.  Is it not just a question of
>> popping something like this in a shell script that runs every N days:
>>
>>   git clone <MAGIT-URL> magit
>>   cp magit/*.el lisp/magit
>>   rm -rf magit
>>   git commit -a -m "; Auto-update Magit"
>>   git push
>
> Yeah, I also think it isn't a too big problem.  I also think we should
> take the portable packages (i.e. the packages which don't depend on
> Emacs internals, e.g. term, artist, comint (maybe), doctor) out of the
> main Emacs repository and make them available through GNU ELPA (while
> still keeping a copy in main Emacs repository).  That way Emacs 28.1
> users (and possibly Emacs 27.2 users) will get the latest updates to
> those packages.
>
>>
>> If we want to be a bit more conservative, we have code in NonGNU ELPA to
>> check out the latest tagged package version.
>
> The last time I checked, the Magit version hosted on NonGNU ELPA was
> completely broken.

I've been using the version from NonGNU ELPA since it has been added
(last year), and there haven't been any issues.

Re: Magit

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

What arrangements did we make to update the version of Magit in NonGNU
ELPA?  Are those arrangements being carried out?
-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Magit

[Philip Kaludercic]

Richard Stallman <rms@gnu.org> writes:

> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
> What arrangements did we make to update the version of Magit in NonGNU
> ELPA?  Are those arrangements being carried out?

As is the default for NonGNU ELPA, the Magit repository is automatically
synchronised and mirrored.  Whenever the version tag in the package
header is bumped, a new version is released.

Re: Magit

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > > What arrangements did we make to update the version of Magit in NonGNU
  > > ELPA?  Are those arrangements being carried out?

  > As is the default for NonGNU ELPA, the Magit repository is automatically
  > synchronised and mirrored.  Whenever the version tag in the package
  > header is bumped, a new version is released.

That's normally a good way -- but then I wonder, how was it that a
user found a significant difference between the behavior of the Magit
in NonGNU ELPA and the one on another repo?

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Magit

[Phil Sainty]

On 2022-09-07 14:19, Richard Stallman wrote:
>   > As is the default for NonGNU ELPA, the Magit repository is 
> automatically
>   > synchronised and mirrored.  Whenever the version tag in the package
>   > header is bumped, a new version is released.
> 
> That's normally a good way -- but then I wonder, how was it that a
> user found a significant difference between the behavior of the Magit
> in NonGNU ELPA and the one on another repo?

That user would most likely have installed Magit from the MELPA
archive, which tracks the unstable development of every package
-- each time MELPA sees a change to a source repository, it builds
a new release of that package.

GNU ELPA and NonGNU ELPA, conversely, provide new releases only
when they observe that the package maintainer updated the version
string -- commits made between those version updates do not result
in a new release.

(Which of these two approaches provides the "best" version of
any given package at any given time might vary, of course.)


-Phil

Re: Magit

[Stefan Monnier]

> That's normally a good way -- but then I wonder, how was it that a
> user found a significant difference between the behavior of the Magit
> in NonGNU ELPA and the one on another repo?

You'll first have to ask him to see if what he saw has anything to do
with what he claimed or if it was some random other effect.


        Stefan

Re: Magit

[Akib Azmain Turja]

[-- Attachment #1: Type: text/plain, Size: 635 bytes --]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> That's normally a good way -- but then I wonder, how was it that a
>> user found a significant difference between the behavior of the Magit
>> in NonGNU ELPA and the one on another repo?
>
> You'll first have to ask him to see if what he saw has anything to do
> with what he claimed or if it was some random other effect.
>
>
>         Stefan
>
>

It works now!

-- 
Akib Azmain Turja

Find me on Mastodon at @akib@hostux.social.

This message is signed by me with my GnuPG key.  Its fingerprint is:

    7001 8CE5 819F 17A3 BBA6  66AF E74F 0EFA 922A E7F5

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: Magit

[Stefan Monnier]

>> But even if we do make such an exception, having a copy of Magit in
>> `emacs.git` would add extra maintenance burden to keep that copy in sync
>> with the one maintained elsewhere.  So for administrative reasons, it's
>> probably preferable to keep it outside of `emacs.git`.
>
> I'm not sure I understand the objection.  Is it not just a question of
> popping something like this in a shell script that runs every N days:
>
>   git clone <MAGIT-URL> magit
>   cp magit/*.el lisp/magit
>   rm -rf magit
>   git commit -a -m "; Auto-update Magit"
>   git push

People can (and do) commit changes directly to `emacs.git`s `master`
branch and the above would silently revert such changes.  It also means
that the Magit files in `emacs.git` don't get a proper commit log
history, making it harder to track down and fix bugs.

I'm all for including more packages in Emacs, but not by copying them
into the `master` branch `emacs.git`.  I'd rather have a Git submodule
or some such mechanism.


        Stefan

Re: Magit

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > I don't think that will ever happen.  Magit has many contributors, and
  > many of them hasn't completed the paperwork.

Talking with them about this is not impossible.  It just takes work.

Would someone like to volunteer to work on this?

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Magit

[Philip Kaludercic]

Richard Stallman <rms@gnu.org> writes:

> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
>   > I don't think that will ever happen.  Magit has many contributors, and
>   > many of them hasn't completed the paperwork.
>
> Talking with them about this is not impossible.  It just takes work.

Magit itself has 315 contributors of which approximately 70-90 have
significant contributions by my estimate.  There are certainly a few
that have already signed the CA, but there are plenty that have done so
either a long while ago and would not be difficult to contact.  And
with this many people there are always plenty who are disinterested or
actively hostile towards assigning their copyright, which is always an
unpleasant situation.

It might not be "impossible" in the literal sense of the word, but that
doesn't make it much easier either.

> Would someone like to volunteer to work on this?

Re: Magit

[Eli Zaretskii]

> From: Philip Kaludercic <philipk@posteo.net>
> Cc: Akib Azmain Turja <akib@disroot.org>,  emacs-devel@gnu.org
> Date: Mon, 05 Sep 2022 09:04:23 +0000
> 
> Richard Stallman <rms@gnu.org> writes:
> 
> >   > I don't think that will ever happen.  Magit has many contributors, and
> >   > many of them hasn't completed the paperwork.
> >
> > Talking with them about this is not impossible.  It just takes work.
> 
> Magit itself has 315 contributors of which approximately 70-90 have
> significant contributions by my estimate.  There are certainly a few
> that have already signed the CA, but there are plenty that have done so
> either a long while ago and would not be difficult to contact.  And
> with this many people there are always plenty who are disinterested or
> actively hostile towards assigning their copyright, which is always an
> unpleasant situation.
> 
> It might not be "impossible" in the literal sense of the word, but that
> doesn't make it much easier either.

AFAIK, the job of getting this done, however formidable, was already
under way.  Jonas described its progress on several occasions.

Re: Magit

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > of which approximately 70-90 have
  > significant contributions by my estimate.

It's a substantial job, but not enormous.  We can do it.
Could we have a few volunteers to divide up the job?

Then we need to find out from Jonas Bernoulli the status
of contacting those people -- who we need to contact.



-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)