From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3544 invoked by alias); 13 Feb 2020 16:26:26 -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 3528 invoked by uid 89); 13 Feb 2020 16:26:26 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-6.5 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.1 spammy=H*i:sk:83a75mq, H*MI:sk:83a75mq, H*f:sk:83a75mq X-HELO: smtp.polymtl.ca Received: from smtp.polymtl.ca (HELO smtp.polymtl.ca) (132.207.4.11) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 13 Feb 2020 16:26:24 +0000 Received: from simark.ca (simark.ca [158.69.221.121]) (authenticated bits=0) by smtp.polymtl.ca (8.14.7/8.14.7) with ESMTP id 01DGQCe8015552 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 13 Feb 2020 11:26:17 -0500 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp.polymtl.ca 01DGQCe8015552 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=polymtl.ca; s=default; t=1581611178; bh=a6AXDvEF8dQOKQfO5Z2ewo2bRqd7/IJx3GvCwWoPobM=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=ISa2SajktP5itbzTRL1UYybLf1aOpNK4uAXskvM3hYVRyJ/cOMCZjrkIpdfhwe4TH yglFolBRO1g0HOxjr8dAunr3csGYuW/ruzniE8nn5zP8jeCabQsAwbx++NAlfGoxN5 K7DCw3aP6W+O0BY7YgYriUfEhm0dIHbVk11tPLn8= Received: from [172.16.0.95] (192-222-181-218.qc.cable.ebox.net [192.222.181.218]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id 9BCB41E05A; Thu, 13 Feb 2020 11:26:12 -0500 (EST) Subject: Re: Using the vcs_to_changelog.py script To: Eli Zaretskii Cc: binutils@sourceware.org, gdb-patches@sourceware.org References: <83imkbqhry.fsf@gnu.org> <83a75mqyry.fsf@gnu.org> From: Simon Marchi Message-ID: <675991ee-28c0-ce5a-6327-c6ad80ccb1c3@polymtl.ca> Date: Thu, 13 Feb 2020 16:26:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: <83a75mqyry.fsf@gnu.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2020-02/txt/msg00286.txt.bz2 On 2020-02-13 10:42 a.m., Eli Zaretskii wrote: >> 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...) I am not a user of ChangeLog files myself (other than writing entries for them), so I would be fine if the entry only mentioned the file name. But perhaps others will not, I can't tell. I don't think it would be practical if some entries were written by hand and others were generated. First, I think it would make the contribution process confusing, but also I don't know how it would work process-wise. >> 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? I presume that it's much harder to make an ad-hoc parser for C and for a texinfo file. So if it has been done for C, it should be do-able to texinfo. >> 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. My understanding from: - past dicussions (the big one on bug- - the proposed change to standards.texi that you sent is that the ChangeLog entry is redundant enough with the combination of: - a good commit message that explains why the change is done - the diff of the change which are both kept by the VCS. And for that reason, it's fine not to keep a ChangeLog file in the VCS. However, for the benefit of people just using tarballs, and not the VCS, we generate a ChangeLog file from the diff. Naturally, the generated ChangeLog will be less informative than one written by humans (it won't say what changed in a function, it will just say that the function has been modified), but since that procedure was adopted by glibc, and is mentioned in the proposed standards.texi change, then it must have been considered an acceptable compromise. Simon