From owner-freebsd-hackers@freebsd.org Mon Jun 24 17:06:37 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 08A1915D2E86 for ; Mon, 24 Jun 2019 17:06:37 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from smtp-out-so.shaw.ca (smtp-out-so.shaw.ca [64.59.136.139]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id C7D6776A7C; Mon, 24 Jun 2019 17:06:34 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from spqr.komquats.com ([70.67.125.17]) by shaw.ca with ESMTPA id fSQFhoxISGusjfSQHhalbC; Mon, 24 Jun 2019 11:06:31 -0600 X-Authority-Analysis: v=2.3 cv=fOdHIqSe c=1 sm=1 tr=0 a=VFtTW3WuZNDh6VkGe7fA3g==:117 a=VFtTW3WuZNDh6VkGe7fA3g==:17 a=jpOVt7BSZ2e4Z31A5e1TngXxSK0=:19 a=IkcTkHD0fZMA:10 a=dq6fvYVFJ5YA:10 a=iKhvJSA4AAAA:8 a=YxBL1-UpAAAA:8 a=6I5d2MoRAAAA:8 a=eeSdjhnMUMhRrhh-RzUA:9 a=4pr309j300RNxBSQ:21 a=K4irkvPNajIRuIrX:21 a=QEXdDO2ut3YA:10 a=odh9cflL3HIXMm4fY7Wr:22 a=Ia-lj3WSrqcvXOmTRaiG:22 a=IjZwj45LgO3ly-622nXo:22 Received: from android-9b917f0ce39da6e6.esitwifi.local (S0106788a207e2972.gv.shawcable.net [70.66.154.233]) by spqr.komquats.com (Postfix) with ESMTPSA id 1832BB59; Mon, 24 Jun 2019 10:06:26 -0700 (PDT) Date: Mon, 24 Jun 2019 10:06:02 -0700 User-Agent: K-9 Mail for Android In-Reply-To: <201906241629.x5OGTmpd044504@gndrsh.dnsmgr.net> References: <201906241629.x5OGTmpd044504@gndrsh.dnsmgr.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: release notes file To: "Rodney W. Grimes" , Warner Losh CC: "freebsd-hackers@freebsd.org" , "Bjoern A. Zeeb" , Mark Johnston , FreeBSD Release Engineering Team From: Cy Schubert Message-ID: <2BD397BB-FD96-4A06-9263-DD35B2CA494D@cschubert.com> X-CMAE-Envelope: MS4wfFjQd+0BohiBZ34aGNbyc7umoozE7cSYIXHVkJcBPrkcWHsPiHJ0E2XCDIqsrmcNo8mleJT6XJisU+8zAuaSoq52yMlD3g8IZtnn11ijK2V7VPhslNa7 ghMI9qJ0X/Ioi0vUijJKa2YFabE/9OHOWn6neIbgzTPDyt+RylcUZJyBA9wkOVcF+Cr3eSEr4QNOGQL8EQ/C8xdjdW+XU/aAlJIiLnjfEEdNWglx9Y1v2Pp5 Tl1ZnzO4VhjHADlwCYzKaJ4MUyBUNS3bKUsKkgl+8YBWHi987sxCzhJ2lbp9ZQhWleEZK/Rm60EavIz4bvEQAh+JsMwi7o8BrkAe4Og+/3E= X-Rspamd-Queue-Id: C7D6776A7C X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-5.58 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; RCPT_COUNT_FIVE(0.00)[6]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MX_GOOD(-0.01)[cached: spqr.komquats.com]; NEURAL_HAM_SHORT(-0.98)[-0.977,0]; RECEIVED_SPAMHAUS_PBL(0.00)[17.125.67.70.zen.spamhaus.org : 127.0.0.11,233.154.66.70.zen.spamhaus.org : 127.0.0.11]; R_SPF_NA(0.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[139.136.59.64.list.dnswl.org : 127.0.5.1]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:6327, ipnet:64.59.128.0/20, country:CA]; MID_RHS_MATCH_FROM(0.00)[]; IP_SCORE(-2.39)[ip: (-6.05), ipnet: 64.59.128.0/20(-3.27), asn: 6327(-2.54), country: CA(-0.09)]; FROM_EQ_ENVFROM(0.00)[] 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: Mon, 24 Jun 2019 17:06:37 -0000 On June 24, 2019 9:29:48 AM PDT, "Rodney W=2E Grimes" wrote: >> On Mon, Jun 24, 2019 at 9:44 AM Cy Schubert > >> wrote: >>=20 >> > On June 23, 2019 5:36:16 PM PDT, Mark Johnston >wrote: >> > >On Sun, Jun 23, 2019 at 11:23:57PM +0000, Bjoern A=2E Zeeb wrote: >> > >> On 23 Jun 2019, at 19:18, Mark Johnston wrote: >> > >> >> > >> Hi, >> > >> >> > >> > Today we add a Relnotes tag to commits that warrant a release >note=2E >> > >> > My impression is that it doesn't work so well: if a committer >> > >forgets >> > >> > or doesn't know to add one there's no way to amend the commit >> > >message >> > >> > (same for MFCs), and a commit message isn't a convenient place >to >> > >> > write >> > >> > the text of a release note=2E I would like to propose adding a >> > >> > top-level >> > >> > RELNOTES file instead, which like UPDATING would document >notes for >> > >> > specific commits=2E It would be truncated every time the head >branch >> > >is >> > >> > forked, and changes to it would be MFCed=2E This fixes the >> > >> > above-mentioned problems and would hopefully reduce the amount >of >> > >time >> > >> > needed by re@ to compile release notes=2E >> > >> >> > >> Hooray=2E Can we put that file into the doc repo, so that the >ports >> > >> people, and the docs people, and all other kinds of hats can put >> > >things >> > >> in there as well? >> > > >> > >Virtually all of the 12=2E0 release notes are for src/ (there are 4 >lines >> > >for ports/pkg and 1 line for docs, and the latter describes a new >man >> > >page in src)=2E Why is it important to have a single place for >everyone >> > >to commit their entries? >> > > >> > >> Oh, the release notes go into the doc repo anyway=2E Can we just >put >> > >them >> > >> in the right place and just fill them from a skeleton where they >> > >should >> > >> be and naturally grow the document (feel free to use a different >> > >markup >> > >> language once doc is ready for that)=2E >> > >> >> > >> Oh, with that release notes are written automatically and you >are >> > >still >> > >> responsible for that your stuff is in there=2E And the release >notes >> > >only >> > >> need an editing pass in the end? >> > >> >> > >> And the wiki pages like ?What?s cooking for 13?? or similar >could >> > >> just vanish as we?d have these updated at least every 10 minutes >> > >> automatically =2E=2E on our web server under /releases/ where they >belong >> > >=2E=2E >> > >> >> > >> How amazing would that be? >> > > >> > >I would guess that many src committers simply won't add release >notes >> > >if >> > >they have to commit to a second repository and use some unfamiliar >> > >markup format and worry about validating the file=2E There are lots >of >> > >__FreeBSD_version bumps that go undocumented until someone else >goes in >> > >and fills in the missing entries=2E A plain-text file in src repo >for >> > >src >> > >release notes is low-friction and creates only marginally more >work for >> > >RE=2E "What's cooking for 13?" can just point to the copy of >RELNOTES in >> > >svnweb=2E >> > > >> > >That said, I personally would try to commit my release notes to a >doc >> > >repo file if one existed=2E I've spent a few minutes trying to >compile >> > >the 12=2E0 notes on my desktop and have not been able to get past, >> > >"cannot >> > >parse >http://www=2EFreeBSD=2Eorg/XML/share/xml/freebsd-xhtml-release=2Exsl"=2E >> > >So, I'm probably not a good person to set up release notes for >13=2E0=2E I >> > >will help fill in entries for commits since the 12=2E0 if someone >else >> > >does that setup=2E >> > >_______________________________________________ >> > >freebsd-hackers@freebsd=2Eorg mailing list >> > >https://lists=2Efreebsd=2Eorg/mailman/listinfo/freebsd-hackers >> > >To unsubscribe, send any mail to >> > >"freebsd-hackers-unsubscribe@freebsd=2Eorg" >> > >> > Src and ports should each have their own RELNOTES file=2E >> > >> > The only operational concern I have is trimming the file, probably >when a >> > branch goes EOL=2E >> > >>=20 >> I'd add truncating the file on -current to the list of things we do >when we >> branch=2E then we can MFC RELNOTES as we MFC the features they >describe=2E > >I disagree, truncating the file on -current destroys the list of >changes that are still in current that need to get into the next >set of release notes=2E > >Howerver there is 1 point on head/ to truncate the file=2E >That is when we create a new =2E0 branch as that is the tree state >that has nothing to put in the release notes=2E This may be the >most sane path forward that I had not thought of before=2E All >other branched versions can just continue to grow until EOL=2E >This bounds the file to about a 2=2E5 year collection in head/, >and a 5=2E0 year collection in stable/=2E >It may make since to truncate on stable/X when stable/X=2EY's >are created=2E > >I think we need to be fairly careful with the MFCing of this, >that may work fine for things that are commited with a RELNOTES >entry, something in the back of my head is screaming lots of >merge conflicts but I can not put a solid finger on it=2E > >Something just hit me, what commit number goes in this file, >if we list it by rXXXXXX of head, that has a rYYYYYY when MFC'ed, >probably need to track both? Which means all existing entries get >an added line at stable/X creation to indicated the commit that >created the branch? If we try to simplify and only track by=20 >head commit that makes it harded to go find the MFC and see >if there was merge munging to make it work=2E > >> Warner Which is why trimming at branch EOL probably makes the most sense=2E It's = simple and easy to implement=2E As for what to do about MFCs and more specifically conflicts, conflicts wi= ll be unavoidable=2E IMO conflicts with RELNOTES will be as likely as with = UPDATING or Obsoletefiles=2E=20 --=20 Pardon the typos and autocorrect, small keyboard in use=2E Cheers, Cy Schubert FreeBSD UNIX: Web: http://www=2EFreeBSD=2Eorg The need of the many outweighs the greed of the few=2E