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

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

[Suhail Singh]

* 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

diff --git a/gnu/local.mk b/gnu/local.mk
index 945d89d550..90ef82204d 100644
--- a/gnu/local.mk
+++ b/gnu/local.mk
@@ -1186,7 +1186,6 @@ dist_patch_DATA =						\
   %D%/packages/patches/emacs-disable-jit-compilation.patch			\
   %D%/packages/patches/emacs-exec-path.patch			\
   %D%/packages/patches/emacs-fix-scheme-indent-function.patch	\
-  %D%/packages/patches/emacs-git-email-missing-parens.patch	\
   %D%/packages/patches/emacs-helpful-fix-tests.patch	\
   %D%/packages/patches/emacs-highlight-stages-add-gexp.patch	\
   %D%/packages/patches/emacs-json-reformat-fix-tests.patch	\
diff --git a/gnu/packages/emacs-xyz.scm b/gnu/packages/emacs-xyz.scm
index 59c804066a..57ae548a3b 100644
--- a/gnu/packages/emacs-xyz.scm
+++ b/gnu/packages/emacs-xyz.scm
@@ -22159,44 +22159,31 @@ (define-public emacs-gitpatch
     (license license:gpl3+)))
 
 (define-public emacs-git-email
-  ;; Use latest commit since latest tagged release is missing important
-  ;; changes.
-  (let ((commit "b5ebade3a48dc0ce0c85699f25800808233c73be")
-        (revision "0"))
-    (package
-      (name "emacs-git-email")
-      (version (git-version "0.2.0" revision commit))
-      (source
-       (origin
-         (method git-fetch)
-         (uri (git-reference
-               (url "https://git.sr.ht/~yoctocell/git-email")
-               (commit commit)))
-         (patches
-          (search-patches "emacs-git-email-missing-parens.patch"))
-         (file-name (git-file-name name version))
-         (sha256
-          (base32 "1lk1yds7idgawnair8l3s72rgjmh80qmy4kl5wrnqvpmjrmdgvnx"))))
-      (build-system emacs-build-system)
-      (arguments
-       `(#:phases
-         (modify-phases %standard-phases
-           ;; piem is not yet packaged in Guix.
-           (add-after 'unpack 'remove-piem
-             (lambda _
-               (delete-file "git-email-piem.el")))
-           (add-before 'install 'makeinfo
-             (lambda _
-               (invoke "makeinfo" "doc/git-email.texi"))))))
-      (native-inputs
-       (list texinfo))
-      (propagated-inputs
-       (list mu emacs-magit emacs-notmuch))
-      (license license:gpl3+)
-      (home-page "https://sr.ht/~yoctocell/git-email")
-      (synopsis "Format and send Git patches in Emacs")
-      (description "This package provides utilities for formatting and
-sending Git patches via Email, without leaving Emacs."))))
+  (package
+    (name "emacs-git-email")
+    (version "0.5.0")
+    (source
+     (origin
+       (method git-fetch)
+       (uri (git-reference
+             (url "https://codeberg.org/suhail/git-email")
+             (commit version)))
+       (file-name (git-file-name name version))
+       (sha256
+        (base32 "0q70k0pn0dkbrcsah0hcwxa2c3f8aw89bbds5k2dslacn93ghws7"))))
+    (build-system emacs-build-system)
+    (arguments
+     `(#:phases (modify-phases %standard-phases
+                  (add-before 'install 'makeinfo
+                    (lambda _
+                      (invoke "makeinfo" "doc/git-email.texi"))))))
+    (inputs (list mu emacs-magit emacs-notmuch emacs-piem))
+    (native-inputs (list texinfo))
+    (license license:gpl3+)
+    (home-page "https://suhail.codeberg.page/git-email")
+    (synopsis "Format and send Git patches in Emacs")
+    (description "This package provides utilities for formatting and
+sending Git patches via Email, without leaving Emacs.")))
 
 (define-public emacs-erc-hl-nicks
   (package
diff --git a/gnu/packages/patches/emacs-git-email-missing-parens.patch b/gnu/packages/patches/emacs-git-email-missing-parens.patch
deleted file mode 100644
index 051e2bf1eb..0000000000
--- a/gnu/packages/patches/emacs-git-email-missing-parens.patch
+++ /dev/null
@@ -1,27 +0,0 @@
-From 820ad7eb2e919e3f880bec22bd4f737fa55c4d22 Mon Sep 17 00:00:00 2001
-From: Niklas Eklund <niklas.eklund@posteo.net>
-Date: Thu, 5 May 2022 12:43:49 +0200
-Subject: [PATCH] Fix missing parens in git-email-mu4e.el
-
-The incorrect number of parens in this file lead to Emacs failing to
-parse the file.
----
- git-email-mu4e.el | 2 +-
- 1 file changed, 1 insertion(+), 1 deletion(-)
-
-diff --git a/git-email-mu4e.el b/git-email-mu4e.el
-index d5b8770..9220bf9 100644
---- a/git-email-mu4e.el
-+++ b/git-email-mu4e.el
-@@ -51,7 +51,7 @@ from Lisp, enable the mode if ARG is omitted or nil."
-                ;; built in context feature.
-                (seq-filter (lambda (header)
-                              (not (eq (car header) 'from)))
--                           headers)
-+                           headers))))
-     (setq git-email-compose-email-function 'message-mail)))
- 
- (provide 'git-email-mu4e)
--- 
-2.34.0
-

base-commit: ba9466481d10992d35f09d010166d616fdb6a637

[bug#74231] [PATCH v2] gnu: emacs-git-email: Update to 0.6.0.

[Suhail Singh]

* gnu/packages/emacs-xyz.scm (emacs-git-email): Update to 0.6.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

diff --git a/gnu/local.mk b/gnu/local.mk
index 1f48fddc9e..88b3bc8ffb 100644
--- a/gnu/local.mk
+++ b/gnu/local.mk
@@ -1188,7 +1188,6 @@ dist_patch_DATA =						\
   %D%/packages/patches/emacs-disable-jit-compilation.patch			\
   %D%/packages/patches/emacs-exec-path.patch			\
   %D%/packages/patches/emacs-fix-scheme-indent-function.patch	\
-  %D%/packages/patches/emacs-git-email-missing-parens.patch	\
   %D%/packages/patches/emacs-helpful-fix-tests.patch	\
   %D%/packages/patches/emacs-highlight-stages-add-gexp.patch	\
   %D%/packages/patches/emacs-json-reformat-fix-tests.patch	\
diff --git a/gnu/packages/emacs-xyz.scm b/gnu/packages/emacs-xyz.scm
index b3517b7bd9..b8eb4b6b1a 100644
--- a/gnu/packages/emacs-xyz.scm
+++ b/gnu/packages/emacs-xyz.scm
@@ -22186,44 +22186,31 @@ (define-public emacs-gitpatch
     (license license:gpl3+)))
 
 (define-public emacs-git-email
-  ;; Use latest commit since latest tagged release is missing important
-  ;; changes.
-  (let ((commit "b5ebade3a48dc0ce0c85699f25800808233c73be")
-        (revision "0"))
-    (package
-      (name "emacs-git-email")
-      (version (git-version "0.2.0" revision commit))
-      (source
-       (origin
-         (method git-fetch)
-         (uri (git-reference
-               (url "https://git.sr.ht/~yoctocell/git-email")
-               (commit commit)))
-         (patches
-          (search-patches "emacs-git-email-missing-parens.patch"))
-         (file-name (git-file-name name version))
-         (sha256
-          (base32 "1lk1yds7idgawnair8l3s72rgjmh80qmy4kl5wrnqvpmjrmdgvnx"))))
-      (build-system emacs-build-system)
-      (arguments
-       `(#:phases
-         (modify-phases %standard-phases
-           ;; piem is not yet packaged in Guix.
-           (add-after 'unpack 'remove-piem
-             (lambda _
-               (delete-file "git-email-piem.el")))
-           (add-before 'install 'makeinfo
-             (lambda _
-               (invoke "makeinfo" "doc/git-email.texi"))))))
-      (native-inputs
-       (list texinfo))
-      (propagated-inputs
-       (list mu emacs-magit emacs-notmuch))
-      (license license:gpl3+)
-      (home-page "https://sr.ht/~yoctocell/git-email")
-      (synopsis "Format and send Git patches in Emacs")
-      (description "This package provides utilities for formatting and
-sending Git patches via Email, without leaving Emacs."))))
+  (package
+    (name "emacs-git-email")
+    (version "0.6.0")
+    (source
+     (origin
+       (method git-fetch)
+       (uri (git-reference
+             (url "https://codeberg.org/suhail/git-email")
+             (commit version)))
+       (file-name (git-file-name name version))
+       (sha256
+        (base32 "1cx6a4dxvdggnjn95a9fhcidd1140srpzw9lx9hi65kancnyjsci"))))
+    (build-system emacs-build-system)
+    (arguments
+     `(#:phases (modify-phases %standard-phases
+                  (add-before 'install 'makeinfo
+                    (lambda _
+                      (invoke "makeinfo" "doc/git-email.texi"))))))
+    (inputs (list mu emacs-magit emacs-notmuch emacs-piem))
+    (native-inputs (list texinfo))
+    (license license:gpl3+)
+    (home-page "https://suhail.codeberg.page/git-email")
+    (synopsis "Format and send Git patches in Emacs")
+    (description "This package provides utilities for formatting and
+sending Git patches via Email, without leaving Emacs.")))
 
 (define-public emacs-erc-hl-nicks
   (package
diff --git a/gnu/packages/patches/emacs-git-email-missing-parens.patch b/gnu/packages/patches/emacs-git-email-missing-parens.patch
deleted file mode 100644
index 051e2bf1eb..0000000000
--- a/gnu/packages/patches/emacs-git-email-missing-parens.patch
+++ /dev/null
@@ -1,27 +0,0 @@
-From 820ad7eb2e919e3f880bec22bd4f737fa55c4d22 Mon Sep 17 00:00:00 2001
-From: Niklas Eklund <niklas.eklund@posteo.net>
-Date: Thu, 5 May 2022 12:43:49 +0200
-Subject: [PATCH] Fix missing parens in git-email-mu4e.el
-
-The incorrect number of parens in this file lead to Emacs failing to
-parse the file.
----
- git-email-mu4e.el | 2 +-
- 1 file changed, 1 insertion(+), 1 deletion(-)
-
-diff --git a/git-email-mu4e.el b/git-email-mu4e.el
-index d5b8770..9220bf9 100644
---- a/git-email-mu4e.el
-+++ b/git-email-mu4e.el
-@@ -51,7 +51,7 @@ from Lisp, enable the mode if ARG is omitted or nil."
-                ;; built in context feature.
-                (seq-filter (lambda (header)
-                              (not (eq (car header) 'from)))
--                           headers)
-+                           headers))))
-     (setq git-email-compose-email-function 'message-mail)))
- 
- (provide 'git-email-mu4e)
--- 
-2.34.0
-

base-commit: 07cd046c209f192032b425d2ee44f6025bff63a1

bug#74231: [PATCH v2] gnu: emacs-git-email: Update to 0.6.0.

[Liliana Marie Prikler]

Am Mittwoch, dem 06.11.2024 um 13:37 -0500 schrieb Suhail Singh:
> * gnu/packages/emacs-xyz.scm (emacs-git-email): Update to 0.6.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
Reworded and pushed.

Thanks

[bug#74231] QA review for 74231

[Cayetano Santos via Guix-patches via]

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

[bug#74231] QA review for 74231

[Suhail Singh]

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,
-- 
Suhail

[bug#74231] QA review for 74231

[Cayetano Santos via Guix-patches via]

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

emacs-git-email: Guix policy for dealing with abandoned packages with active forks (was: [bug#74231] QA review for 74231)

[Suhail Singh]

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>

-- 
Suhail

Re: emacs-git-email: Guix policy for dealing with abandoned packages with active forks

[Suhail Singh]

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,
-- 
Suhail

[bug#74231] emacs-git-email: Guix policy for dealing with abandoned packages with active forks

[Cayetano Santos via Guix-patches via]

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

Re: emacs-git-email: Guix policy for dealing with abandoned packages with active forks

[Cayetano Santos]

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

[bug#74231] emacs-git-email: Guix policy for dealing with abandoned packages with active forks

[Liam Hupfer]

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

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>

Re: [bug#74231] emacs-git-email: Guix policy for dealing with abandoned packages with active forks

[Liam Hupfer]

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

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>