release notes file

[Glen Barber]

FWIW, I don’t think “either/or” is necessarily the best approach; meaning I would like to still keep the tag in the default template.

Glen
(Who knows first hand how much it sucks going through commit logs for relnotes entries)
Sent from my phone.
Please excuse my brevity and/or typos.

> On Jun 23, 2019, at 3:49 PM, Glen Barber <gjb at freebsd.org> wrote:
> 
> Yes, please.
> 
> Glen
> Sent from my phone.
> Please excuse my brevity and/or typos.
> 
>> On Jun 23, 2019, at 3:18 PM, Mark Johnston <markj at freebsd.org> wrote:
>> 
>> Hi,
>> 
>> Today we add a Relnotes tag to commits that warrant a release note.
>> My impression is that it doesn't work so well: if a committer forgets
>> or doesn't know to add one there's no way to amend the commit message
>> (same for MFCs), and a commit message isn't a convenient place to write
>> the text of a release note.  I would like to propose adding a top-level
>> RELNOTES file instead, which like UPDATING would document notes for
>> specific commits.  It would be truncated every time the head branch is
>> forked, and changes to it would be MFCed.  This fixes the
>> above-mentioned problems and would hopefully reduce the amount of time
>> needed by re@ to compile release notes.
>> 
>> For example:
>> 
>> Index: RELNOTES
>> ===================================================================
>> --- RELNOTES    (nonexistent)
>> +++ RELNOTES    (working copy)
>> @@ -0,0 +1,8 @@
>> +Release notes for FreeBSD 13.0.
>> +
>> +r349286:
>> +    swapon(8) can now erase a swap device immediately before
>> +    enabling it, similar to newfs(8)'s -E option.  This behaviour
>> +    can be specified by adding -E to swapon(8)'s command-line
>> +    parameters, or by adding the "trimonce" option to a swap
>> +    device's /etc/fstab entry.
>> 
>> What do folks think?
>> 
>