Re: [External] : [ELPA] Package cleanup

[Jimmy Aguilar Mena <jimmy.aguilar@bsc.es>]

On Wed, Mar 30, 2022 at 04:35:56AM -0400, Stefan Monnier wrote:
>> I would like to assume that ELPA is a somewhat curated
>> collection of packages.  Perhaps not as rigorously tested
>> and maintained as Emacs itself, but more so than some
>> package on github that has not seen an update in 5 years.
>
>That's not really the case, no :-(
>I do make sure the packages compile, and try occasionally to clean up
>the worst warnings, and when I make changes in Emacs I try to keep an
>eye on GNU ELPA packages to update them correspondingly, but I think I'm
>an exception in this regard.
>
>> If the only virtue of being on ELPA is that I can install via
>> package.el then that seems like rather thin gruel.
>
>The other is that there's a plan to include some of those packages into
>the standard Emacs tarball.
>
>> Perhaps the bar for admission to ELPA is too low.
>
>The main bar is for the package to be useful, harmless, and to have
>copyright.  I don't see a strong reason to make it much higher.
>
>> Could we require automated tests that can be run regularly to confirm
>> package health?
>
>That would be great.  But before requiring them, we need to setup a way
>to run the already existing tests.  Any help in this regard would be
>most welcome.
>
>
In this regard. There are some packages which main target is the
interaction, produce tarball, help menus etc... basically interactive
and dynamic work. We can test the internal functions but not the
external interaction and that's insufficient.

There is a package (not very active, but still functional BTW)
Cask+Ecukes... But the setup is not easy... Do we have something or is
there a way/plan to handle such test with internal functionalities?
Otherwise it may be pretty complex to demand/implement tests for those
packages.

>        Stefan
>