From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 89275 invoked by alias); 13 Feb 2020 20:56:37 -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 89262 invoked by uid 89); 13 Feb 2020 20:56:37 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-6.4 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.1 spammy=consult, H*MI:sk:834kvuq, H*i:sk:834kvuq, H*f:sk:834kvuq 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 20:56:35 +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 01DKuLmA016186 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 13 Feb 2020 15:56:26 -0500 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp.polymtl.ca 01DKuLmA016186 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=polymtl.ca; s=default; t=1581627388; bh=kquk7ar0kwEeNhlaYwFRAV29lmo7wlgRvlDA0ULapnc=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=jfYhVHjzvMndiZsmONefMmoayliGNt5eBP9b/4rbarBUI4W1O1tF6B4sucBxP9ajk 0viUr2YLtttXftNYOWbVnifgjDd+HoZrEEwDbTN1vYliyB56rbRBAuuAQh52gA6gdY K35j2flpfDT4Ax824u28n7IZk7PgOxhtHjeWzKWA= 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 5801B1E4C2; Thu, 13 Feb 2020 15:56:21 -0500 (EST) Subject: Re: Using the vcs_to_changelog.py script To: Eli Zaretskii , Philippe Waroquiers Cc: binutils@sourceware.org, gdb-patches@sourceware.org References: <83imkbqhry.fsf@gnu.org> <83a75mqyry.fsf@gnu.org> <675991ee-28c0-ce5a-6327-c6ad80ccb1c3@polymtl.ca> <837e0qqpps.fsf@gnu.org> <834kvuqoar.fsf@gnu.org> From: Simon Marchi Message-ID: Date: Thu, 13 Feb 2020 20:56: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: <834kvuqoar.fsf@gnu.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2020-02/txt/msg00311.txt.bz2 On 2020-02-13 2:29 p.m., Eli Zaretskii wrote: >> From: Philippe Waroquiers >> Cc: binutils@sourceware.org, gdb-patches@sourceware.org >> Date: Thu, 13 Feb 2020 20:09:21 +0100 >> >> On Thu, 2020-02-13 at 20:58 +0200, Eli Zaretskii wrote: >>> I have yet to see this accepted as GNU policy. And at least >>> personally, having a ChangeLog in a tarball that just says which >>> function was changed on what date is almost useless to me (and I do >>> sometimes need to work without access to the VCS repositories). >> It looks easy to have a script to generate a file that contains all >> the git log messages + the diff for each commit >> in case detailed changes have to be analysed off-line, without a git repository. > > How does this help when all you have is the release tarball? I think Philippe suggests bundling that file in the release tarball, similar to how we would be bundling the ChangeLog file. If we were to do that, I'd suggest instead to run "git-format-patch" on the range of commits included in the release. That generates one file per commit (with a numerical prefix so they are in the right order), which makes it easier to consult. The problem with this might be the size of that content. I tried just for fun to see how big it would get with the gdb 9 release. I generated the files with this command: git format-patch $(git merge-base gdb-8.3-branch gdb-9-branch)..gdb-9-branch 2990 patch files are produced. The result is 115M uncompressed, 11M gzip-compressed, 6.7M xz-compressed. So it's not that bad, considering the amount of information it contains. > > Anyway, I really don't think we should re-iterate the many months of > discussions on gnu-prog-discuss, which led me to propose the change in > standards.texi. Those discussions have beaten this horse to death, > and I don't think we will invent any new arguments for or against > producing ChangeLog files from VCS logs. If we decide to produce > ChangeLog files at the time the release is tarred, then the ChangeLog > files should be informative and useful; otherwise it's tantamount to > deciding to drop ChangeLog's for the releases as well. Agreed. Simon