From: Stefan Monnier <monnier@iro.umontreal.ca>
To: Philip Kaludercic <philipk@posteo.net>
Cc: Stefan Kangas <stefan@marxist.se>, emacs-devel@gnu.org
Subject: Re: [nongnu] main 74116339a8 2/3: * elpa-packages (anzu): New package
Date: Sun, 16 Jan 2022 17:19:23 -0500 [thread overview]
Message-ID: <jwvee57fi7a.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: <87mtjvd10u.fsf@posteo.net> (Philip Kaludercic's message of "Sun, 16 Jan 2022 17:49:05 +0000")
> Interesting idea, though it should probably be opt-in, at the risk of
> skewing the popularity data towards enthusiasts. Just one thing: It
> seems like this would either require a special server or to scrub the
> server logs. Is either of that feasible?
The webserver on elpa.gnu.org is under our control, so yes we have
access to the log. I believe the same holds for MELPA.
As for "opt-in", I don't see any need to add user-control to it, but we
should rather show more complete data (like a histogram) so the users
can get a better sense of what's going on.
>> I also think we should have a "rating" system in place, which should
>> also somehow include information on which version/date the user rated
>> the package in.
> Would also be nice.
I don't know how to do that, OTOH (at least in a way that's not too
susceptible to ridiculous amounts of bias).
> If we have Evil, it seems necessary to add some of extensions, as Evil
> appears to not be complete on it's own. But as this is an entire
> package-space onto itself, I am uncertain which of these are actually
> being used and which are obsoleted by either other evil-specific
> packages, other general packages or even features in Emacs.
There seems to be a fair bit of duplication here, in that many of those
Evil-specific packages would benefit from being made non-specific to
Evil (or merged with similar non-Evil-specific packages).
>> I'm not sure if we should have a public record of packages we decide
>> *not* to add. If we did, one place to put it would be just directly
>> `nongnu/elpa-packages` itself, in the regular alphabetical order, which
>> is a place you're less likely to forget looking in.
> It might not be bad to collect these notes somewhere.
I agree with Stefan (the usurper) in that `elpa-packages` is a good
place for that.
> On the topic of critical mass: It might be possible to spread NonGNU
> ELPA via compat (https://git.sr.ht/~pkal/compat), as soon as it is
> released.
I don't understand hat you meant by that.
Do you mean to have `compat` do
(add-to-list 'package-archives '("nongnu" . ...))
?
> But as the package is already borderline heretical, I hesitate to do
> something like this (the same applies to updating the default rcirc
> and erc server lists).
Maybe we can make it safe enough via something like
(when (member package-archives
'((("gnu" . "https://..."))
(("gnu" . "http://..."))))
(add-to-list 'package-archives '("nongnu" . ...)))
so it only adds the entry when nothing's been changed yet.
Stefan
next prev parent reply other threads:[~2022-01-16 22:19 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <164145738158.2838.5769558384331859964@vcs2.savannah.gnu.org>
[not found] ` <20220106082302.0A19CC0DA1E@vcs2.savannah.gnu.org>
2022-01-06 10:02 ` [nongnu] main 74116339a8 2/3: * elpa-packages (anzu): New package Philip Kaludercic
2022-01-06 12:00 ` Stefan Kangas
2022-01-06 13:35 ` Philip Kaludercic
2022-01-06 14:30 ` Packages quality (was: [nongnu] main 74116339a8 2/3: * elpa-packages (anzu): New package) Stefan Monnier
2022-01-06 15:03 ` Bozhidar Batsov
2022-01-06 17:07 ` Packages quality Stefan Monnier
2022-01-06 19:50 ` Tim Cross
2022-01-07 7:54 ` Stefan Kangas
2022-01-07 11:45 ` John Yates
2022-01-07 12:16 ` Stefan Kangas
2022-01-07 15:52 ` John Yates
2022-01-07 7:55 ` Packages quality (was: [nongnu] main 74116339a8 2/3: * elpa-packages (anzu): New package) Stefan Kangas
2022-01-07 10:22 ` Bozhidar Batsov
2022-01-07 10:54 ` Stefan Kangas
2022-01-06 17:28 ` Packages quality Philip Kaludercic
2022-01-06 19:55 ` [nongnu] main 74116339a8 2/3: * elpa-packages (anzu): New package Juri Linkov
2022-01-07 7:55 ` Stefan Kangas
2022-01-16 17:49 ` Philip Kaludercic
2022-01-16 22:19 ` Stefan Monnier [this message]
2022-01-19 8:57 ` Philip Kaludercic
2022-01-19 15:19 ` Stefan Monnier
2022-01-16 22:32 ` Stefan Kangas
2022-01-16 23:16 ` Ergus
2022-01-19 9:05 ` Philip Kaludercic
2022-01-16 23:47 ` Stefan Monnier
2022-01-19 9:03 ` Philip Kaludercic
2022-01-17 7:37 ` Jean Louis
2022-01-19 9:10 ` Philip Kaludercic
2022-01-07 10:02 ` Stefan Kangas
2022-01-10 1:18 ` Stefan Monnier
2022-01-07 9:38 ` Augusto Stoffel
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=jwvee57fi7a.fsf-monnier+emacs@gnu.org \
--to=monnier@iro.umontreal.ca \
--cc=emacs-devel@gnu.org \
--cc=philipk@posteo.net \
--cc=stefan@marxist.se \
/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).