From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 86829 invoked by alias); 13 Feb 2020 15:42:43 -0000 Mailing-List: contact binutils-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sourceware.org Received: (qmail 86815 invoked by uid 89); 13 Feb 2020 15:42:42 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-3.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.1 spammy=staying, H*f:sk:c3f3710, informative, H*MI:sk:c3f3710 X-HELO: eggs.gnu.org Received: from eggs.gnu.org (HELO eggs.gnu.org) (209.51.188.92) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 13 Feb 2020 15:42:41 +0000 Received: from fencepost.gnu.org ([2001:470:142:3::e]:57137) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1j2GdT-0003Ki-K4; Thu, 13 Feb 2020 10:42:39 -0500 Received: from [176.228.60.248] (port=2890 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1j2GdT-0007Wh-07; Thu, 13 Feb 2020 10:42:39 -0500 Date: Thu, 13 Feb 2020 15:42:00 -0000 Message-Id: <83a75mqyry.fsf@gnu.org> From: Eli Zaretskii To: Simon Marchi CC: binutils@sourceware.org, gdb-patches@sourceware.org In-reply-to: (message from Simon Marchi on Thu, 13 Feb 2020 09:19:28 -0500) Subject: Re: Using the vcs_to_changelog.py script References: <83imkbqhry.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-SW-Source: 2020-02/txt/msg00277.txt.bz2 > Cc: binutils@sourceware.org, gdb-patches@sourceware.org > From: Simon Marchi > Date: Thu, 13 Feb 2020 09:19:28 -0500 > > > . Some files in our tree are neither C++ nor C: there are Python > > files, Guile files, shell scripts, and Texinfo files, to mention > > just a few: what to do about them? > > I presume glibc is in the same situation... The script just says that > the file is modified. So for those other languages, the author of the changeset will have to write the entries by hand? Or are tyou suggesting omitting them altogether and staying with file names alone? (The latter would be somewhat boring for the GDB manual, since almost all of it is in a single file...) > If we wanted to get more details for them, we would have to > implement new parsers to figure out what changed between two > revisions. Is that practical? > > . Last, but not least: we'd need detailed instructions for how to > > produce the commit log messages under this regime, because the old > > conventions will not be valid anymore. > > What are you specifically referring to? For GDB, I don't really see what > would need to change. We already enforce having detailed commit logs that > explain: > > - the rationale for the change > - technical details about the fix, if not trivial > > So the only difference is that we would not provide a manual ChangeLog entry. And replace that part with nothing? I thought something will have to be done instead, to have the log messages be as informative as they are now.