bug#19296: [PATCH] Package archives now have priorities.

[Drew Adams]

> > MELPA provides *packages*.  Whether a package is "stable" or
> > not, as far as one can tell from the outside, is only something
> > (optionally) claimed by its developer.
> 
> MELPA actively discourages package authors to have a "stable"
> branch in the recipe:
> https://github.com/milkypostman/melpa/pull/1129#issuecomment-
> 27156539

That URL points to Donald Curtis saying just what I've been
saying here, AFAICT.  MELPA packages are packages, nothing more.
And saying this:

 "part of the reason MELPA is so popular is because it's
  automatic-doesn't rely on the developer to make releases-
  and it provides the newest features".

There is nothing there about MELPA encouraging unstable
packages or discouraging stable packages.

You don't like MELPA.  That much is clear.  That does not an
Emacs bug make.  You say (at that URL):

 "MELPA is becoming the standard package archive outside of
  GNU, and a lot of places recommend using MELPA."

That seems to be what bothers you, AFAICT.  Get over it.
Just don't use it, if you can't get along with it.

> MELPA strongly prefers "snapshot" releases, 

It allows any kind of "release" you want.  And yes, in
particular, it *allows* automatic updating.  This is a
*feature*.  Don't use it if you don't want it.

A package maintainer who uses it wants it.

Nothing requires a maintainer to modify the package source
that is pulled from, so that an automatic "update" to the
repository mirror of it actually changes something.  A
"stable", "release", "official" package can sit in its source
location unchanged for as long as it wants.  When it is
mirrored to MELPA it will remain just as "stable", "release",
and "official".

> and suggests that users use the "MELPA stable" package archive
> if they do want officially released versions.

There is nothing in the URL you cite about "officially
released versions".  How a package maintainer wants to
characterize a given occurrence of a package in a repository
is that maintainer's business.

MELPA does not recognize any "officially released versions",
and it should not.  Nor should package.el.  Who or what is
"official" here?

Releases, "official" or not; snapshots; and whatever else you
like are labels that *package maintainers* can give to their
packages.  If used, they are meaningful only to the package
itself; they are not recognized by the package manager.

They are orthogonal to any handling by ELPA repositories
and package.el (or at least they should be).

They have, and should have, nothing to do with a package
repository.  package.el should not get involved with any
particular labeling of a package by a package maintainer
wrt its use category, whether that be "beta", "snapshot",
"foobar", "official", or anything else.  Such labels do
not exist for the package manager.

Now let's see how you talk about it (same URL):

 "If MELPA wants to enable users to use the bleeding edge
  at the danger of them having unstable code, then MELPA
  needs to advertise this more."

"bleeding edge", "danger", "unstable"...  Sounds scary!

 "As is, MELPA is advertised as the one big useful lisp
  archive with no shortcomings, and that is how many
  users copy and paste the MELPA address to their
  configuration files."

And:

 "[users] are easily tricked into using MELPA" because
                     ^^^^^^^^^^^^^^^^^^^^^^^^
  it "is establishing itself as the de facto standard
  repository for Emacs Lisp packages."

Uh, MELPA isn't really advertised, and certainly not
like that.  It sounds like you have a problem with the
fact that many users *do* think of MELPA as "the one
big useful lisp archive" and they *do* "copy and paste
the MELPA address to their configuration files."

Are they wrong to do so?  Do you want to tell them what
they should think and do?  Is that what this Emacs "bug"
is all about?  MELPA is dangerous! bleeding edge! unstable
and scary stuff - stay away from it!

What do you care what many or most users do with MELPA
or what they think of it?  If you don't want to use
MELPA then don't use it.  "Problem" solved.

> When I raised this issue in the past, I was told that the
> "E" in "MELPA" originally stood for "Experimental":

Who cares?

> https://github.com/milkypostman/melpa/pull/1129#issuecomment-
> 27156209

Clearly you have gripes with MELPA.  My advice is for you to
simply not use it.  Leave it for the many other Emacs users
who appreciate it.  It is trivial for you not to use it.
We'll all be happier.  Not a bug.

> > Repository priorities can be expressed in a normal way,
> > using a list or assigning priority values - with *no
> > built-in prejudice*
> 
> This patch does not add any built-in prejudice. As the patch
> description says, this *allows* the user to set it up like that.
> It does not force anyone to do anything, and does not change
> default behavior at all.

Given your attitude toward MELPA, I'm not convinced.  But I
suppose we shall see.

> Could I ask you to be a bit more courteous and civil to
> possible contributors in the future? Thank you.

Don't be so presumptuous.

You showed the same attitude in the URL you cited:

 "So you are saying that you simply refuse to provide the
  version of my package, which I politely asked you to
  provide?"

To which the reply was:

 "That's not what I'm saying. I hoped that we could have a 
  conversation in order to understand the trade-offs and
  jointly look for a solution which suits everyone.
  If that's not the case, then your polite request is
  technically a demand."

You are so polite, and everyone else is so uncooperative.
Funny about that.

> If you require further responses, please do specify in
> what official capacity you are speaking. I seem unable to
> find you on the list of maintainers for Emacs.

It appears that you are quite impressed by whatever you
think is "official", Herr Schaefer.

I am an Emacs *user*.  Fortunately, we are still able to
speak our minds.  When you are elected Pope, maybe things
will change in that regard.

Apparently this has all come about because this happened:

 "I did not supply an elpy recipe to MELPA (quite
  intentionally so because of this problem). Someone else
  has. Suddenly, I have users coming to me with weird bugs
  related to them unknowingly using a development version
  of elpy."

That's not MELPA's fault.  Tell your users not to do that.
Tell your users that any ELPY taken from MELPA will not
be supported by you.  Tell them to beware the evil MELPA.

You say that you:

 "have a problem with getting feedback about a snapshot by
  users not knowing they are using a snapshot, never having
  wanted to use a snapshot, and being ill-equipped to even
  debug it because they do not know Emacs Lisp at all (and
  why should they, they just use Emacs). They were
  basically tricked into using a source of software that not
            ^^^^^^^
  only accidentally exposes them to possibly broken software,
  but apparently even refuses to take steps to protect them
                      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  from that."

To which the polite reply was:

 "Man, you just seem mad for no reason. We're just trying to
  offer solutions that would work for all of us, but I guess
  we will have to do it your way."

Tell your users to stay away from dangerous MELPA.
Just say no to MELPA if you don't want to use it.