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: Sun, 14 Jun 2020 02:00:19 +0300 Message-ID: <7e3969862c2d3f76fc812f4231d95e80e37c4c25.camel@yandex.ru> 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> 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="55347"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Evolution 3.36.3 To: Dmitry Gutov , Stefan Kangas , Eli Zaretskii , Emacs developers Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Jun 14 01:01:53 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 1jkF9s-000EGM-Sj for ged-emacs-devel@m.gmane-mx.org; Sun, 14 Jun 2020 01:01:52 +0200 Original-Received: from localhost ([::1]:50534 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jkF9r-00086I-TL for ged-emacs-devel@m.gmane-mx.org; Sat, 13 Jun 2020 19:01:51 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:34554) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jkF8l-0007G5-SL for emacs-devel@gnu.org; Sat, 13 Jun 2020 19:00:43 -0400 Original-Received: from forward106j.mail.yandex.net ([5.45.198.249]:37574) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jkF8i-0006zz-9r; Sat, 13 Jun 2020 19:00:42 -0400 Original-Received: from mxback8j.mail.yandex.net (mxback8j.mail.yandex.net [IPv6:2a02:6b8:0:1619::111]) by forward106j.mail.yandex.net (Yandex) with ESMTP id E9ADA11A0227; Sun, 14 Jun 2020 02:00:21 +0300 (MSK) Original-Received: from sas2-ee0cb368bd51.qloud-c.yandex.net (sas2-ee0cb368bd51.qloud-c.yandex.net [2a02:6b8:c08:b7a3:0:640:ee0c:b368]) by mxback8j.mail.yandex.net (mxback/Yandex) with ESMTP id fzWmW5frKn-0LWSr3kw; Sun, 14 Jun 2020 02:00:21 +0300 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1592089221; bh=V8nNkEbPl0Rw1jLoPzxMwvw7fMW7nuGYiHrOGKyCrpw=; h=In-Reply-To:To:From:Subject:Message-ID:References:Date; b=VUkLB+3hM/1B1le8CpfiGz1ygTc8bagyJOA4bQVGcO7FjPwvuvIBRH8EXZzuFrIYu Rb1LjNroiN8Q1DdujgVGqHcSJQS7oBFwa7kwjQKKhxgJg3CSYV6bPWucRd2SqjG55P YefRUyml8CGJPTIlJTPxikzTeHMIlwZ0/0JZkpxM= Authentication-Results: mxback8j.mail.yandex.net; dkim=pass header.i=@yandex.ru Original-Received: by sas2-ee0cb368bd51.qloud-c.yandex.net (smtp/Yandex) with ESMTPSA id Nl8Jq6aeUo-0Kja6CbT; Sun, 14 Jun 2020 02:00:20 +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=5.45.198.249; envelope-from=hi-angel@yandex.ru; helo=forward106j.mail.yandex.net X-detected-operating-system: by eggs.gnu.org: First seen = 2020/06/13 19:00:22 X-ACL-Warn: Detected OS = Linux 2.2.x-3.x [generic] [fuzzy] 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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:252216 Archived-At: On Sun, 2020-06-14 at 01:09 +0300, Dmitry Gutov wrote: > On 13.06.2020 22:23, Konstantin Kharlamov wrote: > > > FTR, I am all for having good commit messages. It is IMO a must have for any > > git > > project. But having a list of function names with description for each does > > not > > make one. Instead it should be an overview of what is done, why, and how. > > Having a standard that increases the likelihood of having such a > description in the commit message without having to ask the contributor > twice is not a bad thing. I agree, it is always great to formalize things. Okay, let's test it. Imagine a contributor who are not aware how to write a good commit message, to see how that guideline would help. So, they make a non-trivial functional change ("non-trivial" because here we don't care of trivials like "rename a thing" or "factor out the code". These can often be described just in the commit title alone), let's say, they replaced a "list" container in a few functions to a binary tree for whatever reason. Now we'd like to know why did that happen. In my case they clearly would not produce anything useful, they'll maybe write "replace list to a binary tree" and that's it. Why? Who knows. How will they behave in your case? Well, they'll collect the functions list, then would scrupulously write an immensely useful information against each one "Replace list to a binary tree here". You see, it is the same here. > > Suppose you have a patch that deduplicates the same code pattern across 34 > > functions by factoring it out to a single short function. Do you really need > > that list? I mean, sure it's a fun fact to know, but you'll have to review > > diff > > anyway. > > Yes and no. If I get the purpose of the diff, I could scan the contents > more superficially (depending on what kind of changes are proposed, and > where). Sorry if I'm misreading, but given the context of comparing commit-messages with the list and without, I can only interpret the "yes" as "yes, one sentence that says the code pattern is factored out from all the functions is not enough, I need a similar sentence to be repeated 34 times". Is there other interpretation that I do not see, or do I get it right? > > If anything, it only burdens you by forcing to check that each function > > is on the list. > > I usually don't. This! Strictly speaking, as a reviewer you should check it. If a contributor forgot to add or remove a function on v2 of patches, and you passed them your Reviewed-by, wrong commit message would partially be your fault. You do not usually check it exactly because it is trivially a burden.