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

Warner Losh imp at bsdimp.com
Sun Dec 9 21:24:20 UTC 2018


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.

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 RELNOTES
>> file as we go rather than having to play 2 years of catch-up at major
>> branch times.
>>
>> Having it in the commit message just doesn't work, and this is one of many
>> 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.
>>
>> Warner
>> _______________________________________________
>> svn-src-head at freebsd.org mailing list
>> https://lists.freebsd.org/mailman/listinfo/svn-src-head
>> To unsubscribe, send any mail to "svn-src-head-unsubscribe at freebsd.org"
>>
>


More information about the svn-src-head mailing list