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, 20 Jun 2020 21:04:23 +0300 Message-ID: References: <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> <4923d7e98f5ed816a7569093dbc673153adcea88.camel@yandex.ru> <874krex73o.fsf@gmail.com> <87eeqctgb4.fsf@elephly.net> <83wo43xom6.fsf@gnu.org> <83r1u9vnr3.fsf@gnu.org> <09632e8ec343ddee558b18f811ef6da77e594f55.camel@yandex.ru> <83pn9tvhta.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="38687"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Evolution 3.36.3 Cc: rekado@elephly.net, emacs-devel@gnu.org, stefan@marxist.se, joaotavora@gmail.com, dgutov@yandex.ru To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Jun 20 20:05:26 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 1jmhrp-0009wJ-OD for ged-emacs-devel@m.gmane-mx.org; Sat, 20 Jun 2020 20:05:25 +0200 Original-Received: from localhost ([::1]:55338 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jmhro-0006pw-Qt for ged-emacs-devel@m.gmane-mx.org; Sat, 20 Jun 2020 14:05:24 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:57450) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jmhr5-00069p-Ee for emacs-devel@gnu.org; Sat, 20 Jun 2020 14:04:39 -0400 Original-Received: from forward103o.mail.yandex.net ([2a02:6b8:0:1a2d::606]:38258) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jmhr1-0001QH-Kh; Sat, 20 Jun 2020 14:04:39 -0400 Original-Received: from mxback8j.mail.yandex.net (mxback8j.mail.yandex.net [IPv6:2a02:6b8:0:1619::111]) by forward103o.mail.yandex.net (Yandex) with ESMTP id EF1C15F80503; Sat, 20 Jun 2020 21:04:25 +0300 (MSK) Original-Received: from iva3-dd2bb2ff2b5f.qloud-c.yandex.net (iva3-dd2bb2ff2b5f.qloud-c.yandex.net [2a02:6b8:c0c:7611:0:640:dd2b:b2ff]) by mxback8j.mail.yandex.net (mxback/Yandex) with ESMTP id qyYpxGZcZs-4PUiR8YZ; Sat, 20 Jun 2020 21:04:25 +0300 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1592676265; bh=E7ShPnKbJa++1rVeqmdy9741phyWp+XwvcbXMCEir84=; h=In-Reply-To:Cc:To:From:Subject:Message-ID:References:Date; b=w620Pyz8KL5h6HSOWzXpjVSqoAt+SilwpJxT9vMeM6TiT9hnWiVQj3P39rTWBQpg6 G80VpL72MvjwrVLeNKbM1SPTjrVsj6YTQHK1j7uAqCj1rZzCr+9Z/X6bnPrAg2XnnS Ad400fo8EDM16Pn9zc5kgjcENT4kf8ba6YxZweo0= Authentication-Results: mxback8j.mail.yandex.net; dkim=pass header.i=@yandex.ru Original-Received: by iva3-dd2bb2ff2b5f.qloud-c.yandex.net (smtp/Yandex) with ESMTPSA id 56DnCMWTD3-4OlKBBEE; Sat, 20 Jun 2020 21:04:24 +0300 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (Client certificate not present) In-Reply-To: <83pn9tvhta.fsf@gnu.org> Received-SPF: pass client-ip=2a02:6b8:0:1a2d::606; envelope-from=hi-angel@yandex.ru; helo=forward103o.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:252453 Archived-At: On Sat, 2020-06-20 at 19:10 +0300, Eli Zaretskii wrote: > > From: Konstantin Kharlamov > > Sounds reasonable. I'd like to see those discussions though to understand > > the > > background, and maybe even participate in them. Do you have any reference? > > They are scattered across different mailing lists (and across many > months), but you can find many of them on bug-standard@gnu.org and on > gnu-prog-discuss@gnu.org. Thanks, I'll look at it. > > My point is the functions list is not necessary for having good > > commit messages. > > Our experiences are different, then. I find them very important in at > least some cases. Right. I should mention though, my experience is not specific to myself. Most non-GNU projects (actually, all I have seen) don't require having the list, but do require good commit messages. Peter Hutterer, a libinput and kernel HID subsystem maintainer wrote a good blog-post in 2009 on commit messages, and this too did not include having the list http://who-t.blogspot.com/2009/12/on-commit-messages.html I also don't think GNU projects are any good to make examples of. This is my general experience of seeing how new projects get under GNU umbrella to get never heard of (which I attribute to points listed in my starting mail, since most of them are unspecific to Emacs). But to support this claim regarding GNU, I just did some experiment. I downloaded git repositories of GNU GCC and Clang, and tried to count contributors to last 500 commits. I was interested in seeing the number of occasional contributors. I think that if a project only lives by means of maintainers and paid people, the project pretty much goes down. Maintainers may burn out, paid people will move on. Number of occasional contributors shows how big interest in supporting the development, and they're the ones who at some point may become maintainers too. So, I looked at "author email" fields and removed ones with email addresses that are either clearly corporate or clearly maintainers. Not the most scientific method, I might have missed a few ones who contributed from their personal email, but I don't expect the difference to be statistically significant. So, the command is (I hope my email client won't break it terribly): git log -500 --format="%ae" | grep -vP "@\S*(redhat|arm|suse|google|gnu|adacore|alibaba|intel|ibm|apple|linaro|huawei|c odesourcery|golang|sony|amd|chromium|nvidia|loongson|accesssoftek|ubisoft|micros oft|fb|energize|comstyle|nextsilicon|quicinc|azul|gentoo|graphcore|gdcproject|si five)\.(org|com|de|cz|cn)" | sort -u | wc -l Results are: * GCC as of commit 445d8da5fbd: 15 * Clang as of commit 7b201bfcac2: 49 This is some pretty big difference! If I expand the commits range, the difference increases further. > > This whole thread is dedicated to "why having the list is necessary as > > opposed > > to not having it", and while text explains "why having the list is good" in > > general, but it does not make comparison to not using it. There's no answer > > to > > that question. > > Isn't saying "A is good to have" the same as saying "not having A is > not so good"? It depends. If A is free, then sure. But if I gotta pay for A, then I'd consider my options. > > Again, I don't see why just saying in commit message e.g. "Factor out code > > doing > > X out of all functions", is worse than additionally making the list of those > > functions (or is it a bad example, and you have a better one in mind? Great, > > I > > want to hear it!). > > For repetitive mechanical changes, it might be okay. There's no > argument that some changes don't need detailed lists. The argument is > whether having them in general is helpful. If you are saying that in > some cases they are redundant, then we agree at least in principle > (though we could disagree in specific cases). But if you are saying > they are seldom or never needed or useful, then I disagree, based on > my experience. > > > > I encourage you to talk to Git developers so that they improve this > > > capability. Not sure this is going to happen in practice (knowing how > > > the diffs are generated, and given that one GNU project using Git > > > after another sets up alternative tools for overcoming these > > > problems), but it definitely cannot harm, so by all means go for it. > > > > I might do it, but I need motivation. If I knew this is the only reason > > Emacs > > has requirement for the functions list, thus having such ability in git > > would > > allow to drop this requirement, I'd do it. Right now people seem to prefer > > to > > stick to having the list for other reasons (which are being discussed in the > > text above), so clearly even if git got such ability, it would be of little > > use > > to Emacs. > > It depends how good a job they do. If they do a perfect job, which > will allow generating accurate ChangeLog-formatted entries without > providing the lists of functions in the log messages, then we might > indeed drop the requirement. Okay, I'll ask about it.