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 16:07:54 +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> 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="120836"; 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 15:08:42 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 1jmdEf-000VKu-N3 for ged-emacs-devel@m.gmane-mx.org; Sat, 20 Jun 2020 15:08:41 +0200 Original-Received: from localhost ([::1]:48570 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jmdEe-0004Cc-P1 for ged-emacs-devel@m.gmane-mx.org; Sat, 20 Jun 2020 09:08:40 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:42410) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jmdE8-0003lT-8W for emacs-devel@gnu.org; Sat, 20 Jun 2020 09:08:08 -0400 Original-Received: from forward103o.mail.yandex.net ([37.140.190.177]:43783) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jmdE4-00085V-OY; Sat, 20 Jun 2020 09:08:07 -0400 Original-Received: from mxback30g.mail.yandex.net (mxback30g.mail.yandex.net [IPv6:2a02:6b8:0:1472:2741:0:8b7:330]) by forward103o.mail.yandex.net (Yandex) with ESMTP id 1FBED5F80465; Sat, 20 Jun 2020 16:07:58 +0300 (MSK) Original-Received: from iva4-bca95d3b11b1.qloud-c.yandex.net (iva4-bca95d3b11b1.qloud-c.yandex.net [2a02:6b8:c0c:4e8e:0:640:bca9:5d3b]) by mxback30g.mail.yandex.net (mxback/Yandex) with ESMTP id H0yjkeyTlv-7vTK5FSm; Sat, 20 Jun 2020 16:07:58 +0300 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1592658478; bh=ROmoIfOl/srGLbalmlceG0urn0m6JDqhijGv4JKZVHw=; h=In-Reply-To:Cc:To:From:Subject:Message-ID:References:Date; b=Qls/TPDV3gOzwRpISAldDbkP5XlGuVBvis0BV+8AlPL3CRpxPu+VDcLV4MU/85mcv 30hC+vVasXbPRtS1rEL5QTdVJ/K3UK548EuYS8q7G2MzjzKTPomcCBPtu2yKJw/hyF Z2feQwtRj52ZvOU8FNqRx/WS1ni69nkQhW6OTLiU= Authentication-Results: mxback30g.mail.yandex.net; dkim=pass header.i=@yandex.ru Original-Received: by iva4-bca95d3b11b1.qloud-c.yandex.net (smtp/Yandex) with ESMTPSA id ScZNNoMkdb-7tk0XLsN; Sat, 20 Jun 2020 16:07:56 +0300 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (Client certificate not present) In-Reply-To: <83wo43xom6.fsf@gnu.org> Received-SPF: pass client-ip=37.140.190.177; envelope-from=hi-angel@yandex.ru; helo=forward103o.mail.yandex.net X-detected-operating-system: by eggs.gnu.org: First seen = 2020/06/20 09:07:58 X-ACL-Warn: Detected OS = Linux 2.2.x-3.x [generic] [fuzzy] X-Spam_score_int: -37 X-Spam_score: -3.8 X-Spam_bar: --- X-Spam_report: (-3.8 / 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_LOW=-0.7, RCVD_IN_MSPIKE_H2=-1, 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:252443 Archived-At: On Fri, 2020-06-19 at 14:48 +0300, Eli Zaretskii wrote: > > From: Konstantin Kharlamov > > Cc: Eli Zaretskii , Dmitry Gutov , Stefan > > Kangas , emacs-devel@gnu.org > > Date: Fri, 19 Jun 2020 01:34:21 +0300 > > > > > I’d also like to note that this list can be invaluable when rebasing > > > commits and resolving conflicts. It’s not strictly necessary (just like > > > other parts of a version control workflow are not strictly necessary), > > > but it can serve as a sanity check in a time when the diff is not > > > authoritative as it is in flux. > > > > While it may be useful, but explicit examples may be more interesting. Right > > now > > when I read your text about this list in the context of resolving rebase > > conflicts, I only see the downside that if the conflict came up because a > > function was renamed, you need to go fix the commit message too. > > > > Even worse: if upon rebasing a function was renamed, you may not get any > > conflicts (i.e. because thunk you modified didn't include the beginning of > > the > > function), and now your commit message is broken without you even noticing. > > There's no requirement to retroactively fix commit log messages when > files or functions are renamed. The renaming is recorded in the > history and can be found when one needs to explore the history of some > code fragment. > > What is important is that the log message names the files and > functions/macros/data structures as they are called at the time of the > commit, because the log message is many times read in conjunction with > the diffs. > > So I don't think the difficulties you describe are real. Are you saying that wrong commit messages are okay? Will it be okay if I make a v1 of a patch where just one function is changed, and then in v2 I additionally modify a dozen of others, and won't add their names to the commit message? Also, what you say here contradicts to your quote of GNU standard, which says the list is needed to generate Changelog files. Because not fixing commit messages retroactively will result in wrong Changelogs. What's the point in wrong Changelog files and wrong commit messages? > > Let me sum up the positive mentions: so far, you just say it simplifies > > review > > for you, but I don't know your workflow, there may be many factors that make > > you > > assert that, which does not necessarily applies to everyone. Dmitry said the > > list makes better commit messages from novices, but again when I tried to > > dig > > deeper, that discussion died. > > When you contribute changes to a project, you need to satisfy the > workflows of others, even if they differ from yours. So you need to > respect the opinions of the project developers when they tell you this > information is of help to them. Right. Judging by the fact you say this me, I have a feeling you miss the point why we're even discussing this. Let me abstract from Emacs a bit. People like different things, which is okay, everyone has unique life and character. And some like things that would in fact hurt when applied to others! That's okay too, just don't apply these to everybody. There're communities for them as well, so it's not like they're alone. Now let's get back to Emacs. I hope it's unquestionable that purpose of Emacs project is prosperity of Emacs project. It doesn't have explicit purpose to cater to Emacs contributors or developers. But if you ask "how can we make Emacs evolve and prosper", the "making Emacs contributors, developers and users comfortable" is hopefully an obvious answer. Having good developer practices is an implication of "making developers/contributors comfortable". Which includes, that if some developer practice (I'm pointing out here to the functions list) 1. carries burden on everyone, and 2. Makes happy only a few (perhaps, because of their habits or whatever), we should ditch this practice. Because Emacs project is not a community of peoples who like a specific thing that would hurt others when applied to them. Instead it's a community who want Emacs to evolve and prosper. > Here are the excerpts from the latest GNU Coding Standards manual I > mentioned above: > […snipped…] Thanks. I should say, it's a big text, half of which basically says "it's cool to have" which doesn't answer the question "why". So, I'm sorry if I missed some point while reading this, in this case pointing this out more explicitly might help. Regarding the discussion I grasped from it two points: 1. The list is used to generate Changelogs. 2. The standard does not enforce having the list in commit messages if you're using a decent VCS (which I'd think includes git) The text then goes into details that generating Changelogs from a VCS alone may be unreliable. The example it shows can be reproduced on Emacs repo as follows: if you do `git log -1 -p 50a0126402d`, you'll see some renames, however the context above the hunk shows not the variable/function being renamed. I'd argue it would be way more productive to make git produce what Changelog files need correctly rather than forcing tedious manual work upon everybody. git already can recognize the context correctly, we just need a specific flag to only make it show changed functions/variables (ATM it seems not to have it, at least I didn't find one).