[ELPA] Package cleanup

[ELPA] Package cleanup

[Jimmy Aguilar Mena]

Hi:

Just a question. Did you finally agreed about the package
obsoletion/removal procedure for ELPA?

It seems there are some packages there which haven't received any update
in a very long time (>5 years).  Maybe there is a way to put them is a
sort of obsolete/archived/unmaintained state... In order to keep them,
but at least not confuse the new users, or wrongly suggest to use them.

I have found some packages that doesn't even work or rely on some
features that were obsoleted or removed.

Best,
Ergus.

RE: [External] : [ELPA] Package cleanup

[Drew Adams]

> It seems there are some packages there which haven't received any
> update in a very long time (>5 years).  Maybe there is a way to
> put them is a sort of obsolete/archived/unmaintained state...
> In order to keep them, but at least not confuse the new users,
> or wrongly suggest to use them.

Some cars need to go to the mechanic every month,
which makes sense for them.  Some don't.  Some
people need to go to the doctor often; others
don't.

Why should Emacs assume that no change to a
package means the package is not being maintained
(let alone is obsolete)?

> 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.

Re: [External] : [ELPA] Package cleanup

[John Yates]

On Tue, Mar 29, 2022 at 12:25 PM Drew Adams <drew.adams@oracle.com> wrote:

> > 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?

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.

Re: [External] : [ELPA] Package cleanup

[John Yates]

On Tue, Mar 29, 2022 at 6:05 PM Drew Adams <drew.adams@oracle.com> wrote:

> 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.

Full agreement.  Same holds true for a package on github.
Lack of update is merely a vague proxy for abandoned.  And,
as you point out, abandonment does not imply non-functional.

But if there is no mechanism to, at least, identify decay then,
over time, the ratio of high quality packages to those of lesser
quality drops.  Not a great recipe for brand maintenance.

RE: [External] : [ELPA] Package cleanup

[Drew Adams]

> But if there is no mechanism to, at least, identify decay then,
> over time, the ratio of high quality packages to those of lesser
> quality drops.  Not a great recipe for brand maintenance.

1. FWIW, I disagree that that ratio matters, except
possibly for discoverability.  And nowadays there are
zillions of ways that people find out about this or
that package - discovery of the good amidst the bad
and the ugly isn't a real problem, IMO.

And I don't care about maintenance of the "brand".
IMO, Emacs isn't in a competitive race.  That's no
doubt a minority opinion.  I like people to benefit
from Emacs, and I evangelize it as much as then next
Emaxist.  But I don't feel like there's any need to
sell anything, and no need to polish the sign or the
brand.  It shines enough, for those who care to see.

2. Emacs has users.  Users report problems.  Even
without automatic testing, testing gets done.  If no
one reports a problem with some package then it's a
first-order indication of few problems or few users.
Neither of those cases is cause for alarm.

There are "core" Emacs functions, even libraries,
that few users use.  Yet they might be useful, and
perhaps just lie dormant, undiscovered or
underappreciated.

Like many people, I appreciate dabbrev.  But I also
appreciate the little-known functionality of the
old standard library completion.el, which is a bit
similar.  The latter has no doc, other than its
quaint Commentary.  But who knows?  Maybe someday
it'll be put to more and better use, and maybe
improved.  Or maybe its features will serve as food
for thought for something better, whether restarted
from scratch or directly derivative.

3. It's not like there's some imperative to reduce
the size of the ELPA repository, I hope.  Broken
code that people use will get reported, I expect.

And then it'll get fixed - or not.  If it remains
broken, with no one trying to fix/maintain it, then
deprecation or removal might be worth considering.
Other than that, I don't see the point of rushing
to judgment.

But then, I'm more of a hoarder than a Marie Kondo...

Let 100 flowers bloom.  Really.  There'll be plenty
of time to pull out any truly poisonous weeds.

Re: [ELPA] Package cleanup

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

Thanks for investigating the situation with unmaintained packages.
What you've found will help us think about what to do.

  > Just a question. Did you finally agreed about the package
  > obsoletion/removal procedure for ELPA?

I'd like to see a proposal.

  > It seems there are some packages there which haven't received any update
  > in a very long time (>5 years).

That suggests they might have bugs and need maintenance,
but it does not imply they are useless or obsolete.
They might be obsolete, or not.

There are many questions we'd want to check
to decide what to do with each package.

  > I have found some packages that doesn't even work or rely on some
  > features that were obsoleted or removed.

In those cases, we clearly don't want to leave the package there
in its current form.  But what change should we make?

We could delete it.  We could look for people to update it.
Either one might be better, depending on more details.


-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: [ELPA] Package cleanup

[Po Lu]

Richard Stallman <rms@gnu.org> writes:

> That suggests they might have bugs and need maintenance, but it does
> not imply they are useless or obsolete.  They might be obsolete, or
> not.

Indeed.  There are some very useful packages that aren't maintained
anymore (i.e. yasnippet, which hasn't seen changes since 2 years, and
has no sign of that changing any time soon.)

>   > I have found some packages that doesn't even work or rely on some
>   > features that were obsoleted or removed.

I would rather we take a different approach: don't change anything that
will break packages on ELPA.

Re: [ELPA] Package cleanup

[Jimmy Aguilar Mena]

On Tue, Mar 29, 2022 at 11:12:06PM -0400, Richard Stallman wrote:
>[[[ To any NSA and FBI agents reading my email: please consider    ]]]
>[[[ whether defending the US Constitution against all enemies,     ]]]
>[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
>Thanks for investigating the situation with unmaintained packages.
>What you've found will help us think about what to do.
>
>  > Just a question. Did you finally agreed about the package
>  > obsoletion/removal procedure for ELPA?
>
>I'd like to see a proposal.
>
I have seen some discussions about this topic before. See bellow.

>  > It seems there are some packages there which haven't received any update
>  > in a very long time (>5 years).
>
>That suggests they might have bugs and need maintenance,
>but it does not imply they are useless or obsolete.
>They might be obsolete, or not.
>
>There are many questions we'd want to check
>to decide what to do with each package.
>
But if they don't receive any update for years, and the bug reports
accumulate (on github too) then it quite possible that either the users
and the maintainers are not interested on it anymore.

>  > I have found some packages that doesn't even work or rely on some
>  > features that were obsoleted or removed.
>
>In those cases, we clearly don't want to leave the package there
>in its current form.  But what change should we make?
>
>We could delete it.  We could look for people to update it.
>Either one might be better, depending on more details.
>
We could archive it in a different repository in case someone desires to
adopt, check or fork in the future. Or we could also flag it somehow to
say to the package-list that it is orphan, obsolete,
unmaintained... That's the approach in the AUR repository for arch Linux
and it is useful; because the users get a warning during the updates
about abandon, orphan or outdated packages.

Then if a package is in that state for too long it may be archived, so
it can be accessed, but is not offered in the package list as a good
alternative.
>
>-- 
>Dr Richard Stallman (https://stallman.org)
>Chief GNUisance of the GNU Project (https://gnu.org)
>Founder, Free Software Foundation (https://fsf.org)
>Internet Hall-of-Famer (https://internethalloffame.org)
>
>

Re: [ELPA] Package cleanup

[Michael Albinus]

Drew Adams <drew.adams@oracle.com> writes:

Hi,

>> 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?)

It is on my longer TODO list to activate automatic tests for GNU ELPA
packages on emba.gnu.org. Yes, only for "GNU" ELPA packages.

Unfortunately, these days I'm the only one who works on emba, and there
are many other TODO items. So I have no idea if/when this will happen.

Best regards, Michael.

Re: [ELPA] Package cleanup

[João Távora]

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

On Wed, Mar 30, 2022, 04:44 Po Lu <luangruo@yahoo.com> wrote:

> Richard Stallman <rms@gnu.org> writes:
>
> > That suggests they might have bugs and need maintenance, but it does
> > not imply they are useless or obsolete.  They might be obsolete, or
> > not.
>
> Indeed.  There are some very useful packages that aren't maintained
> anymore (i.e. yasnippet, which hasn't seen changes since 2 years, and
> has no sign of that changing any time soon.)
>

Speaking of which, I'm looking for a maintainer for yasnippet. Noam did an
amazing job for many years, but has moved on. If anyone is interested, let
me know.

A first task would be too sort through the rubble of many unopened issues
and see which ones contain valuable/fixable bugs or suggestions.

João

>

[-- Attachment #2: Type: text/html, Size: 1673 bytes --]

Re: [External] : [ELPA] Package cleanup

[Stefan Monnier]

> 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.


        Stefan

Re: [External] : [ELPA] Package cleanup

[Jimmy Aguilar Mena]

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
>

Re: [External] : [ELPA] Package cleanup

[Stefan Monnier]

> 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.

I think we're still fairly far from those problems, sadly.


        Stefan

Re: [External] : [ELPA] Package cleanup

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > But if there is no mechanism to, at least, identify decay then,
  > over time, the ratio of high quality packages to those of lesser
  > quality drops.

I can envision features we could add to get more feedback about ELPA
packages.  If a package has not been changed in N years, we could
add some simple code to display a message to each user who installs
the package.

For instance, it could suggest sending us an emeil saying whether you
find the package useful, and whether it works correctly.


-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: [External] : [ELPA] Package cleanup

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > If the only virtue of being on ELPA is that I can install via
  > package.el then that seems like rather thin gruel.

The main virtue of ELPA is that we make sure that the package follows
our ethical criteria, so that it is acceptable for us to recommend it
to people.  A second virtue is that we can move the code into core Emacs.

A secondary benefit is that the Emacs developers can fix problems in
these packages, when we know of a specific problem.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: [ELPA] Package cleanup

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > >There are many questions we'd want to check
  > >to decide what to do with each package.
  > >
  > But if they don't receive any update for years,

That's the case that was brought up.

                                                    and the bug reports
  > accumulate 

That wasn't mentioned before.  It makes a difference.  Depending on
what those bugs do, we might delete (or obsolete) the package -- but
not automatically and rigidly.

Another option would be to ask users to tell us what they think of the
package.

               (on github too)

How does that make a difference?

We don't use Github.  We won't ask anyone to make an account there,
since doing so requires running their nonfree software.

Supposing we find someone to fix bugs in the package, we can't fix
them on github.  We could change the GNU ELPA version to direct people
clearly to report bugs to us, so we can fix them.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)