all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Liam Hupfer <liam@hpfr.net>
To: Cayetano Santos <csantosb@inventati.org>,
	Suhail Singh <suhailsingh247@gmail.com>
Cc: Guix-devel mailing list <guix-devel@gnu.org>,
	Mekeor Melire <mekeor@posteo.de>,
	Xinglu Chen <public@yoctocell.xyz>,
	74231@debbugs.gnu.org
Subject: [bug#74231] emacs-git-email: Guix policy for dealing with abandoned packages with active forks
Date: Sun, 10 Nov 2024 20:45:13 -0600	[thread overview]
Message-ID: <87ttce7akm.fsf@hpfr.net> (raw)
In-Reply-To: <87wmhfyq1a.fsf@inventati.org>

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

WARNING: multiple messages have this Message-ID (diff)
From: Liam Hupfer <liam@hpfr.net>
To: Cayetano Santos <csantosb@inventati.org>,
	Suhail Singh <suhailsingh247@gmail.com>
Cc: Guix-devel mailing list <guix-devel@gnu.org>,
	Mekeor Melire <mekeor@posteo.de>,
	Xinglu Chen <public@yoctocell.xyz>,
	74231@debbugs.gnu.org
Subject: Re: [bug#74231] emacs-git-email: Guix policy for dealing with abandoned packages with active forks
Date: Sun, 10 Nov 2024 20:45:13 -0600	[thread overview]
Message-ID: <87ttce7akm.fsf@hpfr.net> (raw)
Message-ID: <20241111024513.vtrL8sXRNQnJQL5yMK9bEXva4_VOCF0QqHNbCrkzXYQ@z> (raw)
In-Reply-To: <87wmhfyq1a.fsf@inventati.org>

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

  reply	other threads:[~2024-11-11  2:46 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-11-06 18:37 [bug#74231] [PATCH] gnu: emacs-git-email: Update to 0.5.0 Suhail Singh
2024-11-06 18:37 ` [bug#74231] [PATCH v2] gnu: emacs-git-email: Update to 0.6.0 Suhail Singh
2024-11-15  7:41   ` bug#74231: " Liliana Marie Prikler
2024-11-07 11:40 ` [bug#74231] QA review for 74231 Cayetano Santos via Guix-patches via
2024-11-07 13:32   ` Suhail Singh
2024-11-07 15:13     ` Cayetano Santos via Guix-patches via
2024-11-07 15:48       ` emacs-git-email: Guix policy for dealing with abandoned packages with active forks (was: [bug#74231] QA review for 74231) Suhail Singh
2024-11-07 16:08         ` emacs-git-email: Guix policy for dealing with abandoned packages with active forks Suhail Singh
2024-11-07 16:20         ` [bug#74231] " Cayetano Santos via Guix-patches via
2024-11-07 16:20           ` Cayetano Santos
2024-11-11  2:45           ` Liam Hupfer [this message]
2024-11-11  2:45             ` [bug#74231] " Liam Hupfer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87ttce7akm.fsf@hpfr.net \
    --to=liam@hpfr.net \
    --cc=74231@debbugs.gnu.org \
    --cc=csantosb@inventati.org \
    --cc=guix-devel@gnu.org \
    --cc=mekeor@posteo.de \
    --cc=public@yoctocell.xyz \
    --cc=suhailsingh247@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.