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: Jimmy Aguilar Mena <jimmy.aguilar@bsc.es>,
	"emacs-devel@gnu.org" <emacs-devel@gnu.org>
Subject: RE: [External] : [ELPA] Package cleanup
Date: Wed, 30 Mar 2022 01:43:04 +0000	[thread overview]
Message-ID: <SJ0PR10MB548857FEF5F0355EF31EF35DF31F9@SJ0PR10MB5488.namprd10.prod.outlook.com> (raw)
In-Reply-To: <CAJnXXohf-oVvM1TUwBqJEkQeOJTWJ00+QcC1cUz7-bCmqnsaHw@mail.gmail.com>

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

  reply	other threads:[~2022-03-30  1:43 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
2022-03-29 23:05       ` John Yates
2022-03-30  1:43         ` Drew Adams [this message]
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=SJ0PR10MB548857FEF5F0355EF31EF35DF31F9@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).