From owner-svn-src-all@freebsd.org Thu Aug 1 18:54:10 2019 Return-Path: Delivered-To: svn-src-all@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 11FCDC5D1D; Thu, 1 Aug 2019 18:54:10 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 45zzwd6lYrz46FN; Thu, 1 Aug 2019 18:54:09 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from John-Baldwins-MacBook-Pro-4.local (ralph.baldwin.cx [66.234.199.215]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: jhb) by smtp.freebsd.org (Postfix) with ESMTPSA id 195E315505; Thu, 1 Aug 2019 18:54:08 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Subject: Re: svn commit: r350505 - in head: contrib/binutils/binutils/doc gnu/usr.bin/binutils/objdump To: Ian Lepore , Ed Maste , "Rodney W. Grimes" Cc: src-committers , svn-src-all , svn-src-head References: <201908011650.x71GoxBe060563@gndrsh.dnsmgr.net> From: John Baldwin Openpgp: preference=signencrypt Autocrypt: addr=jhb@FreeBSD.org; keydata= mQGiBETQ+XcRBADMFybiq69u+fJRy/0wzqTNS8jFfWaBTs5/OfcV7wWezVmf9sgwn8TW0Dk0 c9MBl0pz+H01dA2ZSGZ5fXlmFIsee1WEzqeJzpiwd/pejPgSzXB9ijbLHZ2/E0jhGBcVy5Yo /Tw5+U/+laeYKu2xb0XPvM0zMNls1ah5OnP9a6Ql6wCgupaoMySb7DXm2LHD1Z9jTsHcAQMD /1jzh2BoHriy/Q2s4KzzjVp/mQO5DSm2z14BvbQRcXU48oAosHA1u3Wrov6LfPY+0U1tG47X 1BGfnQH+rNAaH0livoSBQ0IPI/8WfIW7ub4qV6HYwWKVqkDkqwcpmGNDbz3gfaDht6nsie5Z pcuCcul4M9CW7Md6zzyvktjnbz61BADGDCopfZC4of0Z3Ka0u8Wik6UJOuqShBt1WcFS8ya1 oB4rc4tXfSHyMF63aPUBMxHR5DXeH+EO2edoSwViDMqWk1jTnYza51rbGY+pebLQOVOxAY7k do5Ordl3wklBPMVEPWoZ61SdbcjhHVwaC5zfiskcxj5wwXd2E9qYlBqRg7QeSm9obiBCYWxk d2luIDxqaGJARnJlZUJTRC5vcmc+iGAEExECACAFAkTQ+awCGwMGCwkIBwMCBBUCCAMEFgID AQIeAQIXgAAKCRBy3lIGd+N/BI6RAJ9S97fvbME+3hxzE3JUyUZ6vTewDACdE1stFuSfqMvM jomvZdYxIYyTUpC5Ag0ERND5ghAIAPwsO0B7BL+bz8sLlLoQktGxXwXQfS5cInvL17Dsgnr3 1AKa94j9EnXQyPEj7u0d+LmEe6CGEGDh1OcGFTMVrof2ZzkSy4+FkZwMKJpTiqeaShMh+Goj XlwIMDxyADYvBIg3eN5YdFKaPQpfgSqhT+7El7w+wSZZD8pPQuLAnie5iz9C8iKy4/cMSOrH YUK/tO+Nhw8Jjlw94Ik0T80iEhI2t+XBVjwdfjbq3HrJ0ehqdBwukyeJRYKmbn298KOFQVHO EVbHA4rF/37jzaMadK43FgJ0SAhPPF5l4l89z5oPu0b/+5e2inA3b8J3iGZxywjM+Csq1tqz hltEc7Q+E08AAwUIAL+15XH8bPbjNJdVyg2CMl10JNW2wWg2Q6qdljeaRqeR6zFus7EZTwtX sNzs5bP8y51PSUDJbeiy2RNCNKWFMndM22TZnk3GNG45nQd4OwYK0RZVrikalmJY5Q6m7Z16 4yrZgIXFdKj2t8F+x613/SJW1lIr9/bDp4U9tw0V1g3l2dFtD3p3ZrQ3hpoDtoK70ioIAjjH aIXIAcm3FGZFXy503DOA0KaTWwvOVdYCFLm3zWuSOmrX/GsEc7ovasOWwjPn878qVjbUKWwx Q4QkF4OhUV9zPtf9tDSAZ3x7QSwoKbCoRCZ/xbyTUPyQ1VvNy/mYrBcYlzHodsaqUDjHuW+I SQQYEQIACQUCRND5ggIbDAAKCRBy3lIGd+N/BCO8AJ9j1dWVQWxw/YdTbEyrRKOY8YZNwwCf afMAg8QvmOWnHx3wl8WslCaXaE8= Message-ID: Date: Thu, 1 Aug 2019 11:54:07 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:60.0) Gecko/20100101 Thunderbird/60.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2019 18:54:10 -0000 On 8/1/19 11:09 AM, Ian Lepore wrote: > On Thu, 2019-08-01 at 10:39 -0700, John Baldwin wrote: >> On 7/31/19 8:13 PM, Ed Maste wrote: >>> On Thu, 1 Aug 2019 at 12:51, Rodney W. Grimes < >>> freebsd@gndrsh.dnsmgr.net> wrote: >>>> >>>> That would be fine, the important thing is that the >>>> r350505 gets listed in the file, >>> >>> I don't see any reason that r350505 specifically should be in a >>> release note - this is a minor clarification of an existing >>> deprecation notice. It seems having an overall "deprecation >>> notices" >>> section in the release notes would make sense, but they should >>> really >>> persist from version to version. Should we add a top-level >>> DEPRECATION_NOTICES file perhaps? Or tag deprecation notices with >>> some >>> sort of comment in the source so they can be found with a 'grep' >>> during release preparation? >> >> I think it would make sense to have "sections" in RELNOTES that mimic >> the sections we have in the existing release notes (e.g. kernel vs >> userland). That is effectively what GDB does with a top level NEWS >> file. This approach would hopefully make it easier to translate this >> file into the real release notes. It also means that a given "note" >> can evolve over time (e.g. it might start with "XYZ is deprecated" to >> "XYZ is removed" if a deprecation note is added and merged and later >> it >> is removed) rather than only having a running journal ala UPDATING. >> >> On the question of whether we want a dedicated section just for >> deprecation notices, I'm not sure. Probably we can just stick with >> the >> layout of our existing release notes? >> > > I wonder why it is that this relnotes file is some kind of major > attractor for complexity? > > As I understand it, the *entire* intent of this file was "if you forget > to add Relnotes: yes" to a commit, this gives you a way to flag the > commit after the fact, since commit messages are immutable. > > If people realize they forgot Relnotes: yes, and the remedy for that is > that they have to spelunk around in some complex formatted file to find > the "right section" (whatever that means)... well, I think in the real > world: they won't. My assumption was that relnotes would remain a simple text file. I think the win is that you aren't editing XML or SGML or the like, and that you can go back and edit existing entries if needed as well as document something when you missed relnotes: yes. The more work we put into having something closer to the finished product in this file, the less work re@ has to do to parse commit messages. -- John Baldwin