From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Kangas Newsgroups: gmane.emacs.devel Subject: Re: [nongnu] main 74116339a8 2/3: * elpa-packages (anzu): New package Date: Fri, 7 Jan 2022 01:55:28 -0600 Message-ID: References: <164145738158.2838.5769558384331859964@vcs2.savannah.gnu.org> <20220106082302.0A19CC0DA1E@vcs2.savannah.gnu.org> <87k0fdmbat.fsf@posteo.net> <87tueh3s2x.fsf@posteo.net> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="27420"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Philip Kaludercic Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Jan 07 08:57:13 2022 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 1n5k7d-0006uV-OV for ged-emacs-devel@m.gmane-mx.org; Fri, 07 Jan 2022 08:57:13 +0100 Original-Received: from localhost ([::1]:37272 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1n5k7c-0001T9-EW for ged-emacs-devel@m.gmane-mx.org; Fri, 07 Jan 2022 02:57:12 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:34860) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1n5k60-0007mw-3F for emacs-devel@gnu.org; Fri, 07 Jan 2022 02:55:32 -0500 Original-Received: from mail-pf1-f170.google.com ([209.85.210.170]:41541) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1n5k5y-0002Sc-DG for emacs-devel@gnu.org; Fri, 07 Jan 2022 02:55:31 -0500 Original-Received: by mail-pf1-f170.google.com with SMTP id m1so4551431pfk.8 for ; Thu, 06 Jan 2022 23:55:30 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=jejpsLiFsD2NwjK9I1fhPxgHpIzYHnU1+3R1WblGEXc=; b=ushi9myAk8izr1E6hmEIS9HaATNEgUus9BF/CieN/VG9BxhJ6XhBZVGsqQE381Igud ZvR890d5KNPBdfaNXxXZiNPIENUeEFh5nAa4dnsZd3styweO4L+QgCgU/iiRcmnEy6U0 KO1ajtlei+WM8r87pNQ4hLGwRW/MJBBVLU8kteRp8Gh+qStFERWv6yF9tRSKprnpt9qM iy2Xdf6LYtT4thM7iK0LsTp7iNYjlXebrNJnDdrecpYcC+DdFUlvWxoTu9F2uVQGKWC6 xW8Uxt+RDPGY/23vNd0JqOJ+0h21EhQIaIrdNy/AmnFAuFmPrqEva9cptZwhg265pa5P qg/g== X-Gm-Message-State: AOAM5336u6NeiuYjpPgUXhKBaW5EjdFFicZxIAcVgP4+ped6ifT1XFE0 pf4OrcwKaMdifwxA1T4XTjltA1i14A8JP3W1AW4= X-Google-Smtp-Source: ABdhPJyPjP959UqufIUDaGhqi2XGIa2s7AqJhhm4eIwXL+DkUMr05CUKHqRbyXiqRqmDZazjoXixzCqxsF8OEfmHKbo= X-Received: by 2002:a63:5d41:: with SMTP id o1mr54731795pgm.325.1641542128919; Thu, 06 Jan 2022 23:55:28 -0800 (PST) Original-Received: from 753933720722 named unknown by gmailapi.google.com with HTTPREST; Fri, 7 Jan 2022 01:55:28 -0600 In-Reply-To: <87tueh3s2x.fsf@posteo.net> Received-SPF: pass client-ip=209.85.210.170; envelope-from=stefankangas@gmail.com; helo=mail-pf1-f170.google.com X-Spam_score_int: -13 X-Spam_score: -1.4 X-Spam_bar: - X-Spam_report: (-1.4 / 5.0 requ) BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 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:284381 Archived-At: Philip Kaludercic writes: > I think this might be worth discussing. The impression I get is that a > lot of packages/libraries are not being used because they are better, Agreed. > The "danger" is that MELPA might give the wrong impression of > popularity: Yes, I see the same problems and hope that we will eventually be able to do better on (Non-)GNU ELPA (and I hope MELPA will, too)! For example, we could show download count in the last 12 months in addition to the total downloads. If we could add a "?major-version=28.1" to the URL or somesuch, we could even start counting downloads per major version. (Though I'm not sure if there are any privacy implications, or if it should be opt-in or opt-out.) I also think we should have a "rating" system in place, which should also somehow include information on which version/date the user rated the package in. > Do we want to collect as many packages as possible, even if the > implementations and practices are sub-optimal, are displaced by > alternative implementations in Emacs or ELPA, etc. or should we try to > restrict the packages to popular, "good citizens" of the Emacs package > space, in an effort to raise the standards and clean up "obsolete" and > "redundant" packages. It is probably clear that I have an inclination > towards the latter position: Going forward it seems preferable to have > as many useful and idiomatic packages available directly via the ELPAs, > without burdening newcomers with duplicate functionalities. My > motivation in contributing to NonGNU ELPA is to further this goal. I basically agree. I won't be adding redundant or novelty packages myself -- unless I do it by mistake! -- but there is also some balance: I don't want to impose my opinions on everyone else. So when it comes to "evil-*" packages, I feel like I did my part by adding the 10-15 most downloaded ones on MELPA. I don't use evil, so I have no other criteria to go by, really. But when it comes to packages I do use, like ace-jump, I noticed that it had been superseded by avy. So I added this to my private NGE notes: *** Packages not to add - ace-jump: seems superseded by avy (in GNU ELPA) I'm not sure if we should have a public record of packages we decide *not* to add. If we did, one place to put it would be just directly `nongnu/elpa-packages` itself, in the regular alphabetical order, which is a place you're less likely to forget looking in. > It seems to me that MELPA leans > towards completeness, adding anything from serious packages to fun and > jokes. I think we should take the middle ground: let's not *only* add the most technically sound and excellent packages, because you'll end up with a lot of stuff that is actually used by people that won't make the cut. But let's also steer clear of the obvious low effort/patch/bad/novelty/obsolete/unmaintained packages. I *hope* that in general you will find that my additions have been balanced, but please point out if you see any examples (such as anzu) that you think we could discuss. > While I do understand the motivation/advantages, it appears to > fuel the "there is a package for that" mentality (parallel to Apple's > "there is an app for that"-slogan), that implies to download a package > for every little change, instead of writing or even copying some Elisp. [snip] > (From what I remember you were intending to present a talk on a related > topic at EmacsConf last year, right?) Correct. Unfortunately, I had two consecutive colds and couldn't make it. But as you can imagine, I strongly agree with you. ;-) I am not against any efforts in this direction, of course, and I would welcome any kind of initiative to do "community outreach" here. However, I think the place when we can really start doing such work is when people start coming to *us* to ask to be added, and not the other way around. This will happen eventually, I think, but we have a bit of an up-hill battle to get the first critical mass (getting Emacs 28, 29, 30 out the door will help of course).