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...

[Cy Schubert]

In message <CANCZdfqpqN+YUMAxNFKy+nxJo_70Li6osBQMKLzoj6feVugM5g at mail.gma
il.com>
, Warner Losh writes:
> --0000000000009ed486057c9d7878
> Content-Type: text/plain; charset="UTF-8"
>
> On Sun, Dec 9, 2018 at 2:03 PM Oliver Pinter <oliver.pinter at hardenedbsd.org>
> wrote:
>
> >
> >
> > On Sunday, December 9, 2018, Warner Losh <imp at bsdimp.com> wrote:
> >
> >> On Sun, Dec 9, 2018 at 1:09 PM Rodney W. Grimes <
> >> freebsd at pdx.rh.cn85.dnsmgr.net> wrote:
> >>
> >> > > In message <201812090645.wB96jnso066329 at 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 quick
> >> blurb. That way we don't have to look in two places. All release notes go
> >> in here, no exceptions. You can retroactively tag them, or you can commit
> >> this as part of commit.
> >
> >
> >>
> > I don't really know SVN, but there wouldn't be a chicken egg probem during
> > commit time? I mean you would really know the SVN id. So you could only add
> > 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.
>
> You'd add the release notes text in full to the file, with a pointer to the
> revision(s) for the feature.

How about a couple of other alternatives?

Hmmm. Rather than bloat the repo, can we put this onto 
wiki.freebsd.org? Downside, people tend to forget or it's too much of a 
hassle. Upside, no repo bloat.

OTOH, if it is to be a file, IMO it should live in the doc repo. If 
people write up good notes they can be included directly from doc/.

Personally, I prefer "put it in the doc repo" better.


-- 
Cheers,
Cy Schubert <Cy.Schubert at cschubert.com>
FreeBSD UNIX:  <cy at FreeBSD.org>   Web:  http://www.FreeBSD.org

	The need of the many outweighs the greed of the few.