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

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>