From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id cyHQM1l+/V+2OwAAWB0awg (envelope-from ) for ; Tue, 12 Jan 2021 05:47:53 -0500 Received: by simark.ca (Postfix, from userid 112) id C64521EF7E; Tue, 12 Jan 2021 05:47:53 -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 BD5761EE1B for ; Tue, 12 Jan 2021 05:47:52 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 6E745389247A; Tue, 12 Jan 2021 10:47:52 +0000 (GMT) Received: from mail-wr1-x430.google.com (mail-wr1-x430.google.com [IPv6:2a00:1450:4864:20::430]) by sourceware.org (Postfix) with ESMTPS id 70AE23892460 for ; Tue, 12 Jan 2021 10:47:49 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 70AE23892460 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=embecosm.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=andrew.burgess@embecosm.com Received: by mail-wr1-x430.google.com with SMTP id y17so1949185wrr.10 for ; Tue, 12 Jan 2021 02:47:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=embecosm.com; s=google; h=date:from:to:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=pa2Gd3HWA9drJyaxBJFlcCE6dW7YFCuWX8UWRg9UGYA=; b=a8Zg5YJTKMra8e4Rd9KZMzLJj7Gd3fVynOOFAn3cA1upZaQ6wY1Nn+4NX/uWglDIub Y81/bD63znzFPdhilYJ7hno9M1uLKreeGAQlL42eFZq3wEyKdXmNjcqnS367oPfWP9kd tfZNTbXCP8e5QDwej8JG28YMC3xF3DFkUIp8mY+tz6p8n4km6KzTJO1KmWgmJpDige9m oBXiT/uY71cpPmUoVyCIpmZsU1eYz2ndeQwqmiQ5icGeWGV/Z7okcHz28oxu6Ceg4Lxm o7+aefXSlTX6HCaVoQGPgTH23dOP6YtN3Lizonat4d5th9NndVnHH627rAQ8hL6nxnUq A7cA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=pa2Gd3HWA9drJyaxBJFlcCE6dW7YFCuWX8UWRg9UGYA=; b=Hiw8h8UjJqJ0W0Ww1hhWX7XDnD7F1KMjQFdw2WYpaJU4nMNjiT6Tgupn0cMkdxp4m5 JAhDQmlfMFeLTnsMdJL0YdbL+KrspGlOT4IHeUg3bv7p4Ph2HKaNgMsXhUn7hDBINazA fh+YT2RbW0E/NR5kGVApKSwN5Vzw72m4Sa3mBW7yB8xZvSocL8RJh9GjkjVMNqNNZo7B 8s30aXGSTQyUM4NXoczfTI7M8CL9xKVSSsVo2WcyXRr7CDnm3Ustxn/MIKk6FlOxO0z9 h3LXibtakDBJiGbGgJvewVImOUc8nPb2cPd31LD5bOFMrkZ3n1LPOflXGxDyle2tyNPD QNzA== X-Gm-Message-State: AOAM533MxDCWxhyB9E7hKdbxpZ16cskzBdbjlA8HKZBnF4i2Fgpv95iY yvYTePOW2Xfq1norEhDNoujBM82x8tBNiQ== X-Google-Smtp-Source: ABdhPJysmzBkXe7arsRNBrl0LNI+XVXIqHrOGIoDuRA8X+9ytgmdb5fQkAYciOSr8RsI7X8gKQiHZg== X-Received: by 2002:a5d:6cad:: with SMTP id a13mr3512090wra.275.1610448468333; Tue, 12 Jan 2021 02:47:48 -0800 (PST) Received: from localhost (host86-166-129-230.range86-166.btcentralplus.com. [86.166.129.230]) by smtp.gmail.com with ESMTPSA id j10sm3604757wmj.7.2021.01.12.02.47.47 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 12 Jan 2021 02:47:47 -0800 (PST) Date: Tue, 12 Jan 2021 10:47:46 +0000 From: Andrew Burgess To: gdb-patches@sourceware.org Subject: Re: [PATCH] sim: switch to autogenerated ChangeLog files Message-ID: <20210112104746.GJ1175365@embecosm.com> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210111193830.GT7494@vapier> X-Operating-System: Linux/5.8.13-100.fc31.x86_64 (x86_64) X-Uptime: 10:32:01 up 34 days, 15:16, X-Editor: GNU Emacs [ http://www.gnu.org/software/emacs ] 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: , Errors-To: gdb-patches-bounces@sourceware.org Sender: "Gdb-patches" * 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! Thanks, Andrew