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

[Dmitry Gutov]

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?

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

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