From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Philip Kaludercic Newsgroups: gmane.emacs.devel Subject: Re: [nongnu] main 74116339a8 2/3: * elpa-packages (anzu): New package Date: Sun, 16 Jan 2022 17:49:05 +0000 Message-ID: <87mtjvd10u.fsf@posteo.net> 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 Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="1435"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Stefan Kangas Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Jan 16 18:51:05 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 1n99gG-00008d-V1 for ged-emacs-devel@m.gmane-mx.org; Sun, 16 Jan 2022 18:51:05 +0100 Original-Received: from localhost ([::1]:55922 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1n99gF-00027t-LH for ged-emacs-devel@m.gmane-mx.org; Sun, 16 Jan 2022 12:51:03 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:35074) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1n99eT-0001Rt-3Y for emacs-devel@gnu.org; Sun, 16 Jan 2022 12:49:13 -0500 Original-Received: from mout01.posteo.de ([185.67.36.65]:41607) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1n99eQ-0008W8-G3 for emacs-devel@gnu.org; Sun, 16 Jan 2022 12:49:12 -0500 Original-Received: from submission (posteo.de [89.146.220.130]) by mout01.posteo.de (Postfix) with ESMTPS id 5D517240028 for ; Sun, 16 Jan 2022 18:49:07 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1642355347; bh=rL4TtzWWRRN+ysn9Q0YlPFjQ6HUWNj7s9eS1Nrl0I6Y=; h=From:To:Cc:Subject:Autocrypt:Date:From; b=XZAyG2c/Eony/wx+RmyUh+4MC73Eb3XawCogQzjnDjJr/UX6bj4fJImn/eeI9+hi3 7YbW2ECwTe+jxOFYmIoHHUG01+VJTGqYGxY4/0wbvTX3Z7lbTdiwr+7lJKwGV+tyz2 HGl9o5db4VLsrcVvz0qtvfh+muJGfwtpECcA++rP96ZystcDPytxc37iNifGx2H9W9 o7LPgZZIhsirRpbQzormcyJPpJ4jq3EB52te7K8+mRi+iHd5m5XnTSbuXmlV6Hhcph SjBzUtBtiXvOEpDvOPbuvO3edvaREq2fbd9Bs9ZW9kFdpOI849sVyod6Fh4r8OlaPD udGlvL0q1bqCQ== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4JcMwf4vhlz9rxN; Sun, 16 Jan 2022 18:49:06 +0100 (CET) Autocrypt: addr=philipk@posteo.net; prefer-encrypt=nopreference; keydata= mDMEYHHqUhYJKwYBBAHaRw8BAQdAp3GdmYJ6tm5McweY6dEvIYIiry+Oz9rU4MH6NHWK0Ee0QlBo aWxpcCBLYWx1ZGVyY2ljIChnZW5lcmF0ZWQgYnkgYXV0b2NyeXB0LmVsKSA8cGhpbGlwa0Bwb3N0 ZW8ubmV0PoiQBBMWCAA4FiEEDM2H44ZoPt9Ms0eHtVrAHPRh1FwFAmBx6lICGwMFCwkIBwIGFQoJ CAsCBBYCAwECHgECF4AACgkQtVrAHPRh1FyTkgEAjlbGPxFchvMbxzAES3r8QLuZgCxeAXunM9gh io0ePtUBALVhh9G6wIoZhl0gUCbQpoN/UJHI08Gm1qDob5zDxnIHuDgEYHHqUhIKKwYBBAGXVQEF AQEHQNcRB+MUimTMqoxxMMUERpOR+Q4b1KgncDZkhrO2ql1tAwEIB4h4BBgWCAAgFiEEDM2H44Zo Pt9Ms0eHtVrAHPRh1FwFAmBx6lICGwwACgkQtVrAHPRh1Fw1JwD/Qo7kvtib8jy7puyWrSv0MeTS g8qIxgoRWJE/KKdkCLEA/jb9b9/g8nnX+UcwHf/4VfKsjExlnND3FrBviXUW6NcB In-Reply-To: (Stefan Kangas's message of "Fri, 7 Jan 2022 01:55:28 -0600") Received-SPF: pass client-ip=185.67.36.65; envelope-from=philipk@posteo.net; helo=mout01.posteo.de X-Spam_score_int: -43 X-Spam_score: -4.4 X-Spam_bar: ---- X-Spam_report: (-4.4 / 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, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham 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:284840 Archived-At: Stefan Kangas writes: > 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.) Interesting idea, though it should probably be opt-in, at the risk of skewing the popularity data towards enthusiasts. Just one thing: It seems like this would either require a special server or to scrub the server logs. Is either of that feasible? > 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. Would also be nice. >> 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. If we have Evil, it seems necessary to add some of extensions, as Evil appears to not be complete on it's own. But as this is an entire package-space onto itself, I am uncertain which of these are actually being used and which are obsoleted by either other evil-specific packages, other general packages or even features in Emacs. > 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 might not be bad to collect these notes somewhere. I also have my private notes, and if more people want to contribute, being able to quickly check what the status of a package is (waiting for a patch to be applied, obsoleted, ...) would be useful. >> 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. Most of the packages certainly are good and appreciated additions, and would have liked to help if I had more time. >> 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. What do you mean by this? > 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). What difference would this make? I agree that it would be preferable, but a tone for what packages are added to NonGNU ELPA can already be set. On the topic of critical mass: It might be possible to spread NonGNU ELPA via compat (https://git.sr.ht/~pkal/compat), as soon as it is released. It seems that there is already some interest in using this package, most notably from transient. But as the package is already borderline heretical, I hesitate to do something like this (the same applies to updating the default rcirc and erc server lists). -- Philip Kaludercic