Re: What to do about unmaintained ELPA packages

[Akib Azmain Turja]

Tim Cross <theophilusx@gmail.com> writes:

> Dmitry Gutov <dgutov@yandex.ru> writes:
>
>> On 30.05.2022 00:34, Philip Kaludercic wrote:
>>> There are some popular packages on GNU ELPA (and I expect NonGNU ELPA)
>>> that are practically unmaintained.  One example would be Yasnippet that
>>> has been gathering issues and pull requests on GitHub, mostly without
>>> any comments whatsoever.  For example, see
>>> https://github.com/joaotavora/yasnippet/issues.  Does anyone know of any
>>> other packages of this kind?
>>
>> Talking about yasnippet in particular, it more in the "stable" rather than
>> "bitrotten" category, so I wouldn't worry about it too much.
>>
>> Or definitely not resort to measures like removing the reference to the
>> upstream.
>>
>>> I'd like to ask, if there some point at which should one should go from
>>> regarding packages like these from "de facto unmaintained" to "actually
>>> abandoned"?  Perhaps if there was no real activity for over a year,
>>> despite constant contributions?  Would it make sense to call for anyone
>>> new to take over maintaining the package?  Or depending on how long the
>>> package has been unmaintained, how popular the package is, how much
>>> effort it would take to apply the changes one could modify the package
>>> in elpa.git/nongnu.git and inform the maintainers that if they decide to
>>> start working on the package again, that there are downstream changes
>>> that they should look at.
>>
>> Personally, carrying over the development on ELPA would seem 
>> counter-productive.
>> Both due to the reduced potential community of contributors and reporters, 
>> and
>> because of the wealth of reports, discussions and docs that reside at the
>> currently dormant upstream. Kinda passive-aggressive, too.
>>
>> I think the best step right now would be to try to contact Noah and ask to 
>> share
>> commit access. And if not Noah, then Joao -- he's definitely still around.
>
>
> I would agree. First step is to try contacting the repository owner. I
> notice in the case of yasnippets, they are active in other projects, so
> there may be a good reason none of the issues or PRs are getting action
> in that repo. 

I agree.  If the maintainer doesn't respond then we can think about
taking any other step.

>
> I'm not sure there is a 'one size fits all' answer here. We probably
> need to look at each case individually. 

That right, because each case differs and has something unique.

>
> I do think both ELPA and non-GNU ELPA would likely benefit from some
> statistic showing number of weekly/monthly downloads and/or possibly
> some heuristic quality metric i.e. number of open issues, whether the
> package has a test suite, number of compiler warnings, days since last
> update etc. While none of these are likely sufficient metrics on their
> own, perhaps a combination could be useful as an indicator. 

Yeah, these will help users to make a better choice.  Although compiler
warnings count and time since last update can be easily calculated, how
can we check a package has a test suite?  And how can we figure out the
number of open issues (or whatever)?  That would need to use many APIs
like GitHub API, GitLab API, Gitea API.  I would also suggest showing
the license of a package (for NonGNU only, as all ELPA packages are
GPL).

By the way, is it OK to use Expat (or MIT) license for elisp packages?

>
> One unfortunate tendency in the current climate is to consider anything
> which has not had an update in some time to be abandoned. However, it
> could simply be it has reached a stable point of maturity where fewer
> updates are necessary or critical enough. 
>

That's exactly me!  I start writing package, and when I have implemented
everything I want, I just put it aside, until I think it needs attention
(either because I or someone else found a bug or because I would like to
add another feature).

-- 
Akib Azmain Turja

This message is signed by me with my GnuPG key.  It's fingerprint is:

    7001 8CE5 819F 17A3 BBA6  66AF E74F 0EFA 922A E7F5

signature.asc
Description: PGP signature