From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id VR4JB8IQUmA2AQAAWB0awg (envelope-from ) for ; Wed, 17 Mar 2021 10:22:58 -0400 Received: by simark.ca (Postfix, from userid 112) id 0FDB31EF78; Wed, 17 Mar 2021 10:22:58 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=0.2 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,RDNS_NONE,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.2 Received: from sourceware.org (unknown [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 A90131E54D for ; Wed, 17 Mar 2021 10:22:57 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id EA1C6385781A; Wed, 17 Mar 2021 14:22:56 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org EA1C6385781A DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1615990977; bh=PhNscxaV/NLB/d19c7OvG2i9FmLGrQ+OrezmtA6J7kY=; h=Subject:To:References:Date:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To: From; b=vFgnYj7om5uvpTK4r40b3rMz7ehf5YmZ1yL6rBtEF1dAyMVomHH+yW7npkHpkYGK5 oWdpvBHR7zKSlrsOlopRSPoL2KCuexvXwKd8dSZ/9KO2JK/qszsWVKELIsqij2wG18 1XWL+iVlG0d1W4WTLiPreo6waIU754MRXm7ueyR4= Received: from mail-qk1-x72c.google.com (mail-qk1-x72c.google.com [IPv6:2607:f8b0:4864:20::72c]) by sourceware.org (Postfix) with ESMTPS id C7FD9385781A for ; Wed, 17 Mar 2021 14:22:54 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org C7FD9385781A Received: by mail-qk1-x72c.google.com with SMTP id s7so38981473qkg.4 for ; Wed, 17 Mar 2021 07:22:54 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=PhNscxaV/NLB/d19c7OvG2i9FmLGrQ+OrezmtA6J7kY=; b=eNnoi8jcT08YAK/fS5a07MpPEMU/NPIJ4egdxTqsPupwTftk2Ay097tquWD5RcnoUG PRfuyiMP640I66QfmALKsJiHpXyi/ZxNW/+l4bNvfg6CvcAsSg3faA5Zjv6BFmeMXtWb FpcRtu9LDqRTg3gurGuZTXSiq1Ur1nbhgkSXp/rOfLZjDPpgrqSAfN/9wLa36EK6MTCk t77jne2oUu2WgZwUbKm3mwYdBfYUe/wVQNwqRrNJTyhT+KI/EkSGZ2r5/afW+iR7ZXdN l50l/dLL9UDGAWmY5B5FMSBGNV7GW7el5A0XfP9myPO2fkB6sBa6Pv9hQ4gsMShtnYir zpOQ== X-Gm-Message-State: AOAM530i7PfMwZ/tI3rgLpiVT1TdrYSEaWRQ277LLvH8h3lySnNjTkam TJjxUrCPR7Vq1kjFwS7DSSQyJw== X-Google-Smtp-Source: ABdhPJzDe7LxYSheaJytEY2MTv8zN2ECkdMpOy9lKwM+fwxJusn9fpFsR9JEinR7C2eHAnCxrRYnzA== X-Received: by 2002:a37:6889:: with SMTP id d131mr4944743qkc.264.1615990974188; Wed, 17 Mar 2021 07:22:54 -0700 (PDT) Received: from ?IPv6:2804:7f0:4841:2841:c502:89bb:c3bf:f9a1? ([2804:7f0:4841:2841:c502:89bb:c3bf:f9a1]) by smtp.gmail.com with ESMTPSA id e96sm15411168qtb.60.2021.03.17.07.22.52 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 17 Mar 2021 07:22:53 -0700 (PDT) Subject: Re: [PATCH] sim: switch to autogenerated ChangeLog files To: Andrew Burgess , gdb-patches@sourceware.org, Mike Frysinger 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> <20210309094214.GN1720904@embecosm.com> Message-ID: <436cbb74-ac5b-315e-1e94-8e82ed9a5160@linaro.org> Date: Wed, 17 Mar 2021 11:22:50 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 MIME-Version: 1.0 In-Reply-To: <20210309094214.GN1720904@embecosm.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit 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: Luis Machado via Gdb-patches Reply-To: Luis Machado Errors-To: gdb-patches-bounces@sourceware.org Sender: "Gdb-patches" On 3/9/21 6:42 AM, Andrew Burgess wrote: > * Mike Frysinger [2021-03-09 00:51:15 -0500]: > >> 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. > > My general position is that sim/ is really a sub-component of gdb, as > it is only ever released as part of gdb, and as such should follow GDB > policies and coding standards, just for consistency. > > That said, ChangeLogs suck so much, so maybe we could use this as an > opportunity to drop them, and maybe set some precedent for changing > gdb/ one day (hey, I can dream!). > > I think the one thing I would say is that auto-generated ChangeLogs > are worse than what we currently have, so can we please agree to take > them off the table. I've not yet seen a tool that can 100% accurately > figure out the names for changed entities, nor does an auto-generated > script ever say anything useful about what changed. So you're left > with a list of things that _might_ have changed, with no information > about _what_ changed in them. Just a complete waste of time. > > I guess the one thing that has surprised me is that nobody has jumped > in to really defend ChangeLogs. Maybe there really is hope that we > could drop these for gdb/... My guess is that there are only a few active developers in the GDB community that care about ChangeLog files. Most of us suffer in silence wasting valuable time writing less-than-useful ChangeLog entries, hoping one day there will be a discussion on their usefulness right now. It has gotten worse with C++, because now the names tend to be longer and we start hitting the 80 columns limit as well. So sometimes we need to solve puzzles and fit things properly into the given limits. Isn't this something we can discuss more broadly in the context of the GDB community/development roadmap as a whole? I'm not sure what group of people decides that there's been enough discussion and bikeshedding to make a decision. FSF maintainers? Global maintainers? Or will a consensus-based decision (like glibc) suffice? > > I think you should create a new top-level post, with a subject line > that makes it clear you're planning to drop ChangeLogs for sim/. If > nobody complains to that then go with your plan, just point folk to > the online history. > > > Thanks, > Andrew >