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

Rodney W. Grimes freebsd at pdx.rh.CN85.dnsmgr.net
Mon Dec 10 06:34:34 UTC 2018


> 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,
I do not think this is going to create any sizeable
amount of repo bloat.

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

wiki.freebsd.org is out of the question, to far away from
the commit button to ever be used by most developers.

> 
> otoh, is 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/.

Again, doc repo is too far away for most developers to
ever both with a commit to the doc repository, however
we have move the release notes to the doc repository,
but that is mostly release engineering doing work on
that.

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

Release notes are already there, but putting this file
there would ensure that no developer ever adds anything
to it.  That would also mean 2 commits for any relnotes
type thing, one to the base repository and another to
the docs repository, and that would lose the self referential
svn version that I mentioned in my reply to imp@

-- 
Rod Grimes                                                 rgrimes at freebsd.org


More information about the svn-src-head mailing list