RE: [External] : [ELPA] Package cleanup

[Drew Adams]

> > > I have found some packages that doesn't even work or rely on some
> > > features that were obsoleted or removed.
> >
> > That's something entirely different.  Report such
> > specific problems.
> 
> 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.
> 
> If the only virtue of being on ELPA is that I can install via
> package.el then that seems like rather thin gruel.
> 
> Perhaps the bar for admission to ELPA is too low.  Could
> we require automated tests that can be run regularly to
> confirm package health?

Your last sentence makes sense.  (But on whom
should the requirement fall?  The curator?  The
package contributor?)

Certainly curation and periodic automated testing
would be good to have.  Such things could -- just
as someone reporting a problem encountered could
-- serve to get a package removed or fixed.

I would expect that the author of a package would
appreciate a report from such curation or testing,
and at least in some cases might implement a fix,
which presumably would be a better outcome than
just removal or deprecation.

I'd also expect that Emacs developers might want
to know, if some change in the "core" produced
unexpected problems in contributed packages.
IOW, such test reporting would benefit everyone.

But again, whether some package starts to result
in problems where it didn't previously doesn't
follow from its not having been updated for 5
years.  Similarly, it doesn't at all follow that
a package that's been updated a lot doesn't have
problems, including doesn't introduce new problems
from some recent update.

Bugs and curating/testing are different from the
question of update frequency or recentness.