From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.devel Subject: Re: "Write a new package" culture instead of patches? Date: Mon, 18 May 2020 20:50:36 +0300 Message-ID: <5e635400-0d5c-7bce-5e87-6c1812aa83ed@yandex.ru> 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; format=flowed Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="124750"; 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 , =?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:51:14 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 1jajuz-000WHj-4V for ged-emacs-devel@m.gmane-mx.org; Mon, 18 May 2020 19:51:13 +0200 Original-Received: from localhost ([::1]:42164 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jajuy-00077N-74 for ged-emacs-devel@m.gmane-mx.org; Mon, 18 May 2020 13:51:12 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:41948) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jajuV-0006hS-Qa for emacs-devel@gnu.org; Mon, 18 May 2020 13:50:43 -0400 Original-Received: from mail-wm1-x32c.google.com ([2a00:1450:4864:20::32c]:53438) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jajuU-0000rC-FU for emacs-devel@gnu.org; Mon, 18 May 2020 13:50:43 -0400 Original-Received: by mail-wm1-x32c.google.com with SMTP id k12so380471wmj.3 for ; Mon, 18 May 2020 10:50:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=hBXA3xGcUCaxU95jRnlXQSStXaKK6xuG3NRKDCoL3kQ=; b=Yo91RGwq3fFGqCCAZCejnFeNAWqejr47ctr2KmPDyzut7xzPZhC/HomAvxYVHStFCz xWMkBOTthdZPwLyGvX72Fk3GQem4Wx8rz9BoxSyVVfjzZM38lNZgHqXowvIaXR8k/K58 lmH6kUvXEcDIk8aI1Ov1awFcEjidqpbYbIA/BK+0Qz0ftPtST1mZyJn2YVklhBdHQRgd Gd6+492WGT+6zII7qP+1DzzzvE2+O4t95dUTtYegSUAyaSGlTlNjePq7tIBXtcobMrFz fcmOY7icOfIF/rECM/nhzZf4Lr6ZS3+PavGCGJj0xQIqKG/Jm5IhpgTrze8bFh+UiEW7 dKZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=hBXA3xGcUCaxU95jRnlXQSStXaKK6xuG3NRKDCoL3kQ=; b=IIPr0pCg9gxGyTtOz/mQpLdb6eoUmodCISYdW9h2p2ckcLUyKuZP2zoaBKIBqFjuCF 7bRujeO3buPS2ZV8JbvqmP6QmmkCWNun0DC+OtIctQ3ZBddLKMzJjCuvxDdx+Jda6gzG 5/tWD5+sacrJFn2GXj2LylXBXtxz/QCyCk83pL+mqAsiwrqasbNkvQe+vUreIpvFDXwM X/GrHI0AEufbztiYjp3suw9TDKR7ka+slBghbaH+UPWuLoXlZ2pLHhKSKS3Sm8foNuuY qL5gUfPmj8ceEUed1gLnseSsB7R+0eViMpWPXmm6meZJbMgjv+MxRpofWJkkXGJCtejy x12Q== X-Gm-Message-State: AOAM532LXQhwnzF9mJozyIiX/xh5+JnaKtLHpeBgXRZcHk9h+B+292Y6 xy8WtLUUumah/tnKSdMh40JBwXk8 X-Google-Smtp-Source: ABdhPJy99umO/erdcjuWpzIqAfU0qsVCuIw/pQtq7yy7W8kgVSIoVSZZJhO8CvSZ0CE5Dt6Q7MDDiw== X-Received: by 2002:a7b:ce01:: with SMTP id m1mr542083wmc.116.1589824240691; Mon, 18 May 2020 10:50:40 -0700 (PDT) Original-Received: from [192.168.0.3] ([66.205.73.129]) by smtp.googlemail.com with ESMTPSA id c140sm393825wmd.18.2020.05.18.10.50.39 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 18 May 2020 10:50:40 -0700 (PDT) In-Reply-To: <87imgtb17b.fsf@rabkins.net> Content-Language: en-US Received-SPF: pass client-ip=2a00:1450:4864:20::32c; envelope-from=raaahh@gmail.com; helo=mail-wm1-x32c.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: -16 X-Spam_score: -1.7 X-Spam_bar: - X-Spam_report: (-1.7 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, 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:250795 Archived-At: On 18.05.2020 20:30, Yoni Rabkin wrote: >>> * 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.) People just learn to understand that different packages usually means different authors, and having the prefix emms- on many packages has little bearing on your reputation. > 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. That is because the main package file doesn't follow the ELPA standard of having it commentary describe the whole package. See the "Description" on the MELPA site. The area can host a more thorough description if you make it so. >>> * 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. And that is because, I'm guessing, your main package file doesn't have the "Homepage" header. >> 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. >> >> … 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. The above are guidelines for when a package recipe is submitted. Once it's submitted, the package simply continues to be distributed. Unless someone raises an issue, proposes a better recipe, etc. >>> * 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. Yes: MELPA uses "recipes" (files with data in particular format) to automate distribution. >>> 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. Surely you care about the users' convenience at least a little? >> 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? I don't know, really. You could keep the most popular one. Do you have any download stats for the last year? Or since 2012? > 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. I'm fairly sure that if you demand to be removed, they will do so. Doing that would punish existing users, however. So I can hardly understand the reasons for doing so.