Date: Mon, 10 Dec 2018 10:17:03 +0100 From: Stefan Esser <se@freebsd.org> To: Warner Losh <imp@bsdimp.com>, Cy Schubert <Cy.Schubert@cschubert.com>, "Rodney W. Grimes" <rgrimes@freebsd.org>, Oliver Pinter <oliver.pinter@hardenedbsd.org>, Cy Schubert <cy@freebsd.org> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers <src-committers@freebsd.org> 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... Message-ID: <2b0c3d91-54b6-37d9-e934-a87629b399fd@freebsd.org> In-Reply-To: <CANCZdfqOGasnJP_VE1AAqMQakQUpTQN6XMhyVf4Z%2BMWoLJRFwQ@mail.gmail.com> References: <freebsd@pdx.rh.CN85.dnsmgr.net> <201812100619.wBA6JB0c064609@pdx.rh.CN85.dnsmgr.net> <201812100640.wBA6eaMA052004@slippy.cwsent.com> <CANCZdfqOGasnJP_VE1AAqMQakQUpTQN6XMhyVf4Z%2BMWoLJRFwQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Am 10.12.18 um 07:47 schrieb Warner Losh: > > > On Sun, Dec 9, 2018, 11:40 PM Cy Schubert <Cy.Schubert@cschubert.com > <mailto:Cy.Schubert@cschubert.com> wrote: > > In message <201812100619.wBA6JB0c064609@pdx.rh.CN85.dnsmgr.net > <mailto: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 <mailto:oliver.pinter@hardenedbsd.org> > > > > > > wrote: > > > > > > > > > > > > > > > On Sunday, December 9, 2018, Warner Losh <imp@bsdimp.com > <mailto:imp@bsdimp.com>> wrote: > > > > > > > >> On Sun, Dec 9, 2018 at 1:09 PM Rodney W. Grimes < > > > >> freebsd@pdx.rh.cn85.dnsmgr.net > <mailto:freebsd@pdx.rh.cn85.dnsmgr.net>> wrote: > > > >> > > > >> > > In message <201812090645.wB96jnso066329@repo.freebsd.org > <mailto:201812090645.wB96jnso066329@repo.freebsd.org>>, 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. IMHO it would be easiest to use and to remember to just perform a forced commit to any of the files affected by the change and to set RELNOTES in that commit. The commit message could further contain a SVN revision number of the relevant change (mandatory, if it has not been the previous commit to that file) and optionally an explanatory text for the RE. This could be automated by allowing the revision affected (or a few words of explanation) to be put on the RELNOTES line - assume there already is a script that scans the repository for such entries and that script could be enhanced to automatically retrieve the commit message from a referenced earlier commit, for example. Regards, STefan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?2b0c3d91-54b6-37d9-e934-a87629b399fd>