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

[Cayetano Santos via Guix-patches via <guix-patches@gnu.org>]

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