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

[Yoni Rabkin <yoni@rabkins.net>]

Clément Pit-Claudel <cpitclaudel@gmail.com> writes:

> On 18/05/2020 11.22, Yoni Rabkin wrote:
>> I'm the maintainer of GNU/Emms (a media player for Emacs). The people
>> who distribute Emms on MELPA do a poor job of it (see below), and have
>> never communicated with us, the Emms developers about it (not even
>> once). I only discovered about it by chance recently when I went out to
>> figure out what M/ELPA is, and how I can add Emms to ELPA.
>> 
>> What the MEPLA people are doing that I don't like:
>
> I think you're a bit harsh with the MELPA folks. EMMS was added to
> MELPA eight years ago, back when it was just getting started, so I
> wouldn't judge based on that.  See below re. contacting package
> authors.

I apologize for being harsh. I shouldn't have done that.

I re-read what I've written below to see if it is harsh. It is
opinionated, I don't think it is harsh. If it is harsh, please don't
hesitate to point it out. I'll be happy for pointers on how to make my
writing more kind.

>>     * Associate Emms with several Emms extensions that live only on
>>       MELPA and that we, the Emms developers, have never heard
>>       about. This would give anyone accessing Emms via MELPA that those
>>       extensions are somehow a part of Emms, when they are not.
>
> What do you mean by this?  MELPA is the same as ELPA in this regard:
> anyone can publish an "emms-xyz" package, right?

The site, https://melpa.org/#/emms, lists a number of projects under
"needed by". But there is no differentiation between Emms, a GNU
project, and those "needed by" projects.

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

The word "gnu" doesn't even appear on the website for Emms on
MELPA. Surely there is some value to pointing out to people which part
of what is being distributed is a GNU project, and thereby subject to
GNU's standards. People can then go on to ignore the information, but at
least they have access to it.


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

>> Ideas for improvement:
>> 
>>     * Encourage people to speak to the developers of a project before
>>       packaging it.
>
> The current guidelines say the following:
>
> Contact package author
>     If you are not the original author or maintainer of the package
>     you are submitting, please notify the authors prior to submitting
>     and include them in the pull request process.
>
> … so things have indeed improved a lot since 2012.

Not in the case of Emms, since nobody has done so. Therefore, Emms has
not been the beneficiary of such an improvement.

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

>>       Emms doesn't need a recipe; it already comes organized and
>>       packaged for working with Emacs.
>
> I think most users these days expect "packaged" to mean "installable
> using package.el", while EMMS only provides source releases; that's
> why you see the MELPA recipe slicing and dicing the emms repo.

I don't agree with "most people"-type statements as an argument for a
number of reasons, among them that I've always been against speaking on
behalf of other people. I can speak for myself as the maintainer of Emms
on behalf of GNU, and try to steer toward to the goal of the GNU project
when doing so. I don't check to see if there is a majority or minority
supporting me in this regard.


> 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, and
will hopefully soon be installable via ELPA.

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.

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.

-- 
   "Cut your own wood and it will warm you twice"