From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by sourceware.org (Postfix) with ESMTP id 8F830386F436 for ; Tue, 12 Jan 2021 21:22:57 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 8F830386F436 Received: from vapier (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with SMTP id 8AEFC340DFE; Tue, 12 Jan 2021 21:22:56 +0000 (UTC) Date: Tue, 12 Jan 2021 16:22:55 -0500 From: Mike Frysinger To: Andrew Burgess Cc: gdb-patches@sourceware.org Subject: Re: [PATCH] sim: switch to autogenerated ChangeLog files Message-ID: <20210112212255.GY7494@vapier> 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: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Zzd9Wh/bp6DhMAqJ" Content-Disposition: inline In-Reply-To: <20210112104746.GJ1175365@embecosm.com> X-Spam-Status: No, score=-5.6 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, KAM_SHORT, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_PASS, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org 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: , X-List-Received-Date: Tue, 12 Jan 2021 21:23:03 -0000 --Zzd9Wh/bp6DhMAqJ Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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. > > >=20 > > > Last time I tried the gitlog-to-changelog script on GDB, it produced > > > horrible results. Probably because it was not designed for C++. > > >=20 > > > 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. > >=20 > > 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). >=20 > I read this page, and especially the part that talks about using > gitlog-to-changelog, and I don't find their argument compelling. >=20 > 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. >=20 > 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. >=20 > 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. >=20 > If we really wanted to include something informative inside each > release then I'd be most tempted to just do something like: >=20 > git log --stat last-release-tag...new-release-tag > GIT-LOG >=20 > That would give people a far more detailed understanding of what has > changed. the current gitlog-to-changelog script that my patches here use does generate a file akin to what you're recommending with GIT-LOG (albeit without --stat). > 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! i don't have a problem with dumping `git log` to ChangeLog files as part of the release tarball creation. i know we're all pretty well integrated with the source repos and know how to find this info, but sometimes people who download these releases are not. there is also the slight angle of network connectivity not being as ubiquitous for all users around the world as it might be for you & i. but really my only very strong preference is to not ever have to write another ChangeLog entry by hand, whether it be in the files themselves, or inlined in the commit message, or attached to an e-mail sent to the list. i can take/leave every other idea. -mike --Zzd9Wh/bp6DhMAqJ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEuQK1JxMl+JKsJRrUQWM7n+g39YEFAl/+Ey8ACgkQQWM7n+g3 9YE6/xAArdYx5r+AVWpjzGkWh9XTDjaGvLD7ZseexOm2ZqgWQc3KJCu763RYVrQa DDY80NibDm9lJsjf/oRwsIzfNXGnieMribUioo0Jccyv/iQX7TeBPahxHSG70H+E FY0US3VEJbu/gqpDXvvECCgDnQgVstr25m5e1E2EISHORwv6rGvL3D/B34Bxn/rD QIjuNu9c57b7xNir991UpYoz711NLWloQq5jeKVbtVM58I6y8b/V0MS/8uJjo9oJ IrqMmK8QKu29rnkdMDZgPaR10R6OHGTC/Q+oRKGUKEKXnW55CtJ2Iwk81+s/GH6V LiJElYuW9EGsWuc8KcPpmbHRNR/lxBADeTpUqC+VmF+RJ+xhA/eMCbYkX4LOsxA6 17ITCDKiRnapn7/o0Vwznmfan069w4UJdjZfHezfCrSA/TiM0xVxgr2vbpPzDm5o ZQxNKWOfVmTLWbpJEKvwcQOVYcw2jpRpbr47tDMJvpmZr5r7IQTMsf9XgkYkto5u wayMOxjYe/y+op1vRsrDGVDwJdTbXEA9pV4gUsYiL0s6MPgcIauFr1dCyiaJ24XL 0N0CJoQDalJbRaopb217sKx3/mXv5shY84rQHpJOUxT1RpFnZ06k9P1YxaoXFMyg 0mw2hvprlhAzP1Dl8K00xMOuka+HttfrNtT7nNZU8hSngyRd4s4= =7zbN -----END PGP SIGNATURE----- --Zzd9Wh/bp6DhMAqJ--