From owner-freebsd-hackers@freebsd.org Sun Jun 23 20:19:46 2019 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A874515D9A03 for ; Sun, 23 Jun 2019 20:19:46 +0000 (UTC) (envelope-from gjb@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (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 "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 455F76DFC8; Sun, 23 Jun 2019 20:19:46 +0000 (UTC) (envelope-from gjb@freebsd.org) Received: from FreeBSD.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by freefall.freebsd.org (Postfix) with ESMTPS id B4CAA1E067; Sun, 23 Jun 2019 20:19:45 +0000 (UTC) (envelope-from gjb@freebsd.org) Date: Sun, 23 Jun 2019 20:19:43 +0000 From: Glen Barber To: Warner Losh Cc: Mark Johnston , "freebsd-hackers@freebsd.org" , FreeBSD Release Engineering Team Subject: Re: release notes file Message-ID: <20190623201943.GB41944@FreeBSD.org> References: <20190623191818.GA84365@raichu> <6B485E5C-9C8A-43C8-BD5A-528A74A61A23@FreeBSD.org> <79B7AEEE-7617-44D8-A16A-C8EC5F95455A@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="bCsyhTFzCvuiizWE" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.11.2 (2019-01-07) X-Rspamd-Queue-Id: 455F76DFC8 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-2.96 / 15.00]; local_wl_from(0.00)[freebsd.org]; NEURAL_HAM_MEDIUM(-1.00)[-0.997,0]; NEURAL_HAM_SHORT(-0.97)[-0.967,0]; ASN(0.00)[asn:11403, ipnet:2610:1c1:1::/48, country:US]; NEURAL_HAM_LONG(-1.00)[-1.000,0] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Jun 2019 20:19:46 -0000 --bCsyhTFzCvuiizWE Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jun 23, 2019 at 02:01:31PM -0600, Warner Losh wrote: > On Sun, Jun 23, 2019 at 1:56 PM Glen Barber wrote: >=20 > > FWIW, I don=E2=80=99t think =E2=80=9Ceither/or=E2=80=9D is necessarily = the best approach; meaning > > I would like to still keep the tag in the default template. > > >=20 > A while ago, I proposed a protocol that we'd only have the RELNOTES file. >=20 > The other part of the protocol was to remove it from RELNOTES once it was > added to the release notes. This way, we can have multiple people working > on the release notes should we be so fortunate to have those resources in > the future. It's minorly racy, but not terrible. This way, release notes > text could also be written by the committer and tweaked by whomever > compiles the release notes. >=20 > However, I'm cool with having it in the commit message + template since > it's better to have a heads up you need to write something than not. The > understanding would be a RelNotes: yes would mean that someone else would > write the notes and if you wanted to have more control over what went out, > you'd use RELNOTES. >=20 > Glen, do you think that's a workable protocol? >=20 It's kind of difficult for me to put the words together that effectively conveys what I'm thinking or where my mindset is here, but I'll try. I am in full support of a RELNOTES file, but I think that should be supplementary to the 'Relnotes: yes' (or other variations of a non-empty tag). I am conflicted on removing entries from a RELNOTES file once they are added to the release notes, because that might be a more convenient way for end users to get an idea of what changed. However, "Relnotes: yes" does not solve this for those folks. It is easy to truncate the file when a new branch is created, just as a workflow example, but I think the larger thing here is that while there are folks that commit something without "Relnotes: yes" because they forgot (or it did not occur to them at the time that it is a user-visible change), it can be equally difficult to remember to update a file specifically dedicated to this. All that said, having at least a sample text of what to include would be extremely helpful, at least for me, as sometimes I have to ping committers out-of-band to understand why a particular commit was flagged as "Relnotes: yes". Hopefully all that made sense. :) Glen --bCsyhTFzCvuiizWE Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEjRJAPC5sqwhs9k2jAxRYpUeP4pMFAl0P3t8ACgkQAxRYpUeP 4pOKOg/+InmQCz8IfEfPQx8OcAewG7OJq+3+6Hlfs6e0KIJstgqW0npq+G8XQJVT JnYaidIazq/mTGV10ipHQQ4V4w1dcNyqKaw9ovaHAmCXc7iWEqtHKoZlh9udwRKL sj2UV9cmyQ7kDscblloHSpyUVkciuJUM8QRaC0km53Ax2p1NQ4xXEVH2FHFAIYal L0P9sn+KUtQ/WejHd98cdo/3SIML353R2G690mFu7io/1Fk3Wm26myxU9f1iBVxx l+xQfsIoTHV9zT1ocbH9uqSIJfPyxTyF79wm4YYyuA9KhVH/2rzD3ZNIbYA96hvq 74yIhZY/xQCZUi4w3usVqNfAF0mmi0EzmMRtLeX4wEh2TpKcc9nt4lwV/zDAHFLj Lg52z5lp2JftyvvlgYsZkAnIfNeUTYr/aIhl8tbLn7W7EO1Oe27udUB5roXWq6Yp dr8icx9PsPtqYh64dW5NMMGImtdYwV6nTlCeRZIwOM/qi/ZF9qKcWcNoqG9raGHs vKHxrjnjrvYkaKYei9Vkkj5vJaZ/wMp8sX6IHXSNAdF6ML9N7yQGS5PDepoUSJQP 6sd3upyjcSWHJDPeWk9sqrk7SkpnKNKYvrCrYLw2Ck3YCgMj6RgxcOfQXO/4qITQ q7CN1Eh/zH2F6SgbXXaaGIanu/dweuAshNCrtF5hqaCC7iR+ozc= =I8/2 -----END PGP SIGNATURE----- --bCsyhTFzCvuiizWE--