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 13:00:25 +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> <7e3969862c2d3f76fc812f4231d95e80e37c4c25.camel@yandex.ru> <9e4d15f7-a6ef-1924-dcc1-00e256558446@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="35878"; 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 12:01:22 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 1jkPS5-0009F3-SS for ged-emacs-devel@m.gmane-mx.org; Sun, 14 Jun 2020 12:01:21 +0200 Original-Received: from localhost ([::1]:43932 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jkPS4-0001wy-S7 for ged-emacs-devel@m.gmane-mx.org; Sun, 14 Jun 2020 06:01:20 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:56656) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jkPRU-0001WN-V1 for emacs-devel@gnu.org; Sun, 14 Jun 2020 06:00:44 -0400 Original-Received: from forward106p.mail.yandex.net ([77.88.28.109]:57751) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jkPRS-0007kC-LX; Sun, 14 Jun 2020 06:00:44 -0400 Original-Received: from mxback21j.mail.yandex.net (mxback21j.mail.yandex.net [IPv6:2a02:6b8:0:1619::221]) by forward106p.mail.yandex.net (Yandex) with ESMTP id E1F8A1C80E99; Sun, 14 Jun 2020 13:00:26 +0300 (MSK) Original-Received: from iva6-2d18925256a6.qloud-c.yandex.net (iva6-2d18925256a6.qloud-c.yandex.net [2a02:6b8:c0c:7594:0:640:2d18:9252]) by mxback21j.mail.yandex.net (mxback/Yandex) with ESMTP id W66fPPVVSQ-0Q6moEim; Sun, 14 Jun 2020 13:00:26 +0300 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1592128826; bh=TdvUtzl7NdEnlL/EeQnsS5nrreHOcrEyOhW31S4yE3I=; h=In-Reply-To:To:From:Subject:Message-ID:References:Date; b=ZRx1W1W9iTPSQEqQVMdyXWpN7xlaOvUBxvs3BaKqskHmD/uo9fN77S0bji5XXlkD9 gWlb6tShN0zDTq+ixCw0CSWqWoq6w9GpT6UY886smZz0jt5YGBRbqFrHMBbzVWifpC VneqtrNzxuwkL3j/c+NEf8TZmS6q+7s4+d1Y/8os= Authentication-Results: mxback21j.mail.yandex.net; dkim=pass header.i=@yandex.ru Original-Received: by iva6-2d18925256a6.qloud-c.yandex.net (smtp/Yandex) with ESMTPSA id ibZg6ZoGuU-0PFWmH45; Sun, 14 Jun 2020 13:00:26 +0300 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (Client certificate not present) In-Reply-To: <9e4d15f7-a6ef-1924-dcc1-00e256558446@yandex.ru> Received-SPF: pass client-ip=77.88.28.109; envelope-from=hi-angel@yandex.ru; helo=forward106p.mail.yandex.net X-detected-operating-system: by eggs.gnu.org: First seen = 2020/06/14 06:00:27 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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-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:252223 Archived-At: On Sun, 2020-06-14 at 02:23 +0300, Dmitry Gutov wrote: > On 14.06.2020 02:00, Konstantin Kharlamov wrote: > > > 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. > > We might want to know more things than that, actually. > > > 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. > > Then I'll probably ask. If the preceding discussion, or the contents of > the associated bug report, haven't made the reason clear already. > > > 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. > > Let's imagine that I know that in the codebase 'list' is used in many > places, and then in the ChangeLog entry I see that only some of them > have been replaced. > > Then I cut the review short and ask about the rest of the places. > > Similarly if they actually described the reason the change, but the > enumerated changes don't match that goal (e.g. some changes in some > files are missing). > > Another concern that can come up are whether they added > backward-compatibility aliases (to satisfy our backward compatibility > policy), which should also be apparent from the ChangeLog style entry. Etc. Sure, all you say sounds reasonable. The point I'm trying to make is that you have to ask the author for better commit message either way. IOW, you have to ask that disregarding whether they're obliged to write down the list of functions changed or not. So having the list didn't help here. Admittedly, I might be the wrong person to make up an example since I didn't see the point in this list to begin with. Better examples are certainly welcome. > > 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? > > Yes, as in "I'd have to review the diff anyway", and no, as in "I won't > have to spend as much time doing it as I might have without the > ChangeLog style summary". Please note we're discussing whether having the list of functions changed is worth it comparing to just the commit message. Having a good commit message is just as enough, so you "won't have to spend as much time doing it". Like, in the example with factoring out a code from 34 functions it's enough to just write "Many functions use same code pattern to do X. Factor it out to a separate function Y". What changes if instead of this one sentence you have 34 lines with function names? Besides, as I hopefully showed in my prev. paragraph, if an author is bad in writing commit messages, having that would hardly change anything.