From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Yoni Rabkin Newsgroups: gmane.emacs.devel Subject: Re: "Write a new package" culture instead of patches? Date: Mon, 18 May 2020 16:17:40 -0400 Message-ID: <871rnhatgb.fsf@rabkins.net> References: <83tv0e9x14.fsf@gnu.org> <83blml9u2t.fsf@gnu.org> <87v9ktb73s.fsf@rabkins.net> <800432c5-2f72-3c29-7399-c6f1f559d983@gmail.com> <87imgtb17b.fsf@rabkins.net> <5de873b7-0157-05ef-8aea-0635ad8a2276@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="37615"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.91 (gnu/linux) Cc: emacs-devel@gnu.org To: =?utf-8?Q?Cl=C3=A9ment?= Pit-Claudel Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon May 18 22:24:54 2020 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jamJh-0009fF-M1 for ged-emacs-devel@m.gmane-mx.org; Mon, 18 May 2020 22:24:53 +0200 Original-Received: from localhost ([::1]:33148 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jamJg-0000y2-Ol for ged-emacs-devel@m.gmane-mx.org; Mon, 18 May 2020 16:24:52 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:59234) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jamCs-0000Qz-29 for emacs-devel@gnu.org; Mon, 18 May 2020 16:17:50 -0400 Original-Received: from smtprelay0088.hostedemail.com ([216.40.44.88]:36384 helo=smtprelay.hostedemail.com) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jamCl-0003LI-8o for emacs-devel@gnu.org; Mon, 18 May 2020 16:17:47 -0400 Original-Received: from filter.hostedemail.com (clb03-v110.bra.tucows.net [216.40.38.60]) by smtprelay01.hostedemail.com (Postfix) with ESMTP id 5EAFA100E7B44; Mon, 18 May 2020 20:17:42 +0000 (UTC) X-Session-Marker: 796F6E69407261626B696E732E6E6574 X-HE-Tag: ball45_8fde0ce2af25 X-Filterd-Recvd-Size: 6412 Original-Received: from birch.rabkins.net (c-73-238-99-162.hsd1.nh.comcast.net [73.238.99.162]) (Authenticated sender: yoni@rabkins.net) by omf18.hostedemail.com (Postfix) with ESMTPA; Mon, 18 May 2020 20:17:41 +0000 (UTC) X-Ethics: Use GNU In-Reply-To: <5de873b7-0157-05ef-8aea-0635ad8a2276@gmail.com> (=?utf-8?Q?=22Cl=C3=A9ment?= Pit-Claudel"'s message of "Mon, 18 May 2020 15:35:53 -0400") Received-SPF: none client-ip=216.40.44.88; envelope-from=yoni@rabkins.net; helo=smtprelay.hostedemail.com X-detected-operating-system: by eggs.gnu.org: First seen = 2020/05/18 16:17:42 X-ACL-Warn: Detected OS = Linux 3.11 and newer X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, URIBL_BLOCKED=0.001 autolearn=_AUTOLEARN X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:250823 Archived-At: Cl=C3=A9ment Pit-Claudel writes: > On 18/05/2020 13.30, Yoni Rabkin wrote: >> 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.) > > There is a bit of quality control, at package submission time (things reg= arding proper API documentation, proper namespacing, etc. =E2=80=94 but not= hing like tests, indeed). > I think the way they display thing isn't much different from what you > get with "apt-cache rdepends" on a Debian system (it's not the same as > the `Recommends: mpg321` or `Suggests: mp3info` lines that `apt` shows > when I ask it `apt show emms`, for example). > >>>> * 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-package= s: >>> >>> Homepage: https://www.gnu.org/software/emms/ >>> >>> The MELPA website links to the git repository instead. >>=20 >> Yes, that was what I was referring to. > > Good point; I opened a ticket about this. thank you >>>> * 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. >>=20 >> 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. > > The package manager that comes by default in Emacs 24+ is able to > produce ELC and info files automatically, so packages typically don't > ship Makefiles. Additionally, it makes certain assumptions about > archive layout that EMMS' releases currently don't abide by; that's > why MELPA has recipes. > Distributing through ELPA would require the same modifications: this is j= ust the way package.el works.=20 > >>> 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. >>=20 >> Why does Emms need to be offered through three different channels at the >> same time? >>=20 >> Ideally, I would contact the MELPA bug tracker and have Emms removed >> from MELPA, since it can be trivially downloaded from a GNU server > > Downloading it from a GNU server is very complicated, compared to > installing it through MELPA. I personally disagree, but since people have asked me to make Emms available via ELPA I'm disregarding my personal opinion on the matter. >> and will hopefully soon be installable via ELPA. > > I hope you can put it in ELPA; that would be even better. Yes, that is the goal. >> 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. > > This is not how it will work: EMMS was one of the earlier packages to > be included in there, before there was a policy to keep maintainers in > the loop. Today, it wouldn't be included without asking. > >> 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. > > No worries. The short summary is that MELPA doesn't take an > adversarial approach, so if you ask for your package to be removed, it > will be removed. But please don't, not before putting it on ELPA =E2=80= =94 it > will break many users' configurations, since emms is rather popular > there. Once it is on ELPA, would that make the MELPA version redundant? Are packages duplicated across ELPA and MELPA? If so, why? > Do you keep statistics for your web server? It would be useful to > compare how many people install through MELPA and how many download > releases directly. Emms is hosted on Savannah, and I'm guessing that GNU/Linux distribution grab copies of the release version from Savannah/GNU servers as well, so even if we had those numbers, I wouldn't know how to make sense of them. --=20 "Cut your own wood and it will warm you twice"