Skip site navigation (1)Skip section navigation (2)
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>