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 13:30:16 -0400 Message-ID: <87imgtb17b.fsf@rabkins.net> References: <83tv0e9x14.fsf@gnu.org> <83blml9u2t.fsf@gnu.org> <87v9ktb73s.fsf@rabkins.net> <800432c5-2f72-3c29-7399-c6f1f559d983@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="26687"; 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 19:31:09 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 1jajbY-0006mi-DM for ged-emacs-devel@m.gmane-mx.org; Mon, 18 May 2020 19:31:08 +0200 Original-Received: from localhost ([::1]:35708 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jajbX-0000D7-Eh for ged-emacs-devel@m.gmane-mx.org; Mon, 18 May 2020 13:31:07 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:38748) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jajam-00083l-Tl for emacs-devel@gnu.org; Mon, 18 May 2020 13:30:20 -0400 Original-Received: from smtprelay0073.hostedemail.com ([216.40.44.73]:41072 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 1jajal-0003Ib-R0 for emacs-devel@gnu.org; Mon, 18 May 2020 13:30:20 -0400 Original-Received: from filter.hostedemail.com (clb03-v110.bra.tucows.net [216.40.38.60]) by smtprelay05.hostedemail.com (Postfix) with ESMTP id 77A3A18021BB1; Mon, 18 May 2020 17:30:18 +0000 (UTC) X-Session-Marker: 796F6E69407261626B696E732E6E6574 X-HE-Tag: sound18_29a6945af035 X-Filterd-Recvd-Size: 7047 Original-Received: from birch.rabkins.net (c-73-238-99-162.hsd1.ma.comcast.net [73.238.99.162]) (Authenticated sender: yoni@rabkins.net) by omf05.hostedemail.com (Postfix) with ESMTPA; Mon, 18 May 2020 17:30:17 +0000 (UTC) X-Ethics: Use GNU In-Reply-To: <800432c5-2f72-3c29-7399-c6f1f559d983@gmail.com> (=?utf-8?Q?=22Cl=C3=A9ment?= Pit-Claudel"'s message of "Mon, 18 May 2020 12:33:56 -0400") Received-SPF: none client-ip=216.40.44.73; envelope-from=yoni@rabkins.net; helo=smtprelay.hostedemail.com X-detected-operating-system: by eggs.gnu.org: First seen = 2020/05/18 13:30:18 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:250789 Archived-At: Cl=C3=A9ment Pit-Claudel writes: > On 18/05/2020 11.22, Yoni Rabkin wrote: >> I'm the maintainer of GNU/Emms (a media player for Emacs). The people >> who distribute Emms on MELPA do a poor job of it (see below), and have >> never communicated with us, the Emms developers about it (not even >> once). I only discovered about it by chance recently when I went out to >> figure out what M/ELPA is, and how I can add Emms to ELPA. >>=20 >> What the MEPLA people are doing that I don't like: > > I think you're a bit harsh with the MELPA folks. EMMS was added to > MELPA eight years ago, back when it was just getting started, so I > wouldn't judge based on that. See below re. contacting package > authors. I apologize for being harsh. I shouldn't have done that. I re-read what I've written below to see if it is harsh. It is opinionated, I don't think it is harsh. If it is harsh, please don't hesitate to point it out. I'll be happy for pointers on how to make my writing more kind. >> * 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.) 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. >> * 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. >> Ideas for improvement: >>=20 >> * Encourage people to speak to the developers of a project before >> packaging it. > > 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. > > =E2=80=A6 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. >> * 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. >> 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. > 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? 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. 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. 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. --=20 "Cut your own wood and it will warm you twice"