[bug#74231] gnu: emacs-git-email: Update to 0.5.0.

* gnu/packages/emacs-xyz.scm (emacs-git-email): Update to 0.5.0 on actively
maintained fork.  Update homepage.  Add emacs-piem as a build-time dependency.
Don't propagate mu, emacs-magit, and emacs-notmuch since they are optional.
* gnu/local.mk (dist_patch_DATA): Delete emacs-git-email-missing-parens.patch,
since it's no longer needed.
* gnu/packages/patches/emacs-git-email-missing-parens.patch: Delete
unnecessary patch.

Change-Id: I47f5aa12cfa676772e281a45cdc9ec3bb3eae544
---
 gnu/local.mk                                  |  1 -
 gnu/packages/emacs-xyz.scm                    | 63 ++++++++-----------
 .../emacs-git-email-missing-parens.patch      | 27 --------
 3 files changed, 25 insertions(+), 66 deletions(-)
 delete mode 100644 gnu/packages/patches/emacs-git-email-missing-parens.patch


base-commit: ba9466481d10992d35f09d010166d616fdb6a637

user guix
usertag 74231 + waiting-on-contributor
thanks

Guix QA review form submission:

"The Elisp dependencies of Emacs packages are typically provided as
propagated-inputs when required at run time."

See: https://guix.gnu.org/manual/en/html_node/Emacs-Packages.html.

To note that this is a completely different beast compared to previous
package (repo, version and mantainer).

Items marked as checked:

- Commit messages
- Package builds
- Lint warnings
- Package style
- Dependent packages build

Cayetano Santos via Guix-patches via <guix-patches@gnu.org> writes:

> "The Elisp dependencies of Emacs packages are typically provided as
> propagated-inputs when required at run time."
>
> See: https://guix.gnu.org/manual/en/html_node/Emacs-Packages.html.

Yes, please note however, that the dependencies in question were
entirely optional.  The package doesn't have any "required" Elisp
dependencies with the version of Emacs packaged in Guix.  More
importantly, for some of these optional dependencies a user would only
ever want to use one of them at a time (since it's intimately tied to
their personal workflow and MUA etc.).

> To note that this is a completely different beast compared to previous
> package (repo, version and mantainer).

Yes.  Please let me know in case the commit message needs to be revised
(it already does note that we are changing the referenced fork).  The
previous fork hasn't been updated in a couple of years and had a number
of bugs that have since been resolved in the updated fork.

Regards,

>jeu. 07 nov. 2024 at 08:32, Suhail Singh <suhailsingh247@gmail.com> wrote:

> Cayetano Santos via Guix-patches via <guix-patches@gnu.org> writes:
>
>> "The Elisp dependencies of Emacs packages are typically provided as
>> propagated-inputs when required at run time."
>>
>> See: https://guix.gnu.org/manual/en/html_node/Emacs-Packages.html.
>
> Yes, please note however, that the dependencies in question were
> entirely optional.  The package doesn't have any "required" Elisp
> dependencies with the version of Emacs packaged in Guix.  More
> importantly, for some of these optional dependencies a user would only
> ever want to use one of them at a time (since it's intimately tied to
> their personal workflow and MUA etc.).

Fine with me, then.

>> To note that this is a completely different beast compared to previous
>> package (repo, version and mantainer).
>
> Yes.  Please let me know in case the commit message needs to be revised
> (it already does note that we are changing the referenced fork).  The
> previous fork hasn't been updated in a couple of years and had a number
> of bugs that have since been resolved in the updated fork.

To me, the open question goes well beyond this package.

Does guix package forks of code from a couple of years ago, without an
explicit acknowledgement between maintainers ? Additionally, this is a
second generation fork ...

I’d say, better bring the question to guix-devel, as this has large
implications. There must be a policy already around this point.

C.

Cayetano Santos <csantosb@inventati.org> writes:

>>> To note that this is a completely different beast compared to previous
>>> package (repo, version and mantainer).
>>
>> Yes.  Please let me know in case the commit message needs to be revised
>> (it already does note that we are changing the referenced fork).  The
>> previous fork hasn't been updated in a couple of years and had a number
>> of bugs that have since been resolved in the updated fork.
>
> To me, the open question goes well beyond this package.
>
> Does guix package forks of code from a couple of years ago, without an
> explicit acknowledgement between maintainers ?

The maintainer has not been active on their own mailing list
(<https://lists.sr.ht/~yoctocell/git-email-devel>) for a while despite
repeated discussions about outstanding issues ([1], [2]).  I believe it
would be fair to characterize the original package as having been
abandoned.

I'm CC-ing Xinglu Chen (the original author) to this email for
transparency.

> Additionally, this is a second generation fork ...

I am not sure I understand what you mean by "second generation" in this
regard.  Could you please elaborate?

If you're referring to the fact that it used another contributor's
(Mekeor) fork as a starting point, then for context please note that the
decision to treat my fork as "upstream" was in discussion with them
(since Mekeor's no longer actively using the package).

I'm CC-ing Mekeor to this message for transparency.

> I’d say, better bring the question to guix-devel, as this has large
> implications. There must be a policy already around this point.

I'm CC-ing guix-devel.


[1]: <https://lists.sr.ht/~yoctocell/git-email-devel/%3C87wn1zlhfq.fsf@posteo.de%3E>

[2]: <https://lists.sr.ht/~yoctocell/git-email-devel/%3Ccc4a1b8b-9a1d-46cf-9b04-466c85ebcd44@riseup.net%3E>

Hello Guix,

Below is a summary of the situation that we're seeking guidance on.
Please ignore this message, if already aware of context.

Suhail Singh <suhailsingh247@gmail.com> writes:

>> I’d say, better bring the question to guix-devel, as this has large
>> implications. There must be a policy already around this point.
>
> I'm CC-ing guix-devel.
>
> [1]: <https://lists.sr.ht/~yoctocell/git-email-devel/%3C87wn1zlhfq.fsf@posteo.de%3E>
>
> [2]: <https://lists.sr.ht/~yoctocell/git-email-devel/%3Ccc4a1b8b-9a1d-46cf-9b04-466c85ebcd44@riseup.net%3E>

In issue #74231 I submitted a patch to update emacs-git-email.  The
patch changes the notion of "upstream" for the emacs-git-email package.

The current package definition in Guix points to the original
implementation.  However, for the last couple of years that project has
received no updates.  Importantly, there has been no response from the
original author regarding offers to take over or help with
maintainership during the same period (see [1] and [2] above).  All this
while the original package had some critical bugs (including, but not
limited to, missing parentheses).

I have, since recently, started actively using (and developing) the
package and incorporated all existing patches as well as added some
additional functionality.

In situations such as these:

1. Is it okay to update the package to point to an actively maintained
   fork?

2. Are there some necessary pre-requisites that have to be fulfilled
   before 1 can be done?  If so, have they been fulfilled?  If not,
   could the outstanding items be noted?

Regards,

>jeu. 07 nov. 2024 at 10:48, Suhail Singh <suhailsingh247@gmail.com> wrote:

> Cayetano Santos <csantosb@inventati.org> writes:
>
>>>> To note that this is a completely different beast compared to previous
>>>> package (repo, version and mantainer).
>>>
>>> Yes.  Please let me know in case the commit message needs to be revised
>>> (it already does note that we are changing the referenced fork).  The
>>> previous fork hasn't been updated in a couple of years and had a number
>>> of bugs that have since been resolved in the updated fork.
>>
>> To me, the open question goes well beyond this package.
>>
>> Does guix package forks of code from a couple of years ago, without an
>> explicit acknowledgement between maintainers ?
>
> The maintainer has not been active on their own mailing list
> (<https://lists.sr.ht/~yoctocell/git-email-devel>) for a while despite
> repeated discussions about outstanding issues ([1], [2]).  I believe it
> would be fair to characterize the original package as having been
> abandoned.
>
> I'm CC-ing Xinglu Chen (the original author) to this email for
> transparency.
>
>> Additionally, this is a second generation fork ...
>
> I am not sure I understand what you mean by "second generation" in this
> regard.  Could you please elaborate?
>
> If you're referring to the fact that it used another contributor's
> (Mekeor) fork as a starting point, then for context please note that the
> decision to treat my fork as "upstream" was in discussion with them
> (since Mekeor's no longer actively using the package).
>
> I'm CC-ing Mekeor to this message for transparency.

Yes, this is what I refer to.

>> I’d say, better bring the question to guix-devel, as this has large
>> implications. There must be a policy already around this point.
>
> I'm CC-ing guix-devel.

Thanks !

I’m just curious about whether guix has a policy concerning this kind of
situation, before reviewing your patch (#74231), as there might have
consequences in the most general case. Namely, it is the case of
patching a package definition, redirecting its source url to a fork by
the patch’s author.

Is that acceptable or a risk ? Is it up to the committer to evaluate,
once being warned ? Something more explicit ?

C.

Cayetano Santos via Guix-patches via <guix-patches@gnu.org> writes:

> I’m just curious about whether guix has a policy concerning this kind of
> situation, before reviewing your patch (#74231), as there might have
> consequences in the most general case. Namely, it is the case of
> patching a package definition, redirecting its source url to a fork by
> the patch’s author.
>
> Is that acceptable or a risk ? Is it up to the committer to evaluate,
> once being warned ? Something more explicit ?

Changing origins is inevitable sometimes. I don’t think there’s a formal
process; it’s more of a matter of judgment on a case-by-case basis. The
[general guidelines on consensus-based decision making] certainly apply.

In this case, it seems the original maintainer has been absent for
several years, there are active requests for a fork (see [any takers for
a fork? — sourcehut lists]), and Suhail has made [substantial tidying] over
several weeks. Given these circumstances, and Suhail’s [established
presence] as a contributor, the fact that he is both the author of the
patch and the fork is not concerning to me.

So +1 from me (as a user of the Guix package) for what it’s worth.

—Liam


[general guidelines on consensus-based decision making] <https://guix.gnu.org/manual/devel/en/html_node/Making-Decisions.html>

[any takers for
a fork? — sourcehut lists] <https://lists.sr.ht/~yoctocell/git-email-devel/%3Ccc4a1b8b-9a1d-46cf-9b04-466c85ebcd44@riseup.net%3E>

[substantial tidying] <https://codeberg.org/suhail/git-email/compare/c0211fa61289fe799cb9c83a8478736fd977793f...0.5.0>

[established
presence] <https://yhetil.org/guix/?q=f%3Asuhail>