From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id Ui8JNeIMR2BxeQAAWB0awg (envelope-from ) for ; Tue, 09 Mar 2021 00:51:30 -0500 Received: by simark.ca (Postfix, from userid 112) id CBF021EF78; Tue, 9 Mar 2021 00:51:30 -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 BD3121E793 for ; Tue, 9 Mar 2021 00:51:26 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 39E453860C34; Tue, 9 Mar 2021 05:51:26 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 39E453860C34 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1615269086; bh=39HoE2cNXwW+boZg9USlEk4ECBK8PciFtYS8wVjt0Lk=; h=Date:To:Subject:References:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=AlE7oxw8em7G+0whhrNVhtgIihP4SaBPLsQ0ORtO/vP/Gg9YGISNuU8n0yxkUHzg3 aOhlcOcxjRWpOvDdR2LhqtSKZwKTSdOY0qyhD8zUVMbAJ+N9kSLGHM1JzN24OgaYb0 kjLkpL41lT2qjz7Zv8mnYXmT9NOivSvIl6m0n2vI= Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by sourceware.org (Postfix) with ESMTP id 7A2A83860C34 for ; Tue, 9 Mar 2021 05:51:18 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 7A2A83860C34 Received: from vapier (localhost [127.0.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.gentoo.org (Postfix) with ESMTPS id 60D39335CF4; Tue, 9 Mar 2021 05:51:17 +0000 (UTC) Date: Tue, 9 Mar 2021 00:51:15 -0500 To: Andrew Burgess Subject: Re: [PATCH] sim: switch to autogenerated ChangeLog files Message-ID: Mail-Followup-To: Andrew Burgess , gdb-patches@sourceware.org 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> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <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: Mike Frysinger via Gdb-patches Reply-To: Mike Frysinger Cc: gdb-patches@sourceware.org Errors-To: gdb-patches-bounces@sourceware.org Sender: "Gdb-patches" On 12 Jan 2021 10:47, Andrew Burgess wrote: > Mike Frysinger [2021-01-11 14:38:30 -0500]: > > On 11 Jan 2021 12:00, Simon Marchi wrote: > > > On 2021-01-11 6:05 a.m., Andrew Burgess wrote: > > > > I think sim/ should follow the same policy as gdb/ for now. Do feel > > > > free to raise this as a suggestion for gdb/ in general though, it > > > > would be an interesting conversation to observe. > > > > > > Last time I tried the gitlog-to-changelog script on GDB, it produced > > > horrible results. Probably because it was not designed for C++. > > > > > > Making a script to produce ChangeLogs for C code is already very > > > difficult, making it work with good results for C++ would be even > > > worst. And most importantly, I think it would be wasted development > > > time. > > > > to be clear, it isn't generating entries exactly like we write. it's > > using the git commit logs with formatted dates. so i don't think this > > applies exactly anymore. so it's inline with the GNU's VCS principles: > > https://www.gnu.org/prep/standards/html_node/Change-Logs.html > > (and that also recommends just using gitlog-to-changelog). > > I read this page, and especially the part that talks about using > gitlog-to-changelog, and I don't find their argument compelling. > > Early in the page they list some uses for ChangeLogs, which basically > boils down to performing "software forensics". Their benefits are all > good, but IMHO are all covered (and covered better) by what the VCS > provide. > > At the end of the page they say if you don't maintain a ChangeLog then > use a script to generate one in case people want to look at the > ChangeLog. But they fail to explain what use a ChangeLog is in a > release tree. The same argument could just as easily be used to > justify including a poem in the release; it should be there in case > someone wants to look at it. > > For me the question is what benefit does a ChangeLog offer in a > release tree? When I look through the 7 points (in favour of > ChangeLogs) raised on the above page I don't see what value any of > those things have given only a release tree. > > If we really wanted to include something informative inside each > release then I'd be most tempted to just do something like: > > git log --stat last-release-tag...new-release-tag > GIT-LOG > > That would give people a far more detailed understanding of what has > changed. > > But honestly, I don't think it's unreasonable to say that if someone > wants to dig into the source history, just clone the repo.... and let > ChangeLogs burn! so how are we feeling now ? i think we agree that we don't want to hand maintain ChangeLog files. then we need to decide on whether we want to include ChangeLog files for sim/ at all in releases. i'd be fine with just dropping them entirely if we don't want to bikeshed it anymore. we can create a sim/ChangeLog that just reads: Please see the git log online at: https://sourceware.org/git/?p=binutils-gdb.git;a=history;f=sim if we do include them, i think it's reasonable to expect they take a form similar to the other ChangeLog files in the tree. that would mean using gitlog-to-changelog, or some other gnu tool that i've missed. the upside to that over a raw `git log` is that, for old commits, it wil extract any ChangeLog entries and inline them in the log. this would be an easy way to bridge the old & new ways of writing log entries. -mike