From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Is it time to drop ChangeLogs? Date: Wed, 06 Jul 2016 20:23:32 +0300 Message-ID: <83y45ellyj.fsf@gnu.org> References: <56BE7E37.3090708@cs.ucla.edu> <4hd1rw1ubr.fsf@fencepost.gnu.org> <83vb50wxhv.fsf@gnu.org> <87y49vz4cg.fsf@acer.localhost.com> <87twg2g86g.fsf@lifelogs.com> <83eg76n5h5.fsf@gnu.org> <87y45eeoor.fsf@lifelogs.com> <8337nmn2pd.fsf@gnu.org> <87shvmem2c.fsf@lifelogs.com> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1467825995 24867 80.91.229.3 (6 Jul 2016 17:26:35 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 6 Jul 2016 17:26:35 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Jul 06 19:26:34 2016 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1bKqao-0004Jb-1G for ged-emacs-devel@m.gmane.org; Wed, 06 Jul 2016 19:26:34 +0200 Original-Received: from localhost ([::1]:35001 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bKqan-0005mR-8U for ged-emacs-devel@m.gmane.org; Wed, 06 Jul 2016 13:26:33 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:44742) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bKqYD-0003iJ-NV for emacs-devel@gnu.org; Wed, 06 Jul 2016 13:23:54 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bKqY8-0007As-Mb for emacs-devel@gnu.org; Wed, 06 Jul 2016 13:23:52 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:37710) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bKqY8-00079T-Jd for emacs-devel@gnu.org; Wed, 06 Jul 2016 13:23:48 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:4674 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1bKqY6-0005V7-MX for emacs-devel@gnu.org; Wed, 06 Jul 2016 13:23:47 -0400 In-reply-to: <87shvmem2c.fsf@lifelogs.com> (message from Ted Zlatanov on Wed, 06 Jul 2016 13:03:07 -0400) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 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.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:205272 Archived-At: > From: Ted Zlatanov > Date: Wed, 06 Jul 2016 13:03:07 -0400 > > On Wed, 06 Jul 2016 19:36:30 +0300 Eli Zaretskii wrote: > > EZ> What format do you suggest instead? > > "Summary line. > > Details..." > > Where the Details can be in the current or another format or whatever > works for the contributor. The per-file summary would be available from > the pull request system, regardless of the formatting of the commit message. That's already so. The number of times I had to reformat log messages for casual contributors is too large to remember. You just suggest to codify that, so they won't feel obliged to even try to format the messages as we want them. > EZ> The advantage of the current formatting is that we have Emacs features > EZ> which support it very well. Any other formatting will have to grow a > EZ> similar support first. And then we all need to re-learn. > > Good points. I'm trying to say all the support code can move to the pull > request system, so it won't go away, and the transition can be gradual. Sorry, I don't understand how this will work. Can you explain? Let's say I received a pull request, and the commit's log message needs reformatting. What next? > EZ> IOW, isn't this suggestion going to favor casual contributors over > EZ> those who push commits day in and day out? > > Yes, exceptions should be made for those regular contributors. But you > know that some features merit discussion, even if a very senior > contributor wants them. Our current practice is to discuss when the commit is already pushed. > If I understand correctly, your concern is about logistics rather than > about the fundamental benefits of such a system. I share your concerns > and think the risk is worth the benefit. My concern is about the manpower. If we don't have enough, this is going to be an exercise in futility. So I'd suggest first to have enough patch reviewers step forward and volunteer, before we start thinking about such a process seriously.