From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: =?UTF-8?Q?Cl=c3=a9ment_Pit-Claudel?= Newsgroups: gmane.emacs.devel Subject: Re: "Write a new package" culture instead of patches? Date: Mon, 18 May 2020 15:35:53 -0400 Message-ID: <5de873b7-0157-05ef-8aea-0635ad8a2276@gmail.com> References: <83tv0e9x14.fsf@gnu.org> <83blml9u2t.fsf@gnu.org> <87v9ktb73s.fsf@rabkins.net> <800432c5-2f72-3c29-7399-c6f1f559d983@gmail.com> <87imgtb17b.fsf@rabkins.net> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="101376"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 Cc: emacs-devel@gnu.org To: Yoni Rabkin Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon May 18 21:39:28 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 1jalbj-000QEy-Cy for ged-emacs-devel@m.gmane-mx.org; Mon, 18 May 2020 21:39:27 +0200 Original-Received: from localhost ([::1]:53396 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jalbi-0007xB-FA for ged-emacs-devel@m.gmane-mx.org; Mon, 18 May 2020 15:39:26 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:55202) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jalYM-0005PG-BE for emacs-devel@gnu.org; Mon, 18 May 2020 15:35:58 -0400 Original-Received: from mail-qv1-xf41.google.com ([2607:f8b0:4864:20::f41]:37143) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jalYK-0002DO-Mk for emacs-devel@gnu.org; Mon, 18 May 2020 15:35:57 -0400 Original-Received: by mail-qv1-xf41.google.com with SMTP id z5so5321799qvw.4 for ; Mon, 18 May 2020 12:35:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=MqmN0Hgxwjd5Kenea2rvmxYr/Sq+SSYFeoaVn9VxEDw=; b=OYp3HodxRod+EkxgfEWwqG3uM6hv/7e2UepAIJTedvncruMQ1VAtbRdgf91BC/qlMw VcDDPi0YaDrq3X7eFIaUDcRsXeZSfoM5/FXO8Pyxv3SAmsLBYkpAUwwzpVFdrhXoPxhb BTT3/qy7TV5Q3Rlixb2PS6zNL80sJSfXZJzlpyWvpzcF3hUga6OOoCO05b7BoXQ7q25N bA+VCoPKryAXsYaglyH9sFUnNvAwgNvs86ZEcxFlbyqVMXFdT15R5SAmIt31s65+h6Qj W+3lH+aI9h7Mxa+glMnllAItzo7inIFkd/WLAAQbgDUUz+hBNNkHMN3hjJPqqwZbO4Ar 90ww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=MqmN0Hgxwjd5Kenea2rvmxYr/Sq+SSYFeoaVn9VxEDw=; b=dUdyCKxiAdLfasAjHc+uXO7xuirrUy21PH1d88CyMBzHD/C8HUIGNaCO0fSvMvX8xb 79Lq8D/pJvJny0677EHv36xRXKfKuPFsPXVce6Q+0jcNyajLVl9Pe6HnoGppNMkhzodn A9NzzyTSGtC4qcEcx2Hk6r3SQUPyvmYrrGB/EMK4wKf8S5jnsVUcQf5d8xXPULgAuavw tPaAi8/NamhTzD7WWM0xmHjfBN5lIy1tHn56jrhiGNeFiKbzzSg/AXDE5I0zvzpAQv3U qJdL4I0WBE2W3P0cHm84c7dzJllPF4hgMYeXTcg3pP3ZgSqfI77ZhZvpnbtSdbHUl9Ol NNVg== X-Gm-Message-State: AOAM530DSVMPufj6Rd74icgEhnevYBhaXslZB/gaONLG8lielg6nz2Pj 0TcQK8e4knwwb/j6m/9eem0k1W/c X-Google-Smtp-Source: ABdhPJxSzNAvC9GTUkZyN/O3buAyYmg+nqfb7v2+LJvBXrAomv7i5J1BQkC647kP0uRtls+G0+nnEA== X-Received: by 2002:a0c:e488:: with SMTP id n8mr6750616qvl.172.1589830555166; Mon, 18 May 2020 12:35:55 -0700 (PDT) Original-Received: from ?IPv6:2601:184:4180:66e7:bda5:ac5c:1de0:b677? ([2601:184:4180:66e7:bda5:ac5c:1de0:b677]) by smtp.googlemail.com with ESMTPSA id u41sm6205756qte.28.2020.05.18.12.35.54 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 18 May 2020 12:35:54 -0700 (PDT) In-Reply-To: <87imgtb17b.fsf@rabkins.net> Content-Language: en-GB Received-SPF: pass client-ip=2607:f8b0:4864:20::f41; envelope-from=cpitclaudel@gmail.com; helo=mail-qv1-xf41.google.com X-detected-operating-system: by eggs.gnu.org: No matching host in p0f cache. That's all we know. X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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:250814 Archived-At: 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 regarding proper API documentation, proper namespacing, etc. — but nothing 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-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. Good point; I opened a ticket about this. >>> * 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. 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 just the way package.el works. >> 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 Downloading it from a GNU server is very complicated, compared to installing it through MELPA. > and will hopefully soon be installable via ELPA. I hope you can put it in ELPA; that would be even better. > 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 — it will break many users' configurations, since emms is rather popular there. 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.