From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id buYEHhbq/V/lTgAAWB0awg (envelope-from ) for ; Tue, 12 Jan 2021 13:27:34 -0500 Received: by simark.ca (Postfix, from userid 112) id 6D7601EF7E; Tue, 12 Jan 2021 13:27:34 -0500 (EST) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-1.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id BA0DC1EE1B for ; Tue, 12 Jan 2021 13:27:33 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 484A2386F013; Tue, 12 Jan 2021 18:27:33 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 484A2386F013 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1610476053; bh=Zfczs0cWn5vDbgDLGUbjMN98vp6sqpBSocztWAgDt3k=; h=Date:To:In-Reply-To:Subject:References:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=RnYCoPsdv5MVOKkTumlSXKDJrhYV0EhKMLJa/jKbMI5wsFao1UMbDERcVXrOy6WWH lW1HJ8vZuAs1H5kipikHt4DHIp3gvW0MfB9vTXLAnmazigKB8LDq50o01Phc7fOOCN pf8vVxKDqhJqwvIryprm5CbI8Ur5HmW6QkctFwGg= Received: from eggs.gnu.org (eggs.gnu.org [IPv6:2001:470:142:3::10]) by sourceware.org (Postfix) with ESMTPS id B8111386F013 for ; Tue, 12 Jan 2021 18:27:30 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org B8111386F013 Received: from fencepost.gnu.org ([2001:470:142:3::e]:37350) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kzOO9-0004RO-VO; Tue, 12 Jan 2021 13:27:29 -0500 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:2726 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1kzOO7-00083L-ET; Tue, 12 Jan 2021 13:27:28 -0500 Date: Tue, 12 Jan 2021 20:27:40 +0200 Message-Id: <83o8huc8o3.fsf@gnu.org> To: Joseph Myers In-Reply-To: (message from Joseph Myers on Tue, 12 Jan 2021 18:14:22 +0000) Subject: Re: [PATCH] sim: switch to autogenerated ChangeLog files References: <20210110033752.6002-1-vapier@gentoo.org> <20210110034223.6268-1-vapier@gentoo.org> <20210111110544.GC1151657@embecosm.com> <313988fb-ed42-11f7-1e64-b46005580792@polymtl.ca> <20210111193830.GT7494@vapier> <20210112104746.GJ1175365@embecosm.com> X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Eli Zaretskii via Gdb-patches Reply-To: Eli Zaretskii Cc: gdb-patches@sourceware.org Errors-To: gdb-patches-bounces@sourceware.org Sender: "Gdb-patches" > Date: Tue, 12 Jan 2021 18:14:22 +0000 > From: Joseph Myers > Cc: gdb-patches@sourceware.org > > What the GNU Coding Standards say about ChangeLogs isn't what would make > sense from a starting point of modern development practices, it's what we > could convince the maintainers of the GNU Coding Standards (being used to > ChangeLog-centric development practices) to allow. When did you last read the current text of GSoC, specifically the part related to change logs? The fact is that you did convince, and the text was modified to allow the MO which you argued for, as one possible alternative. > The discussion started at > > and took a few years (a few bits were on an internal GNU Project list, but > most was on bug-standards). In particular, the maintainers of the GNU > Coding Standards fixated on a point that they were used to using the lists > of changes to named entities (functions etc.) in ChangeLogs as part of the > debugging process, while my position is that the typical problem for which > such lists are used is not "map a commit to the named entities modified in > that change" but the inverse problem "map a named entity to the commits > changing it", which version control tools handle well without needing to > go via the ChangeLog-format lists at all. Having the list of changed entities in the logs is now a just a recommendation; the text describes the advantages of having that, but it doesn't insist. Please check out the latest text (maybe it is still only in CVS, not on prep, I don't keep track of that).