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

[Yoni Rabkin]

Dmitry Gutov <address@hidden> writes:

> On 18.05.2020 20:30, Yoni Rabkin wrote:
>
>>>>      * 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.)
>
> People just learn to understand that different packages usually means
> different authors, and having the prefix emms- on many packages has 
> little bearing on your reputation.
>
>> 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.
>
> That is because the main package file doesn't follow the ELPA standard
> of having it commentary describe the whole package.
>
> See the "Description" on the MELPA site. The area can host a more
> thorough description if you make it so.
>
>>>>      * 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.
>
> And that is because, I'm guessing, your main package file doesn't have
> the "Homepage" header.
>
>>> 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.
>
> The above are guidelines for when a package recipe is submitted. Once
> it's submitted, the package simply continues to be distributed. Unless 
> someone raises an issue, proposes a better recipe, etc.
>
>>>>      * 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.
>
> Yes: MELPA uses "recipes" (files with data in particular format) to
> automate distribution.
>
>>>>        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.
>
> Surely you care about the users' convenience at least a little?

I think we are talking across each other, because I don't understand
what you are referring to.

>>> 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?
>
> I don't know, really. You could keep the most popular one.
>
> Do you have any download stats for the last year? Or since 2012?

It is hosted on Savannah, but I'm unsure of why it would matter.

>> 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.
>
> I'm fairly sure that if you demand to be removed, they will do so.
>
> Doing that would punish existing users, however. So I can hardly
> understand the reasons for doing so.

My understanding of it is that some people (the people who emailed the
Emms mailing list about it) would rather be able to have Emacs' package
system install Emms for them.

I further understood that for that to happen, Emms needs to be available
via ELPA. As far as I know, it is the only repository that is officially
a part of the Emacs project.

Once Emms is available on ELPA, people who want Emacs' package manager
to install it will have it available. At that point it would be very
strange, and confusing, to have an identical copy of Emms separately
maintained via MELPA.

I hope that this isn't a common issue, one in which packages are
duplicated between ELPA and MELPA; that would point to something that is
organizationally broken somewhere.

If there is some technical issue that would stop MELPA users from
getting it from ELPA, then perhaps we could organize a way for the ELPA
maintained copy be mirrored to MELPA. That seems like a kludge, but we
should try to do it if that is the only way not to break people's
installation.

The last resort would be to maintain ELPA and MELPA separately. This is
hardly an ideal situation and one that I hope isn't the standard.

Thank you for all of your patience as I'm learning this.

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