Re: [nongnu] main 74116339a8 2/3: * elpa-packages (anzu): New package

[Philip Kaludercic <philipk@posteo.net>]

Stefan Kangas <stefan@marxist.se> writes:

> Philip Kaludercic <philipk@posteo.net> writes:
>
>> I think this might be worth discussing.  The impression I get is that a
>> lot of packages/libraries are not being used because they are better,
>
> Agreed.
>
>> The "danger" is that MELPA might give the wrong impression of
>> popularity:
>
> Yes, I see the same problems and hope that we will eventually be able to
> do better on (Non-)GNU ELPA (and I hope MELPA will, too)!  For example,
> we could show download count in the last 12 months in addition to the
> total downloads.  If we could add a "?major-version=28.1" to the URL or
> somesuch, we could even start counting downloads per major version.
> (Though I'm not sure if there are any privacy implications, or if it
> should be opt-in or opt-out.)

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?

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

>> Do we want to collect as many packages as possible, even if the
>> implementations and practices are sub-optimal, are displaced by
>> alternative implementations in Emacs or ELPA, etc. or should we try to
>> restrict the packages to popular, "good citizens" of the Emacs package
>> space, in an effort to raise the standards and clean up "obsolete" and
>> "redundant" packages.  It is probably clear that I have an inclination
>> towards the latter position: Going forward it seems preferable to have
>> as many useful and idiomatic packages available directly via the ELPAs,
>> without burdening newcomers with duplicate functionalities.  My
>> motivation in contributing to NonGNU ELPA is to further this goal.
>
> I basically agree.  I won't be adding redundant or novelty packages
> myself -- unless I do it by mistake! -- but there is also some balance:
> I don't want to impose my opinions on everyone else.
>
> So when it comes to "evil-*" packages, I feel like I did my part by
> adding the 10-15 most downloaded ones on MELPA.  I don't use evil, so I
> have no other criteria to go by, really.

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.

> But when it comes to packages I do use, like ace-jump, I noticed that it
> had been superseded by avy.  So I added this to my private NGE notes:
>
>     *** Packages not to add
>     - ace-jump: seems superseded by avy (in GNU ELPA)
>
> 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 also have my
private notes, and if more people want to contribute, being able to
quickly check what the status of a package is (waiting for a patch to be
applied, obsoleted, ...) would be useful.

>>  It seems to me that MELPA leans
>> towards completeness, adding anything from serious packages to fun and
>> jokes.
>
> I think we should take the middle ground: let's not *only* add the most
> technically sound and excellent packages, because you'll end up with a
> lot of stuff that is actually used by people that won't make the cut.
>
> But let's also steer clear of the obvious low
> effort/patch/bad/novelty/obsolete/unmaintained packages.
>
> I *hope* that in general you will find that my additions have been
> balanced, but please point out if you see any examples (such as anzu)
> that you think we could discuss.

Most of the packages certainly are good and appreciated additions, and
would have liked to help if I had more time.

>>  While I do understand the motivation/advantages, it appears to
>> fuel the "there is a package for that" mentality (parallel to Apple's
>> "there is an app for that"-slogan), that implies to download a package
>> for every little change, instead of writing or even copying some Elisp.
> [snip]
>> (From what I remember you were intending to present a talk on a related
>> topic at EmacsConf last year, right?)
>
> Correct.  Unfortunately, I had two consecutive colds and couldn't make
> it.  But as you can imagine, I strongly agree with you.  ;-)
>
> I am not against any efforts in this direction, of course, and I would
> welcome any kind of initiative to do "community outreach" here.

What do you mean by this?

> However, I think the place when we can really start doing such work is
> when people start coming to *us* to ask to be added, and not the other
> way around.  This will happen eventually, I think, but we have a bit of
> an up-hill battle to get the first critical mass (getting Emacs 28, 29,
> 30 out the door will help of course).

What difference would this make? I agree that it would be preferable,
but a tone for what packages are added to NonGNU ELPA can already be
set.

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.  It seems that there is already some interest in using this
package, most notably from transient.  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).

-- 
	Philip Kaludercic