In message <canczdfqpqn+yumaxnfky+nxjo_70li6osbqmklzoj6fevug...@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.pin...@hardenedbsd.org> > wrote: > > > > > > > On Sunday, December 9, 2018, Warner Losh <i...@bsdimp.com> wrote: > > > >> On Sun, Dec 9, 2018 at 1:09 PM Rodney W. Grimes < > >> free...@pdx.rh.cn85.dnsmgr.net> wrote: > >> > >> > > In message <201812090645.wb96jnso066...@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.schub...@cschubert.com> FreeBSD UNIX: <c...@freebsd.org> Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. _______________________________________________ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
