unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Drew Adams <drew.adams@oracle.com>
To: John Yates <john@yates-sheets.org>
Cc: "emacs-devel@gnu.org" <emacs-devel@gnu.org>,
	Jimmy Aguilar Mena <jimmy.aguilar@bsc.es>
Subject: RE: [External] : [ELPA] Package cleanup
Date: Tue, 29 Mar 2022 22:04:47 +0000	[thread overview]
Message-ID: <SJ0PR10MB5488C6D5CD40B233A90A76C6F31E9@SJ0PR10MB5488.namprd10.prod.outlook.com> (raw)
In-Reply-To: <CAJnXXoixeqyDsJ0GEYY67e8ROxBsMYT8y0DXOF7wJk0Ld=Vp2A@mail.gmail.com>

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

  reply	other threads:[~2022-03-29 22:04 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-29  0:43 [ELPA] Package cleanup Jimmy Aguilar Mena
2022-03-29 16:24 ` [External] : " Drew Adams
2022-03-29 21:41   ` John Yates
2022-03-29 22:04     ` Drew Adams [this message]
2022-03-29 23:05       ` John Yates
2022-03-30  1:43         ` Drew Adams
2022-03-31  4:27         ` Richard Stallman
2022-03-30  7:31       ` Michael Albinus
2022-03-30  8:35     ` [External] : " Stefan Monnier
2022-03-30 14:09       ` Jimmy Aguilar Mena
2022-03-30 21:23         ` Stefan Monnier
2022-03-31  4:27     ` Richard Stallman
2022-03-30  3:12 ` Richard Stallman
2022-03-30  3:44   ` Po Lu
2022-03-30  7:56     ` João Távora
2022-03-30  4:56   ` Jimmy Aguilar Mena
2022-04-01  4:07     ` Richard Stallman

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=SJ0PR10MB5488C6D5CD40B233A90A76C6F31E9@SJ0PR10MB5488.namprd10.prod.outlook.com \
    --to=drew.adams@oracle.com \
    --cc=emacs-devel@gnu.org \
    --cc=jimmy.aguilar@bsc.es \
    --cc=john@yates-sheets.org \
    /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).