> On Thu, 2019-08-01 at 10:39 -0700, John Baldwin wrote: > > On 7/31/19 8:13 PM, Ed Maste wrote: > > > On Thu, 1 Aug 2019 at 12:51, Rodney W. Grimes < > > > free...@gndrsh.dnsmgr.net> wrote: > > > > > > > > That would be fine, the important thing is that the > > > > r350505 gets listed in the file, > > > > > > I don't see any reason that r350505 specifically should be in a > > > release note - this is a minor clarification of an existing > > > deprecation notice. It seems having an overall "deprecation > > > notices" > > > section in the release notes would make sense, but they should > > > really > > > persist from version to version. Should we add a top-level > > > DEPRECATION_NOTICES file perhaps? Or tag deprecation notices with > > > some > > > sort of comment in the source so they can be found with a 'grep' > > > during release preparation? > > > > I think it would make sense to have "sections" in RELNOTES that mimic > > the sections we have in the existing release notes (e.g. kernel vs > > userland). That is effectively what GDB does with a top level NEWS > > file. This approach would hopefully make it easier to translate this > > file into the real release notes. It also means that a given "note" > > can evolve over time (e.g. it might start with "XYZ is deprecated" to > > "XYZ is removed" if a deprecation note is added and merged and later > > it > > is removed) rather than only having a running journal ala UPDATING. > > > > On the question of whether we want a dedicated section just for > > deprecation notices, I'm not sure. Probably we can just stick with > > the > > layout of our existing release notes? > > > > I wonder why it is that this relnotes file is some kind of major > attractor for complexity? > > As I understand it, the *entire* intent of this file was "if you forget > to add Relnotes: yes" to a commit, this gives you a way to flag the > commit after the fact, since commit messages are immutable. > > If people realize they forgot Relnotes: yes, and the remedy for that is > that they have to spelunk around in some complex formatted file to find > the "right section" (whatever that means)... well, I think in the real > world: they won't.
That was my original intent when "I" first proposed this, imho that is as simple as it needs to be. Markj then later proposed this file here in a review, which I did give some feedback on, and here we are now, having discussion that probably would of better been had during a wider review process. Regards, Rod -- Rod Grimes rgri...@freebsd.org _______________________________________________ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"