Re: "Write a new package" culture instead of patches?

[Clément Pit-Claudel]

On 18/05/2020 13.30, Yoni Rabkin wrote:
> I agree that it is their right to distribute Emms as they wish as long
> as they abide by the terms of the license, but I do not agree that their
> particular form of distribution is good for Emms (no quality control for
> those "needed by" projects; do they even work?) or if it is good for the
> people who enjoy Emms (maybe they steer people to use proprietary
> services.)

There is a bit of quality control, at package submission time (things regarding 
proper API documentation, proper namespacing, etc. — but nothing like tests, 
indeed).
I think the way they display thing isn't much different from what you get with 
"apt-cache rdepends" on a Debian system (it's not the same as the `Recommends: 
mpg321` or `Suggests: mp3info` lines that `apt` shows when I ask it `apt show 
emms`, for example).

>>>     * Not even linking to the Emms home page
>>>       (https://www.gnu.org/software/emms/).
>>
>> I think it does: I see this when I open the package in M-x list-packages:
>>
>>    Homepage: https://www.gnu.org/software/emms/
>>
>> The MELPA website links to the git repository instead.
> 
> Yes, that was what I was referring to.

Good point; I opened a ticket about this.

>>>     * Find a way of packaging a project as-is. For instance, Emms could
>>>       be distributed as is, and the M/ELPA software could simply point
>>>       at where Emms keeps its .el files for Emacs to find. This is
>>>       instead of how I see ELPA working now, which is to force the
>>>       software through a kind of a sieve (I think ELPA calls it a
>>>       recipe) where only a select few files come out the other end.
>>
>> It's trivial to make a recipe that includes all files, so I wouldn't
>> worry about this.
> 
> The Emms distribution already contains all of the files by defintion;
> none needed to be remove to begin with. I feel like we looking at the
> issue from two different viewpoints.

The package manager that comes by default in Emacs 24+ is able to produce ELC 
and info files automatically, so packages typically don't ship Makefiles.  
Additionally, it makes certain assumptions about archive layout that EMMS' 
releases currently don't abide by; that's why MELPA has recipes.
Distributing through ELPA would require the same modifications: this is just 
the way package.el works. 

>> It will be great to have an improved EMMS recipe in MELPA!  If you run
>> into trouble, you should ask on the bug tracker; the MELPA folks are
>> great.
> 
> Why does Emms need to be offered through three different channels at the
> same time?
> 
> Ideally, I would contact the MELPA bug tracker and have Emms removed
> from MELPA, since it can be trivially downloaded from a GNU server

Downloading it from a GNU server is very complicated, compared to installing it 
through MELPA.

> and will hopefully soon be installable via ELPA.

I hope you can put it in ELPA; that would be even better.

> However, since nobody asked last time they installed Emms there, nothing
> would stop them from installing it on MELPA again, or modifying the
> recipe to exclude files again. Since MELPA offers the Emms project no
> control over distribution, I don't have much incentive to work on how
> Emms is distributed there, or to fix it and then schedule a weekly
> excursion to MELPA to see if someone has broken it.

This is not how it will work: EMMS was one of the earlier packages to be 
included in there, before there was a policy to keep maintainers in the loop.  
Today, it wouldn't be included without asking.

> Please forgive me if I'm misunderstanding something fundamental about
> how MELPA works. As I've mentioned before, I don't use it or ELPA.

No worries. The short summary is that MELPA doesn't take an adversarial 
approach, so if you ask for your package to be removed, it will be removed.
But please don't, not before putting it on ELPA — it will break many users' 
configurations, since emms is rather popular there.

Do you keep statistics for your web server?  It would be useful to compare how 
many people install through MELPA and how many download releases directly.