From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.bugs Subject: bug#19296: [PATCH] Package archives now have priorities. Date: Sun, 7 Dec 2014 10:16:29 -0800 (PST) Message-ID: <77c7e7b5-c30b-4b9a-9737-4e9eb587499e@default> References: <<20141207132244.A14A7200D1E@loki.jorgenschaefer.de> <20141207154316.1f2c5943@forcix> <20141207171002.31c51d19@forcix> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1417976248 6924 80.91.229.3 (7 Dec 2014 18:17:28 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 7 Dec 2014 18:17:28 +0000 (UTC) Cc: 19296@debbugs.gnu.org To: Jorgen Schaefer Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Dec 07 19:17:22 2014 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1XxgOX-00070A-W7 for geb-bug-gnu-emacs@m.gmane.org; Sun, 07 Dec 2014 19:17:22 +0100 Original-Received: from localhost ([::1]:58788 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XxgOX-00005S-6x for geb-bug-gnu-emacs@m.gmane.org; Sun, 07 Dec 2014 13:17:21 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:36617) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XxgOM-00005H-1C for bug-gnu-emacs@gnu.org; Sun, 07 Dec 2014 13:17:17 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XxgOE-0005GC-Od for bug-gnu-emacs@gnu.org; Sun, 07 Dec 2014 13:17:09 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:59272) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XxgOE-0005G7-Kg for bug-gnu-emacs@gnu.org; Sun, 07 Dec 2014 13:17:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1XxgOE-0005xH-0n for bug-gnu-emacs@gnu.org; Sun, 07 Dec 2014 13:17:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 07 Dec 2014 18:17:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19296 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 19296-submit@debbugs.gnu.org id=B19296.141797619322849 (code B ref 19296); Sun, 07 Dec 2014 18:17:01 +0000 Original-Received: (at 19296) by debbugs.gnu.org; 7 Dec 2014 18:16:33 +0000 Original-Received: from localhost ([127.0.0.1]:56485 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XxgNk-0005wS-T4 for submit@debbugs.gnu.org; Sun, 07 Dec 2014 13:16:33 -0500 Original-Received: from aserp1040.oracle.com ([141.146.126.69]:32779) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XxgNi-0005wG-08 for 19296@debbugs.gnu.org; Sun, 07 Dec 2014 13:16:31 -0500 Original-Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id sB7IGSYN020244 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 7 Dec 2014 18:16:29 GMT Original-Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id sB7IGRVQ014820 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 7 Dec 2014 18:16:28 GMT Original-Received: from abhmp0015.oracle.com (abhmp0015.oracle.com [141.146.116.21]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id sB7IGReH027396; Sun, 7 Dec 2014 18:16:27 GMT In-Reply-To: <20141207171002.31c51d19@forcix> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.8.2 (807160) [OL 12.0.6691.5000 (x86)] X-Source-IP: acsinet22.oracle.com [141.146.126.238] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:96952 Archived-At: > > 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. >=20 > 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,=20 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* >=20 > 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=20 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.