From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Konstantin Kharlamov Newsgroups: gmane.emacs.devel Subject: Re: Why are so many great packages not trying to get included in GNU Emacs? WAS: Re: Making Emacs more friendly to newcomers Date: Sat, 13 Jun 2020 14:59:21 +0300 Message-ID: <4923d7e98f5ed816a7569093dbc673153adcea88.camel@yandex.ru> References: <863691n4xl.wl-me@enzu.ru> <87imhw431x.fsf@yahoo.com> <87mu78huhx.fsf_-_@yahoo.com> <87k12bdgx7.fsf@yahoo.com> <87r1wi7a8o.fsf@yahoo.com> <875zdteybt.fsf@runbox.com> <87368wrvf5.fsf@yahoo.com> <86k126d83n.wl-me@enzu.ru> <83pnbyckvv.fsf@gnu.org> 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="129804"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Evolution 3.36.3 To: Stefan Kangas , Eli Zaretskii , Emacs developers Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Jun 13 14:07:13 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 1jk4wK-000XgB-Vx for ged-emacs-devel@m.gmane-mx.org; Sat, 13 Jun 2020 14:07:13 +0200 Original-Received: from localhost ([::1]:55172 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jk4wK-00042L-25 for ged-emacs-devel@m.gmane-mx.org; Sat, 13 Jun 2020 08:07:12 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:48264) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jk4vT-0003Xr-KN for emacs-devel@gnu.org; Sat, 13 Jun 2020 08:06:19 -0400 Original-Received: from forward106o.mail.yandex.net ([2a02:6b8:0:1a2d::609]:33736) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jk4vP-0003hR-8d; Sat, 13 Jun 2020 08:06:18 -0400 Original-Received: from mxback1j.mail.yandex.net (mxback1j.mail.yandex.net [IPv6:2a02:6b8:0:1619::10a]) by forward106o.mail.yandex.net (Yandex) with ESMTP id 54FB25060B2B; Sat, 13 Jun 2020 14:59:24 +0300 (MSK) Original-Received: from myt5-aad1beefab42.qloud-c.yandex.net (myt5-aad1beefab42.qloud-c.yandex.net [2a02:6b8:c12:128:0:640:aad1:beef]) by mxback1j.mail.yandex.net (mxback/Yandex) with ESMTP id TaGPHewzYH-xN8qdx5M; Sat, 13 Jun 2020 14:59:24 +0300 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1592049564; bh=hE1eTlYD4AD6Nb/NFaOCiRtjlDcc6Y5UvuzJtk/I1oQ=; h=In-Reply-To:To:From:Subject:References:Date:Message-ID; b=v4/RZ532XwOu1ZDbKBfM1F8HEQvvTp89TE0cxHS7zIMSX9R+4BpWi4RX4Dxi6YxQJ Z7zb1FL1C3KbuVEhV5J9cNRrnvaDTgoYnZpGG75HXnVmU2r4Y+rkOys0SIRcJI/PeQ vAP/m8z9EzucfWLVrHUY0w/f3c2VVNSgtcLb5RyQ= Authentication-Results: mxback1j.mail.yandex.net; dkim=pass header.i=@yandex.ru Original-Received: by myt5-aad1beefab42.qloud-c.yandex.net (smtp/Yandex) with ESMTPSA id O7VIwnRHmn-xMpOED9X; Sat, 13 Jun 2020 14:59:23 +0300 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (Client certificate not present) In-Reply-To: Received-SPF: pass client-ip=2a02:6b8:0:1a2d::609; envelope-from=hi-angel@yandex.ru; helo=forward106o.mail.yandex.net 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_HELO_NONE=0.001, 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:252160 Archived-At: On Thu, 2020-04-23 at 19:07 +0200, Stefan Kangas wrote: > Eli Zaretskii writes: > The reasons why package authors would not want to include it, on the > other hand, > could obviously vary. Some of the reasons I have seen are > unfortunately very shallow: > > - Misconceptions about how hard it is to work with emacs-devel. Hello! As someone who does not contribute to Emacs for the sole reason it is *way* harder than in any other project I'm aware of (although well in line with other GNU projects, but even among them Emacs takes the lead) I want to emphasize this is not a "shallow reason". It all comes down to Emacs development not being automated. Which puts down too much strain on contributors (not mentioning Emacs maintainers here, because last time this discussion happened (1.5 year ago I think), Eli ensured me that they are okay. Fair enough: I'm not a Emacs maintainer, not gonna speak for them). 1. There are many wrong ways to send a patch; and the correct one is the most non-obvious. Most popular mistakes I think come down to copy- pasting the patch into email client. Most modern email clients require lots of tinkering before they work fine with plain text, otherwise they'll screw patch up in various ways (breaking lines, replacing whitespace, removing whitespace, you name it). Okay, so usually email-based projects recommend using git-send- email. Recently I sent a patch like this¹ and got a complaint it doesn't look like what git-format-patch would produce (is that maybe a hint maintainers are being strained too?). Huh, wrong way again? I'll give you some examples so you'd see the format looks exactly what other email-based project use/used: one from Mesa project² (well, before they moved over to Gitlab-based development) and another one from kernel³. What's the correct way? Well, apparently it is either to combine in some way git-send-email and git-format-patch, or it is to attach a patch to email. "To attach", who would've thought? Attaching patches is frowned upon in all other email-based projects because it is hard to review it, Idk why Emacs even allows that… Okay, let's get back to all those "great packages not included in Emacs": YOU CAN NOT SEND THEM PATCH WRONG. Sorry for caps, I want to make sure it is visible: there is no way I'll send a patch, say, to company-mode, and will get a reply "Dude, your patch does not apply here"! They use either (open-source btw) Gitlab or (proprietary) Github. You can use command line or web-browser to send patches — either way, it all becomes a thing called merge/pull request, and making sure it is correct is all automated. Zero efforts from package maintainers or contributors. 2. Unusual requirements from commit messages: no other projects require writing down a list of functions I changed just for the fun of it. This is what there diff is for! Let me guess where the requirement came from: I remember seeing that Emacs maintainers accept even patches with a bunch of unrelated changes, like 1. renaming a variable, 2. refactoring a code, 3. adding a new feature. No serious project would accept such patches, but apparently Emacs decided to hack that around, and are instead requiring that people write down each function name and its change in commit message. Okay, you want this — but could you at least automate it! And no, some Emacs function does not cut it, people not necessarily use git from Emacs. I personally don't. Please, use git hoooks, because this is what everyone is *forced* to use, you can't possibly miss a git hook. And please, make sure that when people do git-commit-amend, the function names are updated accordingly. Full automation, to make sure this unusual unique requirement of Emacs development stays as unobtrusive as possible. 3. FSF assignment: yeah, it is easy to get. But as a package maintainer, would I want more contributions or only having code from elite members of FSF? I'd go for the former. If some package user found some corner case in a function in my package and wants to contribute it now, and I stop them "go assign some copyright and don't appear at my project without that", this is a punch into motivation. They may do it or not, it depends. 4. Patches are discussed on a bugtracker. Good news: contributors probably won't care. Bad news: as a package maintainer I'd not want to give up my abilities to 1. Close outdated discussions 2. See the diff between current and previous patchset version 3. Immediately see which patchset is the current version. 4. Automatically run CI on the new uploaded version of the patchset. 5. Immediately merge the patchset once I'm fine with the changes. 5. As a contributor, when I stumble upon a bug I could fix in software, first thing I usually do is go check it is not fixed in latest code and that there's no pending merge/pull requests that seem to fix that same thing. So, for example, I want to see pending patchsets to python-mode, can I do that with Emacs "bug-patch-tracker"? No, with debbugs.gnu.org you can either find pending patchsets, or you can make a text search, but over everything: bugs, patchsets, closed or not… P.S.: I have a feeling, people on Emacs-devel don't consider these to be anything but nuance. Well, I've got FSF assignment for contributing to Emacs, and since then I have many times stumbled upon things I could try to improve. But every time it happens, I remember how hard it is to contribute here, and dismiss myself with "no, not worth it". The patch from two weeks ago¹ was the exception just because when I stumbled upon that problem, I immediately figured it is likely a one-liner fix. As it currently stands, I'd strongly recommend against moving packages from gitlab/github to Emacs upstream. 1: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=41684 2: https://lists.freedesktop.org/archives/mesa-dev/2018-December/210803.html 3: https://lists.gt.net/linux/kernel/3588040