Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 24 Jun 2019 06:50:26 -0700
From:      Cy Schubert <Cy.Schubert@cschubert.com>
To:        freebsd-hackers@freebsd.org, Glen Barber <gjb@freebsd.org>, "Bjoern A. Zeeb" <bz@freebsd.org>
Cc:        Mark Johnston <markj@freebsd.org>,re@freebsd.org
Subject:   Re: release notes file
Message-ID:  <7802C1A1-8E79-40F1-9253-CA0E632EAD2B@cschubert.com>
In-Reply-To: <20190623234845.GE41944@FreeBSD.org>
References:  <20190623191818.GA84365@raichu> <55030704-F521-4D6E-9B56-4B7F65EFFC38@FreeBSD.org> <20190623234845.GE41944@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On June 23, 2019 4:48:45 PM PDT, Glen Barber <gjb@freebsd=2Eorg> wrote:
>On Sun, Jun 23, 2019 at 11:23:57PM +0000, Bjoern A=2E Zeeb wrote:
>> On 23 Jun 2019, at 19:18, Mark Johnston wrote:
>>=20
>> Hi,
>>=20
>> > Today we add a Relnotes tag to commits that warrant a release note=2E
>> > 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=2E  I would like to propose adding a
>top-level
>> > RELNOTES file instead, which like UPDATING would document notes for
>> > specific commits=2E  It would be truncated every time the head branch
>is
>> > forked, and changes to it would be MFCed=2E  This fixes the
>> > above-mentioned problems and would hopefully reduce the amount of
>time
>> > needed by re@ to compile release notes=2E
>>=20
>> Hooray=2E  Can we put that file into the doc repo, so that the ports
>people,
>> and the docs people, and all other kinds of hats can put things in
>there as
>> well?
>>=20
>> Oh, the release notes go into the doc repo anyway=2E  Can we just put
>them in
>> the right place and just fill them from a skeleton where they should
>be and
>> naturally grow the document (feel free to use a different markup
>language
>> once doc is ready for that)=2E
>>=20
>> Oh, with that release notes are written automatically and you are
>still
>> responsible for that your stuff is in there=2E  And the release notes
>only
>> need an editing pass in the end?
>>=20
>> And the wiki pages like =E2=80=9CWhat=E2=80=99s cooking for 13?=E2=80=
=9D or similar could
>just
>> vanish as we=E2=80=99d have these updated at least every 10 minutes
>automatically =2E=2E
>> on our web server under /releases/ where they belong =2E=2E
>>=20
>> How amazing would that be?
>
>Very=2E
>
>But, I have one non-important nit -- the file in question does not need
>to be formatted for the documentation language of the day=2E  In other
>words, I do not see this file as a "copy/paste from here to there and
>be
>done with it" sort of thing; i=2Ee=2E, grammar nits, clarifications that
>stray from the original commit log (or commit log intent), etc=2E
>
>When re@ requests clarification on commits or prods committers for
>things that may not have otherwise made it into the release notes, it
>isn't sent as a "please send us the properly-formatted XML entry" or
>some such thing, so personally, I am perfectly fine with a 80-character
>line-length raw plain-text entry=2E
>
>Just my $0=2E02 USD=2E
>
>Glen

I disagree=2E It should be a =2Emd file to display properly on github=2E=
=20


--=20
Pardon the typos and autocorrect, small keyboard in use=2E
Cheers,
Cy Schubert <Cy=2ESchubert@cschubert=2Ecom>
FreeBSD UNIX: <cy@FreeBSD=2Eorg> Web: http://www=2EFreeBSD=2Eorg

	The need of the many outweighs the greed of the few=2E



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?7802C1A1-8E79-40F1-9253-CA0E632EAD2B>