From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by sourceware.org (Postfix) with ESMTPS id 60AB6397A4B2; Fri, 29 May 2020 12:25:07 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 60AB6397A4B2 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=suse.cz Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=mliska@suse.cz X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id DFA8DAD60; Fri, 29 May 2020 12:25:05 +0000 (UTC) Subject: Re: Auto update ChangeLog for binutils+gdb commits? To: Tom Tromey Cc: "H.J. Lu" , Simon Marchi , GDB , Binutils References: <891ef86a-a47f-18f2-c6bd-e525719e3768@simark.ca> <9492d857-c259-1429-f1c7-31a6dbf6510f@simark.ca> <1fb47dab-7a52-524b-17a3-672122277a48@suse.cz> <87tuzzaqey.fsf@tromey.com> From: =?UTF-8?Q?Martin_Li=c5=a1ka?= Message-ID: Date: Fri, 29 May 2020 14:25:05 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <87tuzzaqey.fsf@tromey.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-10.3 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, KAM_SHORT, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gdb@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 May 2020 12:25:08 -0000 On 5/29/20 2:15 PM, Tom Tromey wrote: > Martin> I'm the author of the scripts that are currently used in the GCC. > Martin> As mentioned, we update ChangeLog files by a script that takes all > Martin> the ChangeLog entries from git commit message. The supported ChangeLog > Martin> format is documented here: > > Martin> https://gcc.gnu.org/codingconventions.html#ChangeLogs > > IIUC, we still have to write the ChangeLog entries by hand, just in the > commit message, and using a much stricter format. Is that accurate? Yes, the entries should be places to git message. > > If so, then this seems less convenient than the status quo. At least > for me, editing the files is simpler -- I use scripts to handle the > merges, rebases, and date-updating; and Emacs provides direct support > for writing the entries in the correct files and it usually gets the > function name correct as well. For generation of ChangeLog template, you can use: https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=contrib/mklog.py;h=243edbb15c522169709902b27a8558c6e0755107;hb=HEAD It takes a diff a generates a template. Note that PR entries are auto-filled, new and removed files are automatically added. About the merges: it's a pain to make a backport (a.k.a) as you're very likely conflict in ChangeLog entries. Having the ChangeLog entries in message one can do simple git cherry-pick and it's done. Note that quite all developers have self made scripts for these situations and it seems to me an extra work everybody has to do. > > It's the convenience of the last part that I'm most concerned about > losing. If there's a script that does as good a job, then maybe; but > otherwise it is a -1 from me. My reasoning here is that editing a > ChangeLog entry is labor-intensive, and anything increasing the labor is > a negative. It's already a reasonably significant drag on submitting > patches. > > I'd be receptive to removing ChangeLog entirely. I don't believe they > provide much value. However, I know others disagree on this point, so I > don't plan to press it. > > I'd also be open to changing the format to something requiring zero > manual intervention. For example, if we could have a commit script that > simply listed the files and didn't require editing in the names of the > functions. Yes, mklog.py does that. > > thanks, > Tom >