release notes file

[Warner Losh]

On Sun, Jun 23, 2019 at 1:56 PM Glen Barber <gjb at freebsd.org> wrote:

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

A while ago, I proposed a protocol that we'd only have the RELNOTES file.

The other part of the protocol was to remove it from RELNOTES once it was
added to the release notes. This way, we can have multiple people working
on the release notes should we be so fortunate to have those resources in
the future. It's minorly racy, but not terrible. This way, release notes
text could also be written by the committer and tweaked by whomever
compiles the release notes.

However, I'm cool with having it in the commit message + template since
it's better to have a heads up you need to write something than not. The
understanding would be a RelNotes: yes would mean that someone else would
write the notes and if you wanted to have more control over what went out,
you'd use RELNOTES.

Glen, do you think that's a workable protocol?

Warner


> 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?
> >>
> >
>
> _______________________________________________
> freebsd-hackers at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe at freebsd.org"
>