From owner-freebsd-hackers@freebsd.org Mon Jun 24 15:47:45 2019 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7E19515D13B2 for ; Mon, 24 Jun 2019 15:47:45 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qt1-x834.google.com (mail-qt1-x834.google.com [IPv6:2607:f8b0:4864:20::834]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 33D3A7385C for ; Mon, 24 Jun 2019 15:47:44 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qt1-x834.google.com with SMTP id h21so14922883qtn.13 for ; Mon, 24 Jun 2019 08:47:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=/nNIC7BibbWEQuv19OL/SHUH/227BXQMHMvM9yhaPwE=; b=E7A5Kx9X2Osv4Bbx7bWISOg5UiZSpm8yQVt7/FdWD0CoDmcy3Nr5zVXRW7H3YpvdgH DWejt481vhyJgy2RE3tauH5sadkRYm8/sIa0vGA7kseIM5EcgiLkOz4fHTVD3MChB6t3 yHsyAS31DZaExcJKEMDF71MDkppdGcjKUxo2obmBYADQyA9h3MA/Bg5ib8bRX7hrPxMz XkXdUPWxPZErIgXAz0KLhM+xAnMwkLU+eKoxVnXfiLRf+tPiH8heUqCZzhy1u3H5EyFQ 7vmRV8JNUXnvANxh2dVGy0fo1+yu2LuuAmxpnEVi8ciyip8AYMH+JWdVik0SatXzbvxi I5tA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=/nNIC7BibbWEQuv19OL/SHUH/227BXQMHMvM9yhaPwE=; b=K9X+DpQtV9TYBB30z3gTxiIzcHY17WNBBru59lF5hQTmE1jGTpw9rs8JXcEto/QhDO SlTtYKBjs8dRAe27/R6nm9TJCpmq80vXkxbFMhiBicBlYyQH5FdTsG7WJ3g9/UFk3STu R7+4ebOp0A/Di4sqI/xNpeS9zDepx+naUwvwBiQnbQ/v/7c3wwsXVIQH0/xugP+1XgDj xEGRoOjVEnYxlUqDbxw7/dWlAoK90CrtBzg6ZtmSV0WQCXYfsNDnxH1Vca66J8cTI3R5 zMqf1+SArTJgembn6nTtuWr6ELaKE8s55ScWBXOpAH00OaAImaYg+57VVHRVPmMhnr+d 8mUQ== X-Gm-Message-State: APjAAAW9ogNlDyzBxa/07QInPHY7SjunuOKM7/bWknWwCYA1aQOmAB/G MrOgwnrxlzea/IYuBOPop89OQKXAd89JUwJG19V3TQ== X-Google-Smtp-Source: APXvYqxOM803JKCT/C8TGsLKgVJ2L4+dGZPchA8frfEbzvwvQchs/eLoAjWhZ4EZIMUFAxs6kC6ETqu6zuATFG0FVdo= X-Received: by 2002:ac8:244f:: with SMTP id d15mr11112519qtd.32.1561391263360; Mon, 24 Jun 2019 08:47:43 -0700 (PDT) MIME-Version: 1.0 References: <20190623191818.GA84365@raichu> <55030704-F521-4D6E-9B56-4B7F65EFFC38@FreeBSD.org> <20190624003616.GA90409@raichu> <8FF694F5-D5FC-467E-ADBE-244C3A3254D2@cschubert.com> In-Reply-To: <8FF694F5-D5FC-467E-ADBE-244C3A3254D2@cschubert.com> From: Warner Losh Date: Mon, 24 Jun 2019 09:47:32 -0600 Message-ID: Subject: Re: release notes file To: Cy Schubert Cc: "freebsd-hackers@freebsd.org" , Mark Johnston , "Bjoern A. Zeeb" , FreeBSD Release Engineering Team X-Rspamd-Queue-Id: 33D3A7385C X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20150623.gappssmtp.com header.s=20150623 header.b=E7A5Kx9X X-Spamd-Result: default: False [-4.93 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20150623.gappssmtp.com:s=20150623]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; URI_COUNT_ODD(1.00)[5]; RCPT_COUNT_FIVE(0.00)[5]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MX_GOOD(-0.01)[cached: ALT1.aspmx.l.google.com]; DKIM_TRACE(0.00)[bsdimp-com.20150623.gappssmtp.com:+]; RCVD_IN_DNSWL_NONE(0.00)[4.3.8.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; NEURAL_HAM_SHORT(-0.92)[-0.918,0]; R_SPF_NA(0.00)[]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; MIME_TRACE(0.00)[0:+,1:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; IP_SCORE(-3.00)[ip: (-9.48), ipnet: 2607:f8b0::/32(-3.14), asn: 15169(-2.33), country: US(-0.06)]; RCVD_COUNT_TWO(0.00)[2] Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2019 15:47:45 -0000 On Mon, Jun 24, 2019 at 9:44 AM Cy Schubert wrote: > On June 23, 2019 5:36:16 PM PDT, Mark Johnston wrote: > >On Sun, Jun 23, 2019 at 11:23:57PM +0000, Bjoern A. Zeeb wrote: > >> On 23 Jun 2019, at 19:18, Mark Johnston 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. > >> > >> Hooray. 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? > > > >Virtually all of the 12.0 release notes are for src/ (there are 4 lines > >for ports/pkg and 1 line for docs, and the latter describes a new man > >page in src). Why is it important to have a single place for everyone > >to commit their entries? > > > >> Oh, the release notes go into the doc repo anyway. 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). > >> > >> Oh, with that release notes are written automatically and you are > >still > >> responsible for that your stuff is in there. And the release notes > >only > >> need an editing pass in the end? > >> > >> 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 minut= es > >> automatically .. on our web server under /releases/ where they belong > >.. > >> > >> How amazing would that be? > > > >I would guess that many src committers simply won't add release notes > >if > >they have to commit to a second repository and use some unfamiliar > >markup format and worry about validating the file. There are lots of > >__FreeBSD_version bumps that go undocumented until someone else goes in > >and fills in the missing entries. A plain-text file in src repo for > >src > >release notes is low-friction and creates only marginally more work for > >RE. "What's cooking for 13?" can just point to the copy of RELNOTES in > >svnweb. > > > >That said, I personally would try to commit my release notes to a doc > >repo file if one existed. I've spent a few minutes trying to compile > >the 12.0 notes on my desktop and have not been able to get past, > >"cannot > >parse http://www.FreeBSD.org/XML/share/xml/freebsd-xhtml-release.xsl". > >So, I'm probably not a good person to set up release notes for 13.0. I > >will help fill in entries for commits since the 12.0 if someone else > >does that setup. > >_______________________________________________ > >freebsd-hackers@freebsd.org mailing list > >https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > >To unsubscribe, send any mail to > >"freebsd-hackers-unsubscribe@freebsd.org" > > Src and ports should each have their own RELNOTES file. > > The only operational concern I have is trimming the file, probably when a > branch goes EOL. > I'd add truncating the file on -current to the list of things we do when we branch. then we can MFC RELNOTES as we MFC the features they describe. Warner