From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Eli Zaretskii 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 19:10:57 +0300 Message-ID: <83pn9tvhta.fsf@gnu.org> 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> Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="94381"; mail-complaints-to="usenet@ciao.gmane.io" Cc: rekado@elephly.net, emacs-devel@gnu.org, stefan@marxist.se, joaotavora@gmail.com, dgutov@yandex.ru To: Konstantin Kharlamov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Jun 20 18:11:50 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 1jmg5u-000OSu-Ao for ged-emacs-devel@m.gmane-mx.org; Sat, 20 Jun 2020 18:11:50 +0200 Original-Received: from localhost ([::1]:37988 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jmg5t-00052g-C7 for ged-emacs-devel@m.gmane-mx.org; Sat, 20 Jun 2020 12:11:49 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:40360) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jmg5F-0004aO-79 for emacs-devel@gnu.org; Sat, 20 Jun 2020 12:11:09 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:40259) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jmg5E-0001zc-8A; Sat, 20 Jun 2020 12:11:08 -0400 Original-Received: from [176.228.60.248] (port=1956 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jmg5C-0001WC-7D; Sat, 20 Jun 2020 12:11:07 -0400 In-Reply-To: <09632e8ec343ddee558b18f811ef6da77e594f55.camel@yandex.ru> (message from Konstantin Kharlamov on Sat, 20 Jun 2020 18:41:37 +0300) 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:252448 Archived-At: > From: Konstantin Kharlamov > Cc: rekado@elephly.net, joaotavora@gmail.com, dgutov@yandex.ru, > stefan@marxist.se, emacs-devel@gnu.org > Date: Sat, 20 Jun 2020 18:41:37 +0300 > > > Also, let's face it: changesets where v2 renames many symbols present > > in v1's log are rare. There's no need to make these rare cases sound > > as if they were the rule: they are not. > > Please note that I haven't provided example here. From your text you seem to > think I implied scenario where v1 is an RFC, and later patches are actual > changes. Many times the first version of a patch is an implicit RFC, especially for a rare contributor who cannot be sure his or her ideas will be accepted by the developers. As another data point, I frequently post my proposed patches without log messages, because I believe people generally trust me to produce the right log messages when the time comes. > It's not what I had in mind. I rather was thinking about making some change in > v1, and then as result of code review making more similar changes to other > places. As a real life example, while discussing the patch `Replace manually > crafted hex regexes with [[:xdigit:]]`, more places where similar changes can be > applied were uncovered. > > In code-refactoring I think it's pretty common to happen. You can't omit the > list in v1 in these cases because you don't know there will be followups. Fair enough, but massive renames are still rare, IME, and thus the danger of having to completely rewrite the log messages is also small. > 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. > 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. > 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"? > 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.