Date: Sun, 09 Dec 2018 22:40:36 -0800 From: Cy Schubert <Cy.Schubert@cschubert.com> To: rgrimes@freebsd.org Cc: Warner Losh <imp@bsdimp.com>, Oliver Pinter <oliver.pinter@hardenedbsd.org>, svn-src-head@freebsd.org, Cy Schubert <Cy.Schubert@cschubert.com>, svn-src-all@freebsd.org, src-committers <src-committers@freebsd.org>, Cy Schubert <cy@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: <201812100640.wBA6eaMA052004@slippy.cwsent.com> In-Reply-To: Message from "Rodney W. Grimes" <freebsd@pdx.rh.CN85.dnsmgr.net> of "Sun, 09 Dec 2018 22:19:11 -0800." <201812100619.wBA6JB0c064609@pdx.rh.CN85.dnsmgr.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <imp@bsdimp.com> 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.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. -- Cheers, Cy Schubert <Cy.Schubert@cschubert.com> FreeBSD UNIX: <cy@FreeBSD.org> Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201812100640.wBA6eaMA052004>