From owner-svn-src-head@freebsd.org Mon Dec 10 17:14:40 2018 Return-Path: Delivered-To: svn-src-head@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 D082E132D5F9; Mon, 10 Dec 2018 17:14:39 +0000 (UTC) (envelope-from freebsd@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 25F4A83D28; Mon, 10 Dec 2018 17:14:38 +0000 (UTC) (envelope-from freebsd@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (localhost [127.0.0.1]) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3) with ESMTP id wBAHEXmW066678; Mon, 10 Dec 2018 09:14:33 -0800 (PST) (envelope-from freebsd@pdx.rh.CN85.dnsmgr.net) Received: (from freebsd@localhost) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3/Submit) id wBAHEX7G066677; Mon, 10 Dec 2018 09:14:33 -0800 (PST) (envelope-from freebsd) From: "Rodney W. Grimes" Message-Id: <201812101714.wBAHEX7G066677@pdx.rh.CN85.dnsmgr.net> Subject: Re: svn commit: r341759 - in head: contrib/wpa contrib/wpa/hostapd contrib/wpa/hs20/client contrib/wpa/src/ap contrib/wpa/src/common contrib/wpa/src/crypto contrib/wpa/src/drivers contrib/wpa/src/eap_c... In-Reply-To: <1544458929.1860.329.camel@freebsd.org> To: Ian Lepore Date: Mon, 10 Dec 2018 09:14:33 -0800 (PST) CC: Warner Losh , Cy Schubert , "Rodney W. Grimes" , Oliver Pinter , svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers , Cy Schubert Reply-To: rgrimes@freebsd.org X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Rspamd-Queue-Id: 25F4A83D28 X-Spamd-Result: default: False [1.99 / 15.00]; ARC_NA(0.00)[]; HAS_REPLYTO(0.00)[rgrimes@freebsd.org]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[dnsmgr.net]; REPLYTO_DOM_NEQ_FROM_DOM(0.00)[]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(0.91)[0.907,0]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MX_GOOD(-0.01)[cached: pdx.rh.CN85.dnsmgr.net]; NEURAL_SPAM_LONG(0.69)[0.695,0]; RCPT_COUNT_SEVEN(0.00)[9]; NEURAL_HAM_SHORT(-0.48)[-0.476,0]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:13868, ipnet:69.59.192.0/19, country:US]; MID_RHS_MATCH_FROM(0.00)[]; IP_SCORE(-0.03)[asn: 13868(-0.04), country: US(-0.09)] X-Rspamd-Server: mx1.freebsd.org X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Dec 2018 17:14:40 -0000 > On Sun, 2018-12-09 at 23:47 -0700, Warner Losh wrote: > > On Sun, Dec 9, 2018, 11:40 PM Cy Schubert > wrote: > > > > > > > > In message <201812100619.wBA6JB0c064609@pdx.rh.CN85.dnsmgr.net>, > > > "Rodney W. Gri > > > mes" writes: > > > > > > > > > > > > > > On Sun, Dec 9, 2018 at 2:03 PM Oliver Pinter < > > > oliver.pinter@hardenedbsd.org > > > > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Sunday, December 9, 2018, Warner Losh > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > On Sun, Dec 9, 2018 at 1:09 PM Rodney W. Grimes < > > > > > > > freebsd@pdx.rh.cn85.dnsmgr.net> wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > In message <201812090645.wB96jnso066329@repo.freebsd.or > > > > > > > > > g>, Cy > > > > > > > Schubert > > > > > > > > > > > > > > > > > > > > > > > > > > writes: > > > > > > > > > > > > > > > > > > > > Author: cy > > > > > > > > > > Date: Sun Dec??9 06:45:49 2018 > > > > > > > > > > New Revision: 341759 > > > > > > > > > > URL: https://svnweb.freebsd.org/changeset/base/341759 > > > > > > > > > > > > > > > > > > > > Log: > > > > > > > > > > ? MFV r341618: > > > > > > > > > > > > > > > > > > > > ? Update wpa 2.6 --> 2.7. > > > > > > > > > Relnotes: yes > > > > > > > > As an FYI, or maybe a new procedure, doing a reply to > > > > > > > > a commit message adding relnotes: yes does very little > > > > > > > > to insure that this commit gets refered to in release > > > > > > > > notes. > > > > > > > > > > > > > > > > What about we add RELNOTES.missed to the tree > > > > > > > > next to UPDATING, and when someone forgets to tag > > > > > > > > the Relnotes:yes into a commit you just follow up > > > > > > > > with a commit to that file, stating the svn revision > > > > > > > > which was missing the note and then we have a nice > > > > > > > > documented and clean way to extract the missing > > > > > > > > release note items, rather than trying to cull it > > > > > > > > from a thread in a mail list archive. > > > > > > > > > > > > > > > > The file would get truncated to 0 at appropriate > > > > > > > > times on various branches. > > > > > > > > > > > > > > > How about just RELNOTES. You put the revision that is > > > > > > > relevant and > > > a qui > > > > > > > > ck > > > > > > > > > > > > > > > > > > > > > > > > > blurb. That way we don't have to look in two places. All > > > > > > > release > > > notes g > > > > > > > > o > > > > > > > > > > > > > > > > > > > > > > > > > in here, no exceptions. You can retroactively tag them, or > > > > > > > you can > > > commi > > > > > > > > t > > > > > > > > > > > > > > > > > > > > > > > > > this as part of commit. > > > > My one concern is that if we remove the Relnotes: yes line > > > > from the commits then we may end up totally ignoring the > > > > need to put entries in RELNOTES, which unlike UPDATING > > > > do not have consequences if ignored. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I don't really know SVN, but there wouldn't be a chicken egg > > > > > > probem > > > durin > > > > > > > > g > > > > > > > > > > > > > > > > > commit time? I mean you would really know the SVN id. So you > > > > > > could > > > only a > > > > > > > > dd > > > > > > > > > > > > > > > > > a specific revision in a different commit to RELEASE file. > > > > > > > > > > > Generally, you can guess really well, and fix it in the case of > > > > > a lost > > > race > > > > > > > > > > > > > > easily. > > > > No reason to guess, if you add the RELNOTES change with the > > > > commit > > > > then it is the revision that added the RELNOTES entry, so a log > > > > view > > > > of RELNOTES would show you the revision.??If you do it after > > > > words > > > > or edit an existing entry in the RELNOTES file that is also > > > > fairly > > > > clear as that commit has no other files touched. > > > > > > > > > > > > > > > > > > > You'd add the release notes text in full to the file, with a > > > > > pointer > > > to the > > > > > > > > > > > > > > revision(s) for the feature. > > > > If you modify RELNOTES with the commit adding the feature we > > > > could easily use a pointer of "this commit", the svn version > > > > number > > > > of that added entry is self referencing to the actual change, > > > > which I actually rather like the idea of. > > > > > > > > > > > > > > > > > > > Warner > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Have a blurb at the top that tells people what > > > > > > > order to add them in, and you'd be set. We'd then retire > > > > > > > "relnotes: > > > yes" > > > > > > > > > > > > > > > > > > > > > > > > > > > > > in > > > > > > > the commit message. This would also allow 'helpers' to > > > > > > > format the > > > RELNOT > > > > > > > > ES > > > > > > > > > > > > > > > > > > > > > > > > > file as we go rather than having to play 2 years of catch- > > > > > > > up at > > > major > > > > > > > > > > > > > > > > > > > > > > > > > > > > > branch times. > > > > Yes.??You could actually "delete" an entry from RELNOTES once a > > > > proper entry in the actual release notes had been created, such > > > > that RELNOTES is really a list of pending items. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Having it in the commit message just doesn't work, and this > > > > > > > is one > > > of ma > > > > > > > > ny > > > > > > > > > > > > > > > > > > > > > > > > > reasons: Cy forgot. Other times I'll do something and it's > > > > > > > only a > > > month > > > > > > > > > > > > > > > > > > > > > > > > > > > > > later I realize it needs to be in the release notes after > > > > > > > some > > > issue has > > > > > > > > > > > > > > > > > > > > > > > > > > > > > come up.... Other times I put relnotes: yes in only to > > > > > > > realize > > > that's my > > > > > > > > > > > > > > > > > > > > > > > > > > > > > vanity talking, and nobody else cares. > > > > I agree, what we have now works poorly. > > > Forgetting, yes, but also a hmmm moment. > > > > > > Initially my thinking was a file in doc/. Or maybe something like > > > the > > > vuxml port where we fill in the blanks and make validate to make > > > sure > > > all the i's are dotted and t's crossed. It's a little extra work > > > for > > > committers but would help re@ immensely, and get the details in > > > from > > > the get-go. > > > > > > > My thought was a low friction,??proximate way to do a ticker of important > > changes. Doc repo is too hard. Too much friction. A simple extra file puts > > it all in one, easy to find and edit place... it can cause other things to > > happen, further away. But it needs to be close by. > > > > I agree that a RELNOTES file as plain ascii text will be the easiest > thing for src committers to work with, and being easy will definitely > improve the odds of being updated. > > We have empirical data on src committers updating an xml file in the > docs repo, based on documenting version number bumps, and it all too > often doesn't happen, I think laregely because it's a big hassle and > it's out of sight in another repo. On this position I agree fully with Warner and Ian, simple and easy is very important here, and IMHO this RELNOTES file is a simple fix for the missing RelNotes: yes issue. It also allows the committer to actually say more than just "yes". Also note I do not think we would be requireing more than a simple "this should be mentioned in release notes", defanitly are not asking for publication ready notes, though those would be gladly accepted! Can I ask that the community now allows the RE@ team to discuss this internally and come back with a proposal? Feel free to continue discussing on this thread, I'll try to incorporate any items brought up into our discussion. Thanks, -- Rod Grimes rgrimes@freebsd.org