unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Akib Azmain Turja <akib@disroot.org>
To: Tim Cross <theophilusx@gmail.com>, emacs-devel@gnu.org
Subject: Re: What to do about unmaintained ELPA packages
Date: Mon, 30 May 2022 17:14:00 +0600	[thread overview]
Message-ID: <87tu97p91j.fsf@disroot.org> (raw)
In-Reply-To: <877d642agm.fsf@gmail.com>

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

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

  reply	other threads:[~2022-05-30 11:14 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-29 21:34 What to do about unmaintained ELPA packages Philip Kaludercic
2022-05-29 21:41 ` Stefan Monnier
2022-05-29 21:54 ` Dmitry Gutov
2022-05-29 23:08   ` Tim Cross
2022-05-30 11:14     ` Akib Azmain Turja [this message]
2022-05-30  6:58   ` Philip Kaludercic
2022-05-30 13:45     ` Lars Ingebrigtsen
2022-05-30 14:46     ` João Távora
2022-05-30 22:51       ` Ergus
2022-05-30 23:04         ` João Távora
2022-05-31 16:42       ` Philip Kaludercic
2022-05-31 22:08         ` João Távora
2022-06-01  5:57           ` Bozhidar Batsov
2022-06-01 22:56             ` Richard Stallman
2022-05-30 22:53 ` Richard Stallman
2022-05-31 10:31   ` Akib Azmain Turja
2022-05-31 12:33     ` Stefan Monnier
2022-05-31 13:39       ` Akib Azmain Turja

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

  List information: https://www.gnu.org/software/emacs/

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

  git send-email \
    --in-reply-to=87tu97p91j.fsf@disroot.org \
    --to=akib@disroot.org \
    --cc=emacs-devel@gnu.org \
    --cc=theophilusx@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 public inbox

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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).