From owner-freebsd-hackers@freebsd.org Sun Jun 23 19:18:25 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 A513415D7C48 for ; Sun, 23 Jun 2019 19:18:25 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-io1-xd2d.google.com (mail-io1-xd2d.google.com [IPv6:2607:f8b0:4864:20::d2d]) (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 BB8B16A058; Sun, 23 Jun 2019 19:18:24 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mail-io1-xd2d.google.com with SMTP id e3so1496662ioc.12; Sun, 23 Jun 2019 12:18:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:mime-version :content-disposition:user-agent; bh=QtIvPwUHo1YgKCnXglJ8G0SZbJdTINb7SX6sU24qy9w=; b=KFcno8OAi169Cel5TwFkAxZW0Dsz6jEAhv1V47zjhBsUsb3JeVpvBN3Pt2QCtFPMhN yErg8t872Fw2Qaf6yem9KN+FHPwLVBR44PI1kr4RQ9OLNs1gbHi7T6/hIdOtcnadMHSb oqQTRuO1ijDsXEdPcrA84H9RbVEj3Z3WZ1PVnk3o2onI+6c98x4Mvu5slifRl+VmKAJ9 sHx1K/aDssI7Plih8JBPJp3YFFoXDBiljMLaisjb6oYW7flr37XM9mczdCdqa4MGYzt1 XHTIz1FgIMEqE4PuebVrF+o32sPRl8MVfstM6rPMQ//jT3RcnsaJIwjh0Pzd1Uh5xHyI Wi8g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :mime-version:content-disposition:user-agent; bh=QtIvPwUHo1YgKCnXglJ8G0SZbJdTINb7SX6sU24qy9w=; b=gkGSOROjQKKDIdTdfopgZ/rRsJNaOWrx3iuP6+BchVJJpwzbqz0hlEZGpx/PvG1ptp ILNoSaPYlgjXhIRLpG7Ew5zYejLaEPX8CJj1sbOkf6VO7nn75WwTOrTG2rLDPCPqrVOn 4mHBvswMCVAIKoIqGaLNqeVdcqXFYZ6VeoUyRqfGiqrymKGxn4gURI7YCk5sHwLTfWHZ OrAHxcNbqEJ1zDKXcFwz64Woz22xVrLOANozibek3u9/TJ5FWV/K04ZIBzpP56hfWArr p6kE9eNTEY2JsHbKmCp9KGYBw1JY9hgzRmRIiwCoJy//q7DDY6JyV5VRVGpkakKt941P /IUw== X-Gm-Message-State: APjAAAVj7rvMDKIAyEq35hkpcGQLVZ9mWHbs9dLLqpQfAzG8sANj+qQr 8H6zg15t5ZnpJZfg4dMgzKuY/kWK X-Google-Smtp-Source: APXvYqw7lyzN601Q+C+GcqVJDkNNAIBoVstqCUhQ+UtPfCaeYM+14yekxyyZrla+1bhpjs1MPHA82Q== X-Received: by 2002:a6b:f114:: with SMTP id e20mr33226624iog.169.1561317503531; Sun, 23 Jun 2019 12:18:23 -0700 (PDT) Received: from raichu (toroon0560w-lp140-05-70-29-85-38.dsl.bell.ca. [70.29.85.38]) by smtp.gmail.com with ESMTPSA id n21sm7558203ioh.30.2019.06.23.12.18.22 (version=TLS1_3 cipher=AEAD-AES256-GCM-SHA384 bits=256/256); Sun, 23 Jun 2019 12:18:22 -0700 (PDT) Sender: Mark Johnston Date: Sun, 23 Jun 2019 15:18:18 -0400 From: Mark Johnston To: freebsd-hackers@freebsd.org Cc: re@freebsd.org Subject: release notes file Message-ID: <20190623191818.GA84365@raichu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.12.0 (2019-05-25) X-Rspamd-Queue-Id: BB8B16A058 X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=KFcno8OA; spf=pass (mx1.freebsd.org: domain of markjdb@gmail.com designates 2607:f8b0:4864:20::d2d as permitted sender) smtp.mailfrom=markjdb@gmail.com X-Spamd-Result: default: False [-5.67 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; MIME_TRACE(0.00)[0:+]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[freebsd.org]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; RCVD_COUNT_THREE(0.00)[3]; RCVD_TLS_LAST(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[d.2.d.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]; MX_GOOD(-0.01)[cached: alt3.gmail-smtp-in.l.google.com]; NEURAL_HAM_SHORT(-0.99)[-0.995,0]; IP_SCORE(-2.96)[ip: (-9.27), ipnet: 2607:f8b0::/32(-3.15), asn: 15169(-2.33), country: US(-0.06)]; FORGED_SENDER(0.30)[markj@freebsd.org,markjdb@gmail.com]; MID_RHS_NOT_FQDN(0.50)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[markj@freebsd.org,markjdb@gmail.com] 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: Sun, 23 Jun 2019 19:18:25 -0000 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? From owner-freebsd-hackers@freebsd.org Sun Jun 23 19:32:57 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 94F6815D8A53 for ; Sun, 23 Jun 2019 19:32:57 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qk1-x734.google.com (mail-qk1-x734.google.com [IPv6:2607:f8b0:4864:20::734]) (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 BC98B6C1D7 for ; Sun, 23 Jun 2019 19:32:56 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qk1-x734.google.com with SMTP id p144so8203728qke.11 for ; Sun, 23 Jun 2019 12:32:56 -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=p8lDehDUG24Knafc190r6zhBNYp8VHbGAaDU/d19fr8=; b=LNBisFzkXAyQH/1sjFN+pz48JbS9TRs7eDTuIlSDusRr5En0G4QWC22ITzhAmBlFza v6QGB+mHhwWivetLLQtcvX9BWsJxZqo+MKOvyOJgvnuazvQmgATu6C8CTIXl2Y3HAobt Ttu5a86xzASJpRlABBxk0USfSzC/KSuxHG7uYDWHW1EAZddaV13j8aLDA/5jDovMm5Wl wjzYqyQeo1psile5zMij5dYFEVWZ+AHLMguXD7VmClKHYQr+Dru3B+nPoBeV0XJLFEEo eMpBMEdB1GBZ6EN5GPNkVbXUId4S65xHjerrf+4D9OLSXfa9stS8F4fQeUHK2LHA2I1a T9FQ== 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=p8lDehDUG24Knafc190r6zhBNYp8VHbGAaDU/d19fr8=; b=M1pmxvAgUQaZLrnzR6QlUMQdEvMtzC5w2ed5uJOQHyVbIap6h44nS6Dx8BN7drd0o7 GcvACzt5NOcTVypNrmfTZGVad5zk516MUhg49LD35W9gCMv2D1IXMLyQPIGr2LlF9m5c bSu3qYBSO6i+98oK6gMPndJgdt3y5WsR2b0F78qZxy9hx+rmVCIdc0TguxczKXCGYUdw 1AtqaqjQSybJO/q2+alhp2XaOZHuZzs++sIKSwhBiG/uh/i+grBdkvPVEZ+9bVIJGfUq Ygoi00zcdG/gxFKKJc/YpH+7y2U2ev4kjal4+12goVXUHwAG44qXCPCzYgw93y7IyCCr zbzA== X-Gm-Message-State: APjAAAXQQwKeDr8CFB25QhlTLMcF8It+Balv66eff3IIcqb5A6IQ/9VZ rOx4Jsa8fnUSepE4xxz2ffMfbDx+fjQkCfdTdH+gEdeA448= X-Google-Smtp-Source: APXvYqyG0nhB7pJg6czQSNBHLHk5b8NKP17nPiSWvE1RcQJdyjWJX1iwXfzCo6nWO/D1xGUw6mBYOLpDMaz0SM75HBI= X-Received: by 2002:ae9:f107:: with SMTP id k7mr56386030qkg.215.1561318375726; Sun, 23 Jun 2019 12:32:55 -0700 (PDT) MIME-Version: 1.0 References: <20190623191818.GA84365@raichu> In-Reply-To: <20190623191818.GA84365@raichu> From: Warner Losh Date: Sun, 23 Jun 2019 13:32:44 -0600 Message-ID: Subject: Re: release notes file To: Mark Johnston Cc: "freebsd-hackers@freebsd.org" , FreeBSD Release Engineering Team X-Rspamd-Queue-Id: BC98B6C1D7 X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20150623.gappssmtp.com header.s=20150623 header.b=LNBisFzk X-Spamd-Result: default: False [-5.89 / 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)[]; RCPT_COUNT_THREE(0.00)[3]; 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]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20150623.gappssmtp.com:+]; MX_GOOD(-0.01)[cached: ALT1.aspmx.l.google.com]; RCVD_IN_DNSWL_NONE(0.00)[4.3.7.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.87)[-0.873,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.15), asn: 15169(-2.33), country: US(-0.06)]; RCVD_COUNT_TWO(0.00)[2] Content-Type: text/plain; charset="UTF-8" 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: Sun, 23 Jun 2019 19:32:57 -0000 I love it. I proposed something similar before, and it went nowhere. I often forget, or realize after the fact that something should be in the release notes. Warner On Sun, Jun 23, 2019 at 1:21 PM 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. > > 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@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > From owner-freebsd-hackers@freebsd.org Sun Jun 23 19:36:13 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 3BFF015D8C24 for ; Sun, 23 Jun 2019 19:36:13 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1a.eu.mailhop.org (outbound1a.eu.mailhop.org [52.58.109.202]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7BB9B6C38C for ; Sun, 23 Jun 2019 19:36:12 +0000 (UTC) (envelope-from ian@freebsd.org) ARC-Seal: i=1; a=rsa-sha256; t=1561318570; cv=none; d=outbound.mailhop.org; s=arc-outbound20181012; b=NuOUlAiG2WYAAESOnn20sY9rxbTA1Bd9DouXQBWFh+FpiFRwQ8nlVGelmV0IPNhMH8RyKkCUaG+Hf qFSJkxLNBL1w4RKUELbhlJYh7US/dXsMGFJIagbGF0sZXnsSkcWpxQ9pCJjlTUTQ4FGT3O/fBqPULC 5AuvuJbc52sKC+hiwdUBfAV5ty2s/KnjEVk4X11FrTiS0R6EwIeO4tdOP3A9vc+xhOcDX+wNv8dVol iKplPM3PdZx4JylpZl4mN3MpH/EwYyrWMfuIVZRkcA74FC/Kin7SFBqH2QcGhnBH3A9I38pGTW99bb n61JZMHJwgFM/4RFPcuPXqG3NOwWYLw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=arc-outbound20181012; h=content-transfer-encoding:mime-version:content-type:references:in-reply-to: date:cc:to:from:subject:message-id:dkim-signature:from; bh=0Ty5fhptkELO5USoeNa6bW4euz1ZjH3cVf8zb7OSXQ8=; b=viRMbC9PjGgG7vPXQdl4KT9pio+gHrPX7bJxqe1lwQxAlG3kvjAGBhVTqOD7mNkyczocVELKMleMv pa5felGlQiHL6nAFvKRwgWawsUWv8+lkqWCHqi1TjoXCylFrgSEMF+ulsINFvRSnrKoiNjqE2pU+JS SfuZYzJbznyFJwgRYtCAQmYB8aqMp1/T7o52vNJVWjmwCBU4e4BI2DdFifJTQTW6BXZWRIrEx5m9iz fjjMNr3rD338aEjErXkvn0g5J1egs8okTIRZrWh5wzbYHiP4xbbp939W7iOa/FFvIk18ZzGW73K5MJ PZiVi41uwNI9McOLUssnJagxwuY+89A== ARC-Authentication-Results: i=1; outbound2.eu.mailhop.org; spf=softfail smtp.mailfrom=freebsd.org smtp.remote-ip=67.177.211.60; dmarc=none header.from=freebsd.org; arc=none header.oldest-pass=0; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=dkim-high; h=content-transfer-encoding:mime-version:content-type:references:in-reply-to: date:cc:to:from:subject:message-id:from; bh=0Ty5fhptkELO5USoeNa6bW4euz1ZjH3cVf8zb7OSXQ8=; b=enK9wkxTyg4iuatjjMUJpfXsd/4fiMohGhLvzjNn9+BGvB7O6DZ4BpzhNCRYWfW8afc3RWPxjsiRc lIBweDKXvfKEUuBuInwlO6r1nYkgnhp+M353HUxHWfQupt95Mp6J/rt1c2FduEz6hOs5REJA1An/aw aPeVanB2YMZz/7ya+rX8ahb7UT3NLHmcffxpcKMPaJaPbEecBbiDUGNZeaiXF7XnNl7QIkNBr5JymP sz74iBDzpAy+FIPkOpBy42+IPseBiVDa3IBhcaKmj95no+BV2NKc1z47YWWPPiTgOA38O9eDssiPoH QZbVseKLcRnEODzA/DE9oWT2iG0Es5g== X-MHO-RoutePath: aGlwcGll X-MHO-User: 2454ec69-95ee-11e9-8b8b-5bd8169b0639 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 67.177.211.60 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [67.177.211.60]) by outbound2.eu.mailhop.org (Halon) with ESMTPSA id 2454ec69-95ee-11e9-8b8b-5bd8169b0639; Sun, 23 Jun 2019 19:36:07 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id x5NJa5bA039456; Sun, 23 Jun 2019 13:36:05 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <0175a71fb726c80b450497ecd6acc7ff5404276a.camel@freebsd.org> Subject: Re: release notes file From: Ian Lepore To: Mark Johnston , freebsd-hackers@freebsd.org Cc: re@freebsd.org Date: Sun, 23 Jun 2019 13:36:05 -0600 In-Reply-To: <20190623191818.GA84365@raichu> References: <20190623191818.GA84365@raichu> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.5 FreeBSD GNOME Team Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 7BB9B6C38C X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-2.99 / 15.00]; local_wl_from(0.00)[freebsd.org]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.99)[-0.988,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; ASN(0.00)[asn:16509, ipnet:52.58.0.0/15, country:US] 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: Sun, 23 Jun 2019 19:36:13 -0000 On Sun, 2019-06-23 at 15:18 -0400, 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. > > 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? > I think it's a very good idea. -- Ian From owner-freebsd-hackers@freebsd.org Sun Jun 23 19:49:55 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 5A1D315D90D0 for ; Sun, 23 Jun 2019 19:49:55 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from mail0.glenbarber.us (mail0.glenbarber.us [208.86.227.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail0.glenbarber.us", Issuer "Gandi Standard SSL CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BC5DB6CAC4; Sun, 23 Jun 2019 19:49:54 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from [192.168.1.17] (24.102.164.36.res-cmts.swb2.ptd.net [24.102.164.36]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: gjb) by mail0.glenbarber.us (Postfix) with ESMTPSA id 6E4CA1E1C3; Sun, 23 Jun 2019 19:49:45 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.10.3 mail0.glenbarber.us 6E4CA1E1C3 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) Subject: Re: release notes file From: Glen Barber X-Mailer: iPhone Mail (16F203) In-Reply-To: <20190623191818.GA84365@raichu> Date: Sun, 23 Jun 2019 15:49:44 -0400 Cc: freebsd-hackers@freebsd.org, re@freebsd.org Content-Transfer-Encoding: 7bit Message-Id: <6B485E5C-9C8A-43C8-BD5A-528A74A61A23@FreeBSD.org> References: <20190623191818.GA84365@raichu> To: Mark Johnston X-Rspamd-Queue-Id: BC5DB6CAC4 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-2.97 / 15.00]; local_wl_from(0.00)[FreeBSD.org]; NEURAL_HAM_MEDIUM(-1.00)[-0.998,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.97)[-0.973,0]; ASN(0.00)[asn:36236, ipnet:208.86.227.0/24, country:US] 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: Sun, 23 Jun 2019 19:49:55 -0000 Yes, please. Glen Sent from my phone. Please excuse my brevity and/or typos. > On Jun 23, 2019, at 3:18 PM, 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. > > 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? > From owner-freebsd-hackers@freebsd.org Sun Jun 23 19:52:33 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 244C115D92D6 for ; Sun, 23 Jun 2019 19:52:33 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from mail0.glenbarber.us (mail0.glenbarber.us [IPv6:2607:fc50:1:2300:1001:1001:1001:face]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail0.glenbarber.us", Issuer "Gandi Standard SSL CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 50DAC6CE6D; Sun, 23 Jun 2019 19:52:32 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from [192.168.1.17] (24.102.164.36.res-cmts.swb2.ptd.net [24.102.164.36]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: gjb) by mail0.glenbarber.us (Postfix) with ESMTPSA id 2CF321E1CD; Sun, 23 Jun 2019 19:52:31 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.10.3 mail0.glenbarber.us 2CF321E1CD Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) Subject: Re: release notes file From: Glen Barber X-Mailer: iPhone Mail (16F203) In-Reply-To: <6B485E5C-9C8A-43C8-BD5A-528A74A61A23@FreeBSD.org> Date: Sun, 23 Jun 2019 15:52:30 -0400 Cc: freebsd-hackers@freebsd.org, re@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <79B7AEEE-7617-44D8-A16A-C8EC5F95455A@FreeBSD.org> References: <20190623191818.GA84365@raichu> <6B485E5C-9C8A-43C8-BD5A-528A74A61A23@FreeBSD.org> To: Mark Johnston X-Rspamd-Queue-Id: 50DAC6CE6D X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-2.97 / 15.00]; local_wl_from(0.00)[FreeBSD.org]; NEURAL_HAM_MEDIUM(-1.00)[-0.998,0]; NEURAL_HAM_SHORT(-0.97)[-0.973,0]; ASN(0.00)[asn:36236, ipnet:2607:fc50::/36, country:US]; NEURAL_HAM_LONG(-1.00)[-1.000,0] 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: Sun, 23 Jun 2019 19:52:33 -0000 FWIW, I don=E2=80=99t think =E2=80=9Ceither/or=E2=80=9D is necessarily the b= est approach; meaning I would like to still keep the tag in the default temp= late. Glen (Who knows first hand how much it sucks going through commit logs for relnot= es entries) Sent from my phone. Please excuse my brevity and/or typos. > On Jun 23, 2019, at 3:49 PM, Glen Barber wrote: >=20 > Yes, please. >=20 > Glen > Sent from my phone. > Please excuse my brevity and/or typos. >=20 >> On Jun 23, 2019, at 3:18 PM, Mark Johnston wrote: >>=20 >> Hi, >>=20 >> 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. >>=20 >> For example: >>=20 >> Index: RELNOTES >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> --- 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. >>=20 >> What do folks think? >>=20 >=20 From owner-freebsd-hackers@freebsd.org Sun Jun 23 20:01:44 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 2069F15D9631 for ; Sun, 23 Jun 2019 20:01:44 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qk1-x734.google.com (mail-qk1-x734.google.com [IPv6:2607:f8b0:4864:20::734]) (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 6CD546D56A for ; Sun, 23 Jun 2019 20:01:43 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qk1-x734.google.com with SMTP id c11so8259883qkk.8 for ; Sun, 23 Jun 2019 13:01:43 -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=tGUWlbGnRQzV2uqgo21iDFxzV/lnAf0vMelhoEQQsAw=; b=Sg/FUpPLeFFF+cXXqrY409D1fcAFZo89BRqzoDhraKi6K7eIs7W9LruNKO6usq2L4K pNXjjJPDI+VxYJKjiioklteKi60Vbd+v3SUS44oCREkOPAV0+2KWoVNwZIjoltDA7wmJ uf2UGbAR7ImdKtR9ZCvmNvC/7px1Wq4fkpPQPWbUR5FaJyJGHVTnZHtAdmncF1AHQmNk QiFUfS8cVTVmoob3MhQsiMMsNYpWx31aXz9HoE51vYUA8sPtwpfUdKUGGs5YPEuFI1mB WvGnjXLZH93jcYEq62ISGTzXMSfiiTJJoEEgymM3//cAyXvMsWcwoX3gzMmPOjQOx8aM 9M+g== 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=tGUWlbGnRQzV2uqgo21iDFxzV/lnAf0vMelhoEQQsAw=; b=mth4k0L7WP4q+A7TaDaEywsX5vFj+qSWVqpxa3KZEnKZ7Pg0G2850rm+0PFp+5003i gzkDcC24CXVK5K1exd1NfpoyowJGMoZhE6DWpayN4J4AxlzJRIgvbC7mDRHshkde8Nqe zZYvq5bZBoDYDYKKKk4j1I5PaMdriAdrvoWlyg/GKTrb06UEuemg3jb7oImCjwNhzmJH pJf5Vni0m5M+wxAYZD/MyQMCzLWda2B1jpocZYUOVZzzGmb7qlImvdGaV0W6GauaJbrZ iNYYCsEjgjG1gdviM7JBKFCHR6U+3f4TsgjZ23VWSkr+U7R7CvBU200MCrWsME+ZS1Bo 2sYg== X-Gm-Message-State: APjAAAXzXnibaX9qihhjznfLq+jKQA8xiJowc/TJ4UmB3m5hNGrxRVnX vLk86Pp1cZZcLUa0hkk3XmRAWTk1sriK2r0RwQxZxA== X-Google-Smtp-Source: APXvYqyvkuNtvUunv0EL0CpWBFyt8SLzGOYU1wYoalC754F2pxBMZBp5GFGJ0uvinM/FjkodySICLvDvhd4otPaWT0E= X-Received: by 2002:a37:68ca:: with SMTP id d193mr108670126qkc.240.1561320102805; Sun, 23 Jun 2019 13:01:42 -0700 (PDT) MIME-Version: 1.0 References: <20190623191818.GA84365@raichu> <6B485E5C-9C8A-43C8-BD5A-528A74A61A23@FreeBSD.org> <79B7AEEE-7617-44D8-A16A-C8EC5F95455A@FreeBSD.org> In-Reply-To: <79B7AEEE-7617-44D8-A16A-C8EC5F95455A@FreeBSD.org> From: Warner Losh Date: Sun, 23 Jun 2019 14:01:31 -0600 Message-ID: Subject: Re: release notes file To: Glen Barber Cc: Mark Johnston , "freebsd-hackers@freebsd.org" , FreeBSD Release Engineering Team X-Rspamd-Queue-Id: 6CD546D56A X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20150623.gappssmtp.com header.s=20150623 header.b=Sg/FUpPL X-Spamd-Result: default: False [-5.98 / 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)[]; RCPT_COUNT_THREE(0.00)[4]; 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]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20150623.gappssmtp.com:+]; MX_GOOD(-0.01)[cached: ALT1.aspmx.l.google.com]; RCVD_IN_DNSWL_NONE(0.00)[4.3.7.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.97)[-0.972,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: Sun, 23 Jun 2019 20:01:44 -0000 On Sun, Jun 23, 2019 at 1:56 PM Glen Barber wrote: > FWIW, I don=E2=80=99t think =E2=80=9Ceither/or=E2=80=9D is necessarily th= e 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 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 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 writ= e > >> the text of a release note. I would like to propose adding a top-leve= l > >> 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 > >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >> --- 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@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org= " > From owner-freebsd-hackers@freebsd.org Sun Jun 23 20:19:46 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 A874515D9A03 for ; Sun, 23 Jun 2019 20:19:46 +0000 (UTC) (envelope-from gjb@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 455F76DFC8; Sun, 23 Jun 2019 20:19:46 +0000 (UTC) (envelope-from gjb@freebsd.org) Received: from FreeBSD.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by freefall.freebsd.org (Postfix) with ESMTPS id B4CAA1E067; Sun, 23 Jun 2019 20:19:45 +0000 (UTC) (envelope-from gjb@freebsd.org) Date: Sun, 23 Jun 2019 20:19:43 +0000 From: Glen Barber To: Warner Losh Cc: Mark Johnston , "freebsd-hackers@freebsd.org" , FreeBSD Release Engineering Team Subject: Re: release notes file Message-ID: <20190623201943.GB41944@FreeBSD.org> References: <20190623191818.GA84365@raichu> <6B485E5C-9C8A-43C8-BD5A-528A74A61A23@FreeBSD.org> <79B7AEEE-7617-44D8-A16A-C8EC5F95455A@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="bCsyhTFzCvuiizWE" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.11.2 (2019-01-07) X-Rspamd-Queue-Id: 455F76DFC8 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-2.96 / 15.00]; local_wl_from(0.00)[freebsd.org]; NEURAL_HAM_MEDIUM(-1.00)[-0.997,0]; NEURAL_HAM_SHORT(-0.97)[-0.967,0]; ASN(0.00)[asn:11403, ipnet:2610:1c1:1::/48, country:US]; NEURAL_HAM_LONG(-1.00)[-1.000,0] 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: Sun, 23 Jun 2019 20:19:46 -0000 --bCsyhTFzCvuiizWE Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jun 23, 2019 at 02:01:31PM -0600, Warner Losh wrote: > On Sun, Jun 23, 2019 at 1:56 PM Glen Barber wrote: >=20 > > FWIW, I don=E2=80=99t think =E2=80=9Ceither/or=E2=80=9D is necessarily = the best approach; meaning > > I would like to still keep the tag in the default template. > > >=20 > A while ago, I proposed a protocol that we'd only have the RELNOTES file. >=20 > 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. >=20 > 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. >=20 > Glen, do you think that's a workable protocol? >=20 It's kind of difficult for me to put the words together that effectively conveys what I'm thinking or where my mindset is here, but I'll try. I am in full support of a RELNOTES file, but I think that should be supplementary to the 'Relnotes: yes' (or other variations of a non-empty tag). I am conflicted on removing entries from a RELNOTES file once they are added to the release notes, because that might be a more convenient way for end users to get an idea of what changed. However, "Relnotes: yes" does not solve this for those folks. It is easy to truncate the file when a new branch is created, just as a workflow example, but I think the larger thing here is that while there are folks that commit something without "Relnotes: yes" because they forgot (or it did not occur to them at the time that it is a user-visible change), it can be equally difficult to remember to update a file specifically dedicated to this. All that said, having at least a sample text of what to include would be extremely helpful, at least for me, as sometimes I have to ping committers out-of-band to understand why a particular commit was flagged as "Relnotes: yes". Hopefully all that made sense. :) Glen --bCsyhTFzCvuiizWE Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEjRJAPC5sqwhs9k2jAxRYpUeP4pMFAl0P3t8ACgkQAxRYpUeP 4pOKOg/+InmQCz8IfEfPQx8OcAewG7OJq+3+6Hlfs6e0KIJstgqW0npq+G8XQJVT JnYaidIazq/mTGV10ipHQQ4V4w1dcNyqKaw9ovaHAmCXc7iWEqtHKoZlh9udwRKL sj2UV9cmyQ7kDscblloHSpyUVkciuJUM8QRaC0km53Ax2p1NQ4xXEVH2FHFAIYal L0P9sn+KUtQ/WejHd98cdo/3SIML353R2G690mFu7io/1Fk3Wm26myxU9f1iBVxx l+xQfsIoTHV9zT1ocbH9uqSIJfPyxTyF79wm4YYyuA9KhVH/2rzD3ZNIbYA96hvq 74yIhZY/xQCZUi4w3usVqNfAF0mmi0EzmMRtLeX4wEh2TpKcc9nt4lwV/zDAHFLj Lg52z5lp2JftyvvlgYsZkAnIfNeUTYr/aIhl8tbLn7W7EO1Oe27udUB5roXWq6Yp dr8icx9PsPtqYh64dW5NMMGImtdYwV6nTlCeRZIwOM/qi/ZF9qKcWcNoqG9raGHs vKHxrjnjrvYkaKYei9Vkkj5vJaZ/wMp8sX6IHXSNAdF6ML9N7yQGS5PDepoUSJQP 6sd3upyjcSWHJDPeWk9sqrk7SkpnKNKYvrCrYLw2Ck3YCgMj6RgxcOfQXO/4qITQ q7CN1Eh/zH2F6SgbXXaaGIanu/dweuAshNCrtF5hqaCC7iR+ozc= =I8/2 -----END PGP SIGNATURE----- --bCsyhTFzCvuiizWE-- From owner-freebsd-hackers@freebsd.org Sun Jun 23 21:10:05 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 D3EA715DB604 for ; Sun, 23 Jun 2019 21:10:04 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-io1-xd2f.google.com (mail-io1-xd2f.google.com [IPv6:2607:f8b0:4864:20::d2f]) (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 C97A670091; Sun, 23 Jun 2019 21:10:03 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mail-io1-xd2f.google.com with SMTP id m24so32823ioo.2; Sun, 23 Jun 2019 14:10:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=NbP/MyeLTeQVGx9cH3fcwmmf3Z1gwQjq0MASQUrhusc=; b=okPerVyIU+NI42vu9zcCLGR/yrtEBWRo4QkD2YzzjRw/zOmerDHVWP2vw96L2YnLbu V+fA4VMm2gJdzYy8QI7qwrdrV5esfEAsnK4K+MmU9x46BBqmb56NcFZVXLcF7ich/Dn7 oF2Sww2p6v/5/oW7EUADAnaPB6rRwDv1oWrthRcYBORwJU2WqY9cThiS+Unz0q/e9BXg h51YU/oZW5ccyXAEJECmcCxaQtLiwjf6lAhq+vCSsMVG9I73o9fp/8cdENP1bJdgA9ci +gJcswN1W2hjpXsiUzxJnlBlYl/o3CoZnwcWh0AAWIRSAY7iYhdCjdvpV9T14Eqy7iPk KQIg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition :content-transfer-encoding:in-reply-to:user-agent; bh=NbP/MyeLTeQVGx9cH3fcwmmf3Z1gwQjq0MASQUrhusc=; b=LD4B8hkVGy7ZZ5m/pgGVSrkHcNaNVGZamRNye/DMOFbbObDjz6nkFfM53Y9dv1MkLQ j668/479DQrulbC59zLYRhb3CikBRHePyyZcmsvJBkmyKbuogUn6PqHvyv/yb++UdZrO /FnI8EMk/3C06k4C580xt1peXjccCZD54A7nl7jRQzk9ldUNM/wEClUE3cTv992WEtde mpmODiNmLgfipA5pBXwgTfT2n2lvRXezdBjdoBBivYkY1E0YhrhB6sOxGFQ3C5eIqdt3 cm6Zqiaxu2kjtxS+/EdNLJUBOQgfsfId91bzfcn3PDBCG9TP/Mxaj2j+kynL8KQhPqaX 5KiA== X-Gm-Message-State: APjAAAURU7+cg3KcplaA7bwJgj6CzdOQjclYbKK9KuOe9P5v9P7KksDw kQwBTZHRnDbtdtInkSRAZhyWaAhp X-Google-Smtp-Source: APXvYqzp62cUGWd9r89zYbahDGPETo0NQc6rm2/0yT7fa6ymULEw5rMVvyuiPLaPowrw+NWp3fxSxA== X-Received: by 2002:a02:1948:: with SMTP id b69mr21448030jab.55.1561324202667; Sun, 23 Jun 2019 14:10:02 -0700 (PDT) Received: from raichu (toroon0560w-lp140-05-70-29-85-38.dsl.bell.ca. [70.29.85.38]) by smtp.gmail.com with ESMTPSA id u26sm11121526iol.1.2019.06.23.14.10.01 (version=TLS1_3 cipher=AEAD-AES256-GCM-SHA384 bits=256/256); Sun, 23 Jun 2019 14:10:01 -0700 (PDT) Sender: Mark Johnston Date: Sun, 23 Jun 2019 17:09:59 -0400 From: Mark Johnston To: Glen Barber Cc: Warner Losh , "freebsd-hackers@freebsd.org" , FreeBSD Release Engineering Team Subject: Re: release notes file Message-ID: <20190623210959.GB50070@raichu> References: <20190623191818.GA84365@raichu> <6B485E5C-9C8A-43C8-BD5A-528A74A61A23@FreeBSD.org> <79B7AEEE-7617-44D8-A16A-C8EC5F95455A@FreeBSD.org> <20190623201943.GB41944@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20190623201943.GB41944@FreeBSD.org> User-Agent: Mutt/1.12.0 (2019-05-25) X-Rspamd-Queue-Id: C97A670091 X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=okPerVyI; spf=pass (mx1.freebsd.org: domain of markjdb@gmail.com designates 2607:f8b0:4864:20::d2f as permitted sender) smtp.mailfrom=markjdb@gmail.com X-Spamd-Result: default: False [-5.38 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; MX_GOOD(-0.01)[cached: alt3.gmail-smtp-in.l.google.com]; NEURAL_HAM_SHORT(-0.82)[-0.818,0]; FORGED_SENDER(0.30)[markj@freebsd.org,markjdb@gmail.com]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[markj@freebsd.org,markjdb@gmail.com]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[f.2.d.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]; IP_SCORE(-2.86)[ip: (-8.76), ipnet: 2607:f8b0::/32(-3.14), asn: 15169(-2.33), country: US(-0.06)]; MID_RHS_NOT_FQDN(0.50)[] 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: Sun, 23 Jun 2019 21:10:05 -0000 On Sun, Jun 23, 2019 at 08:19:43PM +0000, Glen Barber wrote: > On Sun, Jun 23, 2019 at 02:01:31PM -0600, Warner Losh wrote: > > On Sun, Jun 23, 2019 at 1:56 PM Glen Barber 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? > > > > It's kind of difficult for me to put the words together that effectively > conveys what I'm thinking or where my mindset is here, but I'll try. > > I am in full support of a RELNOTES file, but I think that should be > supplementary to the 'Relnotes: yes' (or other variations of a non-empty > tag). > > I am conflicted on removing entries from a RELNOTES file once they are > added to the release notes, because that might be a more convenient way > for end users to get an idea of what changed. However, "Relnotes: yes" > does not solve this for those folks. > > It is easy to truncate the file when a new branch is created, just as > a workflow example, but I think the larger thing here is that while > there are folks that commit something without "Relnotes: yes" because > they forgot (or it did not occur to them at the time that it is > a user-visible change), it can be equally difficult to remember to > update a file specifically dedicated to this. > > All that said, having at least a sample text of what to include would be > extremely helpful, at least for me, as sometimes I have to ping > committers out-of-band to understand why a particular commit was flagged > as "Relnotes: yes". > > Hopefully all that made sense. :) It makes sense to me. I think the idea is that "Relnotes: yes" is advisory and serves as a reminder that the commit should get a release note; committers may forget or not want to write RELNOTES entries for some reason. Similar to how "MFC after" is advisory and doesn't guarantee that an MFC has been done after any particular point. re@ would need to scan commits for Relnotes tags that don't have entries in RELNOTES. Since RELNOTES can be updated after the fact, this set would hopefully be small. Regarding whether RELNOTES entries should be removed, I would prefer to keep them at least until head is branched. They would serve as useful documentation to users, and if there are multiple people compiling release notes they can synchronize in other ways. At least, I would wait for it to become a problem before trying to solve it by removing entries from RELNOTES. From owner-freebsd-hackers@freebsd.org Sun Jun 23 21:20:16 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 1A89715DBAFE for ; Sun, 23 Jun 2019 21:20:16 +0000 (UTC) (envelope-from oliver.pinter@hardenedbsd.org) Received: from mail-yb1-xb2d.google.com (mail-yb1-xb2d.google.com [IPv6:2607:f8b0:4864:20::b2d]) (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 AA49B70A90 for ; Sun, 23 Jun 2019 21:20:14 +0000 (UTC) (envelope-from oliver.pinter@hardenedbsd.org) Received: by mail-yb1-xb2d.google.com with SMTP id l10so1618172ybj.5 for ; Sun, 23 Jun 2019 14:20:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hardenedbsd.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=sBMDEqylY4yc4Nd9efTGmGbGbEWKRJ7lsB+bMkuuxYI=; b=LYPq8J61vNWEvhXxrGsR1HGMKfNjYNBn1Sk5tZikZGfKTUUK2YCQOZTgz3pgtVp8Rx CWbDK7+HqNwgTaH4MkkHFR8ohPvZnKdKNUG0uEIM/SSGKFgp0ishl8I7C+6X44cGGGdv rL9qL1WYl6X+/0jF0/WqbCHXrnW6QWDO6XayKRkZp/lwI4jxsRdTZPQ+GwOKzY4DTlwR A/MQtMSUsGUX/i5EueMDx1dkOFXGOdeA2J9mr5jpLrpBz8WHPeA4JCVyNVbkwvN5JO0j xPv+vKXAXDdMyaEn1q5MdWapIITHTC5PO3BieoXik8Dvr1sT0iTG9PnTMtqp+4iPO5UG n2vA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=sBMDEqylY4yc4Nd9efTGmGbGbEWKRJ7lsB+bMkuuxYI=; b=cAEGN0ck1tnUz0IqGsOrWdudSqGph8gykgIJ2hjKuj8+knxJukDCCk/roTY9PQZibe Y1HI2/zgUHrB8za2ipRdnyDgW9FgDEin6BKfAjjr2g45BqUt0QaBt+5S6X0cecL1DcDN 7xZzdebaEbxQDD5nuSwIZjW6qEQHa04spKsm9FsHqWIZDd8adxYu4N5xbSkJWGLh7PtG a71VMuXSdwDKJj9efg6VrwaHLE03Zz7HWehx8hALC3X/+i7ZDMEKJGuAoRZAYliooynE 8Kt9tN/Li8HhfDWDc72D6FjqM7E8Ag4jYpM6GSNWP8yuoqMb+2fJ0yMkYGbfHhuF19BB 63eQ== X-Gm-Message-State: APjAAAV0Wy9rcfkxY3IdIla7Exf/pbbKlkNoZtJ1GVVWBAIx6SUm4aYw rdTUAjvxL5T6O+EjKUrwfva8KtiPAIU3KX2I8hPyALZwRYk= X-Google-Smtp-Source: APXvYqw4a23JIiVy3J9O18OGuZmvHmdgGkqBrX6/EM1lIzUJtQFhotGAbrjcd5f/fEyGAUVb38nNkCxXxb9f3xO//H8= X-Received: by 2002:a25:8109:: with SMTP id o9mr69006737ybk.132.1561324813725; Sun, 23 Jun 2019 14:20:13 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a25:4a86:0:0:0:0:0 with HTTP; Sun, 23 Jun 2019 14:20:13 -0700 (PDT) In-Reply-To: <20190623191818.GA84365@raichu> References: <20190623191818.GA84365@raichu> From: Oliver Pinter Date: Sun, 23 Jun 2019 23:20:13 +0200 Message-ID: Subject: Re: release notes file To: Mark Johnston Cc: "freebsd-hackers@freebsd.org" , "re@freebsd.org" X-Rspamd-Queue-Id: AA49B70A90 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; dkim=pass header.d=hardenedbsd.org header.s=google header.b=LYPq8J61; spf=pass (mx1.freebsd.org: domain of oliver.pinter@hardenedbsd.org designates 2607:f8b0:4864:20::b2d as permitted sender) smtp.mailfrom=oliver.pinter@hardenedbsd.org X-Spamd-Result: default: False [-6.36 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; R_DKIM_ALLOW(-0.20)[hardenedbsd.org:s=google]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; 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)[hardenedbsd.org]; TO_DN_SOME(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[hardenedbsd.org:+]; MX_GOOD(-0.01)[alt1.aspmx.l.google.com,aspmx.l.google.com,aspmx2.googlemail.com,alt2.aspmx.l.google.com,aspmx3.googlemail.com]; RCVD_IN_DNSWL_NONE(0.00)[d.2.b.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.84)[-0.845,0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; IP_SCORE(-3.00)[ip: (-9.49), ipnet: 2607:f8b0::/32(-3.14), asn: 15169(-2.33), country: US(-0.06)] Content-Type: text/plain; charset="UTF-8" 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: Sun, 23 Jun 2019 21:20:16 -0000 On Sunday, June 23, 2019, 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. In the future with git you could easily add meta infos for specific commits. The project currently using this to store git-svn meta, but you can add more the one note to each commit. W > > 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@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > From owner-freebsd-hackers@freebsd.org Sun Jun 23 21:57:32 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 A46D615ADBB3 for ; Sun, 23 Jun 2019 21:57:32 +0000 (UTC) (envelope-from gjb@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [96.47.72.132]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 41DB471E9C; Sun, 23 Jun 2019 21:57:32 +0000 (UTC) (envelope-from gjb@freebsd.org) Received: from FreeBSD.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by freefall.freebsd.org (Postfix) with ESMTPS id CA8401F72C; Sun, 23 Jun 2019 21:57:31 +0000 (UTC) (envelope-from gjb@freebsd.org) Date: Sun, 23 Jun 2019 21:57:29 +0000 From: Glen Barber To: Mark Johnston Cc: Warner Losh , "freebsd-hackers@freebsd.org" , FreeBSD Release Engineering Team Subject: Re: release notes file Message-ID: <20190623215729.GD41944@FreeBSD.org> References: <20190623191818.GA84365@raichu> <6B485E5C-9C8A-43C8-BD5A-528A74A61A23@FreeBSD.org> <79B7AEEE-7617-44D8-A16A-C8EC5F95455A@FreeBSD.org> <20190623201943.GB41944@FreeBSD.org> <20190623210959.GB50070@raichu> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="ylS2wUBXLOxYXZFQ" Content-Disposition: inline In-Reply-To: <20190623210959.GB50070@raichu> User-Agent: Mutt/1.11.2 (2019-01-07) X-Rspamd-Queue-Id: 41DB471E9C X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-2.93 / 15.00]; local_wl_from(0.00)[freebsd.org]; NEURAL_HAM_MEDIUM(-1.00)[-0.997,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.94)[-0.936,0]; ASN(0.00)[asn:11403, ipnet:96.47.64.0/20, country:US] 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: Sun, 23 Jun 2019 21:57:32 -0000 --ylS2wUBXLOxYXZFQ Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jun 23, 2019 at 05:09:59PM -0400, Mark Johnston wrote: > On Sun, Jun 23, 2019 at 08:19:43PM +0000, Glen Barber wrote: > > On Sun, Jun 23, 2019 at 02:01:31PM -0600, Warner Losh wrote: > > > On Sun, Jun 23, 2019 at 1:56 PM Glen Barber wrote: > > >=20 > > > > FWIW, I don=E2=80=99t think =E2=80=9Ceither/or=E2=80=9D is necessar= ily the best approach; meaning > > > > I would like to still keep the tag in the default template. > > > > > > >=20 > > > A while ago, I proposed a protocol that we'd only have the RELNOTES f= ile. > > >=20 > > > 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 wor= king > > > on the release notes should we be so fortunate to have those resource= s in > > > the future. It's minorly racy, but not terrible. This way, release no= tes > > > text could also be written by the committer and tweaked by whomever > > > compiles the release notes. > > >=20 > > > However, I'm cool with having it in the commit message + template sin= ce > > > 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 w= ould > > > write the notes and if you wanted to have more control over what went= out, > > > you'd use RELNOTES. > > >=20 > > > Glen, do you think that's a workable protocol? > > >=20 > >=20 > > It's kind of difficult for me to put the words together that effectively > > conveys what I'm thinking or where my mindset is here, but I'll try. > >=20 > > I am in full support of a RELNOTES file, but I think that should be > > supplementary to the 'Relnotes: yes' (or other variations of a non-empty > > tag). > >=20 > > I am conflicted on removing entries from a RELNOTES file once they are > > added to the release notes, because that might be a more convenient way > > for end users to get an idea of what changed. However, "Relnotes: yes" > > does not solve this for those folks. > >=20 > > It is easy to truncate the file when a new branch is created, just as > > a workflow example, but I think the larger thing here is that while > > there are folks that commit something without "Relnotes: yes" because > > they forgot (or it did not occur to them at the time that it is > > a user-visible change), it can be equally difficult to remember to > > update a file specifically dedicated to this. > >=20 > > All that said, having at least a sample text of what to include would be > > extremely helpful, at least for me, as sometimes I have to ping > > committers out-of-band to understand why a particular commit was flagged > > as "Relnotes: yes". > >=20 > > Hopefully all that made sense. :) >=20 > It makes sense to me. I think the idea is that "Relnotes: yes" is > advisory and serves as a reminder that the commit should get a release > note; committers may forget or not want to write RELNOTES entries for > some reason. Similar to how "MFC after" is advisory and doesn't > guarantee that an MFC has been done after any particular point. re@ > would need to scan commits for Relnotes tags that don't have entries in > RELNOTES. Since RELNOTES can be updated after the fact, this set > would hopefully be small. >=20 > Regarding whether RELNOTES entries should be removed, I would prefer to > keep them at least until head is branched. They would serve as useful > documentation to users, and if there are multiple people compiling > release notes they can synchronize in other ways. At least, I would > wait for it to become a problem before trying to solve it by removing > entries from RELNOTES. >=20 To your latter point, removing the RELNOTES entries, this is what I sort of had in mind: head -> stable/X -> releng/X.Y: head/RELNOTES gets truncated after stable/X is created; stable/X gets truncated after releng/X.Y is created For point releases, the workflow is similar as it just excludes head: stable/X -> releng/X.Y: stable/X gets truncated after releng/X.Y is created In other words, there would be no arbitrarily-long file, but there would potentially be some overlap for a major release where a dot-zero release has last-minute new stuff that should be in release notes; it would grow and shrink as development happens. Or, this is how I see it being most beneficial to RE when it comes to writing release notes, at least. Glen --ylS2wUBXLOxYXZFQ Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEjRJAPC5sqwhs9k2jAxRYpUeP4pMFAl0P9ckACgkQAxRYpUeP 4pN8oBAAiS8EWVfuFory2Qs1CSNNh+K0rLHM+CVt+g9eUDMlcLtsc7jdqA/Fz17L tFbXQVOupTTFVqsalTl/Q/luHT/m6zxLTypcO6nhRbI2bN01Hokls+4RAp8TVSmJ wMSpgmASjnccNeHVFjjYir0XOkK1uykaBZnFCFKrcwpLYefOa3lh8XQXRi08Emvs ICmv3neYXjWAas0xJXBeXEbPgpWRsY6OHVDAcaESrL9z12HVUKgl4FEVTlHGH1qx 8TTJBDCILiGcDZNLd6FRewTngTFHekILphwh247957kgZzepfYbpA8C0DVHWGd1m 6PMmApHuPRfp4QuZo0Q7wyPBnscgRKXReTfmyY3M9ck13FbLsgnEL1MQgB7M7Qnu dUnZPLCAbSPrQoYT30cT/tvgplr0AuZEfVQWR/0fhrPu/SEwWZESkUus6thsO8Xj 2lDvvoicwAKG922m/YQ3BuqFzJRceKxR4Ngh22VAMcyVha3PK5YIo9VZS3lB265t Un5cHbg9zsOEsAftTWlkKyd++aTKTPKpbhgTIqnOKYZ+rqqIYF8+xBrhDYdeuiAR /4TulD5SZx4NrVnVJrAVHZ46B/KQIOQV/Wy0egyz1zpqI2qisG3Itrv390ZAcHe/ 5kgHHLTRN3vRPWq9qiW2/H9W3jhjw7ZV0QJ7bIIyX+O+Gz5Nz+Y= =QgHd -----END PGP SIGNATURE----- --ylS2wUBXLOxYXZFQ-- From owner-freebsd-hackers@freebsd.org Sun Jun 23 22:09:36 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 25DAF15B3085 for ; Sun, 23 Jun 2019 22:09:36 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-io1-xd2d.google.com (mail-io1-xd2d.google.com [IPv6:2607:f8b0:4864:20::d2d]) (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 2FA017235E; Sun, 23 Jun 2019 22:09:35 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mail-io1-xd2d.google.com with SMTP id r185so412588iod.6; Sun, 23 Jun 2019 15:09:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=rXRzJNTrCwZIGd6+vNSwYead9v9iPxABDxb/K+0ZOC4=; b=mJq5UKdDO2dCatqcjGQX810m9UzAGjqBGHASeZlVRasUNq/rrj5OIR1J6FvuG3dTX9 abICRtnr6asJcdwLxc4eYQzw0uPZ/ZbWCS2CVFNRvL6qKLzwDWlxZMh51fOODJ4EQZ3Q 1JOgVBLxYM92uXVI5qY0Wa2heNT3oSoZbOm8YUl+3iv5+mROoJACS1/EWIrYr/s/Ofhz VPuw8RplKvNeYLQFzRtBaBThtW5h9EG5jiH/SnQN+jZTP9nUY31aXKNarK9yMEai2HXd uT0ixcDmDrDFrfM68fJG05AvJtZPq91TV9ptYHv7X+Tp2t04CLC+KDjypFZkfgAYA50d YOSA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to:user-agent; bh=rXRzJNTrCwZIGd6+vNSwYead9v9iPxABDxb/K+0ZOC4=; b=pbpLyjM4X+7tiPMz7AP7q8GQBJq/+hAdszdJ/uJHMRY2RcRed0I/1a+ELJpoqqjM4z 2x5gBsxx5qI/Z/R8wCw8XdmNFyvzYkMXgn4TZ7VqvRQXhBJkhb/B2XSd/eMYy3ewqKm9 Jf3OCiAcI+hySBu0fRwRgiWs8Qr4JRZXfNvrzlEgzn8npPxlZb8oXaZirSE2wOgMtLWQ ZVPD/i5usspIUt56HTGXh2766g25dYumgsF8Jww8sSqRRbAVzYQVvHw6B4mzEIGfyY6T /Vq7F4u+eqnYbGsgUEKij7I5QiI+wgop6PuPi41BrX04mDhY8PiE2ZUyoJxFnnMxk0Y7 cQyQ== X-Gm-Message-State: APjAAAX2LKeKj1db4F9MWphi0pIo3jtNLrRTmnoORmlMbAqn3Ica+jIR xj+sfiwJV/4m7kLHjo2Z5RrqP2wZ X-Google-Smtp-Source: APXvYqz2+sDug1f6Hpb/tvjEW+wr+OMoyJTW9JMBMH9hXs7XQHwrx2BAI8n5Kp+87QBEeoerd+W3yA== X-Received: by 2002:a6b:b804:: with SMTP id i4mr9836870iof.119.1561327774169; Sun, 23 Jun 2019 15:09:34 -0700 (PDT) Received: from raichu (toroon0560w-lp140-05-70-29-85-38.dsl.bell.ca. [70.29.85.38]) by smtp.gmail.com with ESMTPSA id a2sm9046165iod.57.2019.06.23.15.09.33 (version=TLS1_3 cipher=AEAD-AES256-GCM-SHA384 bits=256/256); Sun, 23 Jun 2019 15:09:33 -0700 (PDT) Sender: Mark Johnston Date: Sun, 23 Jun 2019 18:09:31 -0400 From: Mark Johnston To: Glen Barber Cc: Warner Losh , "freebsd-hackers@freebsd.org" , FreeBSD Release Engineering Team Subject: Re: release notes file Message-ID: <20190623220931.GC50070@raichu> References: <20190623191818.GA84365@raichu> <6B485E5C-9C8A-43C8-BD5A-528A74A61A23@FreeBSD.org> <79B7AEEE-7617-44D8-A16A-C8EC5F95455A@FreeBSD.org> <20190623201943.GB41944@FreeBSD.org> <20190623210959.GB50070@raichu> <20190623215729.GD41944@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190623215729.GD41944@FreeBSD.org> User-Agent: Mutt/1.12.0 (2019-05-25) X-Rspamd-Queue-Id: 2FA017235E X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=mJq5UKdD; spf=pass (mx1.freebsd.org: domain of markjdb@gmail.com designates 2607:f8b0:4864:20::d2d as permitted sender) smtp.mailfrom=markjdb@gmail.com X-Spamd-Result: default: False [-5.63 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; MX_GOOD(-0.01)[cached: alt3.gmail-smtp-in.l.google.com]; NEURAL_HAM_SHORT(-0.97)[-0.967,0]; FORGED_SENDER(0.30)[markj@freebsd.org,markjdb@gmail.com]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[markj@freebsd.org,markjdb@gmail.com]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[d.2.d.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]; IP_SCORE(-2.95)[ip: (-9.24), ipnet: 2607:f8b0::/32(-3.14), asn: 15169(-2.33), country: US(-0.06)]; MID_RHS_NOT_FQDN(0.50)[] 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: Sun, 23 Jun 2019 22:09:36 -0000 On Sun, Jun 23, 2019 at 09:57:29PM +0000, Glen Barber wrote: > On Sun, Jun 23, 2019 at 05:09:59PM -0400, Mark Johnston wrote: > > Regarding whether RELNOTES entries should be removed, I would prefer to > > keep them at least until head is branched. They would serve as useful > > documentation to users, and if there are multiple people compiling > > release notes they can synchronize in other ways. At least, I would > > wait for it to become a problem before trying to solve it by removing > > entries from RELNOTES. > > > > To your latter point, removing the RELNOTES entries, this is what I sort > of had in mind: > > head -> stable/X -> releng/X.Y: > head/RELNOTES gets truncated after stable/X is created; > stable/X gets truncated after releng/X.Y is created > > For point releases, the workflow is similar as it just excludes head: > stable/X -> releng/X.Y: > stable/X gets truncated after releng/X.Y is created > > In other words, there would be no arbitrarily-long file, but there > would potentially be some overlap for a major release where a dot-zero > release has last-minute new stuff that should be in release notes; it > would grow and shrink as development happens. > > Or, this is how I see it being most beneficial to RE when it comes to > writing release notes, at least. This is what I had pictured as well. From owner-freebsd-hackers@freebsd.org Sun Jun 23 23:24:02 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 9A6A515B4DC2 for ; Sun, 23 Jun 2019 23:24:02 +0000 (UTC) (envelope-from bz@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1FAE774A06; Sun, 23 Jun 2019 23:24:02 +0000 (UTC) (envelope-from bz@FreeBSD.org) Received: from mx1.sbone.de (cross.sbone.de [195.201.62.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx1.sbone.de", Issuer "SBone.DE" (not verified)) (Authenticated sender: bz/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id D31D6A40; Sun, 23 Jun 2019 23:24:01 +0000 (UTC) (envelope-from bz@FreeBSD.org) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id CEF328D4A129; Sun, 23 Jun 2019 23:24:00 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id 54EA1E70847; Sun, 23 Jun 2019 23:24:00 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id G2f9O_h0s5j9; Sun, 23 Jun 2019 23:23:58 +0000 (UTC) Received: from [192.168.2.110] (unknown [IPv6:fde9:577b:c1a9:31:2ef0:eeff:fe03:ee34]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 82C04E707E6; Sun, 23 Jun 2019 23:23:58 +0000 (UTC) From: "Bjoern A. Zeeb" To: "Mark Johnston" Cc: freebsd-hackers@freebsd.org, re@freebsd.org Subject: Re: release notes file Date: Sun, 23 Jun 2019 23:23:57 +0000 X-Mailer: MailMate (2.0BETAr6137) Message-ID: <55030704-F521-4D6E-9B56-4B7F65EFFC38@FreeBSD.org> In-Reply-To: <20190623191818.GA84365@raichu> References: <20190623191818.GA84365@raichu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 1FAE774A06 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-2.97 / 15.00]; local_wl_from(0.00)[FreeBSD.org]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.97)[-0.970,0]; ASN(0.00)[asn:11403, ipnet:2610:1c1:1::/48, country:US] 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: Sun, 23 Jun 2019 23:24:02 -0000 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? 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 “What’s cooking for 13?” or similar could just vanish as we’d have these updated at least every 10 minutes automatically .. on our web server under /releases/ where they belong .. How amazing would that be? /bz From owner-freebsd-hackers@freebsd.org Sun Jun 23 23:48:49 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 69C4A15B54BB for ; Sun, 23 Jun 2019 23:48:49 +0000 (UTC) (envelope-from gjb@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [96.47.72.132]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id EA91E75296; Sun, 23 Jun 2019 23:48:48 +0000 (UTC) (envelope-from gjb@freebsd.org) Received: from FreeBSD.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by freefall.freebsd.org (Postfix) with ESMTPS id 6F4BD349; Sun, 23 Jun 2019 23:48:48 +0000 (UTC) (envelope-from gjb@freebsd.org) Date: Sun, 23 Jun 2019 23:48:45 +0000 From: Glen Barber To: "Bjoern A. Zeeb" Cc: Mark Johnston , freebsd-hackers@freebsd.org, re@freebsd.org Subject: Re: release notes file Message-ID: <20190623234845.GE41944@FreeBSD.org> References: <20190623191818.GA84365@raichu> <55030704-F521-4D6E-9B56-4B7F65EFFC38@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="BQPnanjtCNWHyqYD" Content-Disposition: inline In-Reply-To: <55030704-F521-4D6E-9B56-4B7F65EFFC38@FreeBSD.org> User-Agent: Mutt/1.11.2 (2019-01-07) X-Rspamd-Queue-Id: EA91E75296 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-2.96 / 15.00]; local_wl_from(0.00)[freebsd.org]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.96)[-0.957,0]; ASN(0.00)[asn:11403, ipnet:96.47.64.0/20, country:US] 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: Sun, 23 Jun 2019 23:48:49 -0000 --BQPnanjtCNWHyqYD Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jun 23, 2019 at 11:23:57PM +0000, Bjoern A. 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. > > 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. >=20 > 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? >=20 > 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 a= nd > naturally grow the document (feel free to use a different markup language > once doc is ready for that). >=20 > 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? >=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 autom= atically .. > on our web server under /releases/ where they belong .. >=20 > How amazing would that be? Very. But, I have one non-important nit -- the file in question does not need to be formatted for the documentation language of the day. 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.e., grammar nits, clarifications that stray from the original commit log (or commit log intent), etc. 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. Just my $0.02 USD. Glen --BQPnanjtCNWHyqYD Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEjRJAPC5sqwhs9k2jAxRYpUeP4pMFAl0QD9gACgkQAxRYpUeP 4pMT6w//dWiB1FCvsEoV1XBA+0PrI2othlPjNuff/k0hprJKNzY+anD9UW9UBckL YrdUzF5xk9u78cEpzVQp4bysZcVqIA+QR1GAXVVnOVNFuDvaKqQXNe3r72Px4qsH r0q+2WVeU0MuFWLMoDT8XzRaXC02ERMBcGceBC8DbtpIvHPFChkgp7NSMfVlj5dW 0OhGPBBfe+87SS6V3RH5eSeAvpF9xV8bQSBEDCe+dQqfGuYqug9hFBgHh35v9leR SkvyEIY32+ErePYjZeCSaGLI+G5gpBBsrAfFSDgGcwVLEX2IpVAcCkQhrIe31XLs lTSjJSoSjFY9KTv71bWRhaCf/fIybLkCpbwREKkHQRO/5kF2uetz/xKVk3zaIxG3 sAn+ZpmTid7uEpHs2Wo/Pz9KTZMu40uvX2WH00Kha4P/p0MhtJSs5Io2N+65+C7u Az8fpsUEiRMyRaDmpdsTl6CVTJC8IwVbG6yhVELgY72W1unFeMokjKCK3VeD5SaI RXUvA6ID8ogUXALz9qIeGAH88A0ZqE5DIbF71HFQ8GVo8PLnc7tl+GN28kNQu4zQ ZnAvb7+ZxbNTZtoMgsSx0xpLVEqk3U+4njb355XJCBDmNiCyFatBMC4MwToeYmzw UvLypU/lVrywvu2EctzzxB4sjDfcn4oRyGZZ3Ks4TsyfcifLUBI= =NhaN -----END PGP SIGNATURE----- --BQPnanjtCNWHyqYD-- From owner-freebsd-hackers@freebsd.org Mon Jun 24 00:36:25 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 49F0215B87EF for ; Mon, 24 Jun 2019 00:36:25 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-io1-xd32.google.com (mail-io1-xd32.google.com [IPv6:2607:f8b0:4864:20::d32]) (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 5851176624; Mon, 24 Jun 2019 00:36:24 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mail-io1-xd32.google.com with SMTP id r185so61663iod.6; Sun, 23 Jun 2019 17:36:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=OEXw2HROMAFEGIywKLpN5rtKpvBwp2QU1MJKol63ZqY=; b=ihgoELl8fRJWhPFGacZe46c9xpJwlmlAupMFrK/OxDzgZPDbkBwBAFLxI0lH8E74W1 lBaONJKQIEZsylr8aPv+2WjK1pT6qKK8aHx/U6nj4L1EeZZZpfSm2AY+jQB/8qwdiMqe jJFLrlvu8BWxyFHl8Oh3TSSbXeWl2q4ows0Pa4k6CCw3DbeE+ZNd13ZMw60qoav/62Oi 9vt0ZocbIJYFegXGwDVednhFhDTAaeiqZPUTIdjPVt0opODKu60Gv5U+ZqvhlLzQTbRI rUWlXpUPxLjy5qitdKF1h227AUaGmxoToCsUWbYRM+jEkqfs7KZWgdgBEz+C8nduMXWP QPxQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition :content-transfer-encoding:in-reply-to:user-agent; bh=OEXw2HROMAFEGIywKLpN5rtKpvBwp2QU1MJKol63ZqY=; b=lUqFd/2At7s0MwyW5d/XtVbWAwIYfNPSuBylpejTY+s/b+CHSr5n7mW48XgGW4OF3D cO74m7HVYZS1K6JEfbzrtF0x7ZINk9eq8CY15BqAn2TsZIk3cSI2r2jnweUzi3sWq+uu fLBEW/tuaMZM6QzXlWacv2AX0u3osOtHzdwBs8g8UPRcE3w8tJcbCyrp4ajZs3XHE/qF i1p3xxxjKS1KN3bQXy3g6jCoyb2Doc2Osl0kVSeyb0YUXoZjQXB9wFhqvj4GlUPfr5dQ fKAuXX/VfcBwqkaM6e9Hr2SS/OQ0Ki5dvTq5szr5PR2v9RTN8qvrdaBzDkZbInN5NwMh qMZA== X-Gm-Message-State: APjAAAUqbYvYELQjQaT2rXfX7gtyeaV+Ub1YV9NaZabiAi/VKDgre2/b ROU03WJotqZteJx1GvRkrIpNUJce X-Google-Smtp-Source: APXvYqwrUCYqbF8G1HNnC//aMwEGiSVHxbiug2c3yeBboNbznp/gCxEQx5YcuItZFtymGTGxp4JH1g== X-Received: by 2002:a5d:8253:: with SMTP id n19mr14105133ioo.80.1561336582890; Sun, 23 Jun 2019 17:36:22 -0700 (PDT) Received: from raichu (toroon0560w-lp140-05-70-29-85-38.dsl.bell.ca. [70.29.85.38]) by smtp.gmail.com with ESMTPSA id p10sm14846155iob.54.2019.06.23.17.36.20 (version=TLS1_3 cipher=AEAD-AES256-GCM-SHA384 bits=256/256); Sun, 23 Jun 2019 17:36:20 -0700 (PDT) Sender: Mark Johnston Date: Sun, 23 Jun 2019 20:36:16 -0400 From: Mark Johnston To: "Bjoern A. Zeeb" Cc: freebsd-hackers@freebsd.org, re@freebsd.org Subject: Re: release notes file Message-ID: <20190624003616.GA90409@raichu> References: <20190623191818.GA84365@raichu> <55030704-F521-4D6E-9B56-4B7F65EFFC38@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <55030704-F521-4D6E-9B56-4B7F65EFFC38@FreeBSD.org> User-Agent: Mutt/1.12.0 (2019-05-25) X-Rspamd-Queue-Id: 5851176624 X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=ihgoELl8; spf=pass (mx1.freebsd.org: domain of markjdb@gmail.com designates 2607:f8b0:4864:20::d32 as permitted sender) smtp.mailfrom=markjdb@gmail.com X-Spamd-Result: default: False [-5.40 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; MIME_TRACE(0.00)[0:+]; DMARC_NA(0.00)[freebsd.org]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; RCVD_COUNT_THREE(0.00)[3]; RCVD_TLS_LAST(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; MX_GOOD(-0.01)[cached: alt3.gmail-smtp-in.l.google.com]; RCVD_IN_DNSWL_NONE(0.00)[2.3.d.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.90)[-0.897,0]; IP_SCORE(-2.79)[ip: (-8.43), ipnet: 2607:f8b0::/32(-3.14), asn: 15169(-2.33), country: US(-0.06)]; FORGED_SENDER(0.30)[markj@freebsd.org,markjdb@gmail.com]; MID_RHS_NOT_FQDN(0.50)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[markj@freebsd.org,markjdb@gmail.com] 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 00:36:25 -0000 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 “What’s cooking for 13?” or similar could > just vanish as we’d have these updated at least every 10 minutes > 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. From owner-freebsd-hackers@freebsd.org Mon Jun 24 00:47:15 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 0BAC215B8C24 for ; Mon, 24 Jun 2019 00:47:15 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 28A4576ADD; Mon, 24 Jun 2019 00:47:13 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (localhost [127.0.0.1]) by gndrsh.dnsmgr.net (8.13.3/8.13.3) with ESMTP id x5O0l9HT041276; Sun, 23 Jun 2019 17:47:09 -0700 (PDT) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: (from freebsd-rwg@localhost) by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id x5O0l98i041275; Sun, 23 Jun 2019 17:47:09 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201906240047.x5O0l98i041275@gndrsh.dnsmgr.net> Subject: Re: release notes file In-Reply-To: <20190623234845.GE41944@FreeBSD.org> To: Glen Barber Date: Sun, 23 Jun 2019 17:47:09 -0700 (PDT) CC: "Bjoern A. Zeeb" , freebsd-hackers@freebsd.org, Mark Johnston , re@freebsd.org X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Rspamd-Queue-Id: 28A4576ADD X-Spamd-Bar: ++ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [2.84 / 15.00]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_SPAM_SHORT(0.69)[0.688,0]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[dnsmgr.net]; AUTH_NA(1.00)[]; RCPT_COUNT_FIVE(0.00)[5]; RCVD_COUNT_THREE(0.00)[3]; IP_SCORE(0.04)[ip: (0.14), ipnet: 69.59.192.0/19(0.07), asn: 13868(0.05), country: US(-0.06)]; MX_GOOD(-0.01)[cached: gndrsh.dnsmgr.net]; NEURAL_SPAM_LONG(0.93)[0.927,0]; NEURAL_SPAM_MEDIUM(0.30)[0.297,0]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:13868, ipnet:69.59.192.0/19, country:US]; MID_RHS_MATCH_FROM(0.00)[] 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 00:47:15 -0000 > 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? The file needs to live in src/ as this is to catch the missed Release Notes: Y thing and if you put it in doc repo src committers have hard access to even make a commit to it. Ideally some people well want to commit to src/RELNOTES at the same time as they make there commit to the tree, helping the release engineering team out a great deal. For those forgotten Release Notes: Yes items one simple does a top level sparse checkout of ^/head/base add an entry to RELNOTES stating what rXXXXXX it applies to and what was left out, can even be as simple as "Forgot Relnotes: Y". I was working on a proposal while part of RE to do much of this, that proposal was shelfed when I exited RE. > > 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 ?What?s cooking for 13?? or similar could just > > vanish as we?d have these updated at least every 10 minutes automatically .. > > on our web server under /releases/ where they belong .. > > > > How amazing would that be? > > Very. > > But, I have one non-important nit -- the file in question does not need > to be formatted for the documentation language of the day. 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.e., grammar nits, clarifications that > stray from the original commit log (or commit log intent), etc. That was also my feelings, the file should be extremly simple, and rough. It may have 2 or more parts. It should be possible to automatic collecting of Relnotes: foo entries from commits and making sure they all have entries in this file. The 2 part thing is I had a part that is kinda RE only, that is where RE tracks and builds the fuller text from the simple entries added by developers or the releasenotes tag. The simpler entries are marked off as "processed by RE (username@) on date" so that they could be worked on in parallel. I felt this could be expanded to people outside of RE once more experienced was gained and operational procedures established. Examples: r123342: Relnotes: Yes forgot to flag in original commit This is a committer cleaning up a forgotten flag r123344: Relnotes: Yes added by autobot1 on 2019/06/21 This is the type of thing a weekly cronjob, or even a postcommit hook script does. What it looks like after a RE/Doc person deals with it: r123344: Relnotes: Yes proccess by RE (gjb@) on 2019/06/22 ... PART 2 of file: r12344: This commit added the new feature reserve parachute to appliction pilot ejection. Please exercise care when using it as it is experimental and the riggers are still learning to pack properly. These would be visible to all committers so if someone makes a mistake discribing a change that is going into release notes feedback can be provided in very short order. > > 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. Yep > Just my $0.02 USD. > Glen Here, have some change.... $0.01 -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-hackers@freebsd.org Mon Jun 24 00:53:44 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 84B7815B8F3C for ; Mon, 24 Jun 2019 00:53:44 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 75B0F76F14; Mon, 24 Jun 2019 00:53:43 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (localhost [127.0.0.1]) by gndrsh.dnsmgr.net (8.13.3/8.13.3) with ESMTP id x5O0rewK041294; Sun, 23 Jun 2019 17:53:40 -0700 (PDT) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: (from freebsd-rwg@localhost) by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id x5O0rexU041293; Sun, 23 Jun 2019 17:53:40 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201906240053.x5O0rexU041293@gndrsh.dnsmgr.net> Subject: Re: release notes file In-Reply-To: <20190624003616.GA90409@raichu> To: Mark Johnston Date: Sun, 23 Jun 2019 17:53:40 -0700 (PDT) CC: "Bjoern A. Zeeb" , freebsd-hackers@freebsd.org, re@freebsd.org X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Rspamd-Queue-Id: 75B0F76F14 X-Spamd-Bar: ++ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [2.15 / 15.00]; TO_DN_SOME(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; MX_GOOD(-0.01)[cached: gndrsh.dnsmgr.net]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:13868, ipnet:69.59.192.0/19, country:US]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.09)[-0.085,0]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_SPAM_SHORT(0.57)[0.569,0]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[dnsmgr.net]; AUTH_NA(1.00)[]; IP_SCORE(0.04)[ip: (0.14), ipnet: 69.59.192.0/19(0.07), asn: 13868(0.05), country: US(-0.06)]; NEURAL_SPAM_LONG(0.74)[0.739,0]; R_SPF_NA(0.00)[] 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 00:53:44 -0000 > 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? I echo your concerns. > > 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 ?What?s cooking for 13?? or similar could > > just vanish as we?d have these updated at least every 10 minutes > > 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. Very much my position on the issue of a simple text file as src/RELNOTES, see other reply. > > 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. Even having you do the simple text in the RELNOTES file is 90% of the work, formatting, markdown, whatever, lets let the doc experts deal with that. This would be a case where we could consistantly delivery a fair bit of simple text for them to work on, and it would take work load off RE@. -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-hackers@freebsd.org Mon Jun 24 02:01:56 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 7D55315BB7EA for ; Mon, 24 Jun 2019 02:01:56 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qk1-x72b.google.com (mail-qk1-x72b.google.com [IPv6:2607:f8b0:4864:20::72b]) (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 5C01C80BAB for ; Mon, 24 Jun 2019 02:01:55 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qk1-x72b.google.com with SMTP id p144so8585373qke.11 for ; Sun, 23 Jun 2019 19:01:55 -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=5XidzjTT5U0GyQSzouIEEodEMvrYzYVEpPhdnrkLjvI=; b=s5go2J6ontxfWbgro41QcbxVFj6F5HAD7QJWaO7/IyhzU4b7Gl10Tz8LAj4mT5OuXK HVA5RpjCDcUX9YhjLsKGNihUnFVLx8EYHYRW3eDZJmXwgHoRIdC4utBkRB/ViQw04vLW sGJ6MHtRq5pBCkR4digrCOwW+F2VtIQiwohwC0mPaiTb3DLZzOJZ02PA0ThbPtW104Zu rkDvPLMKOOIxx4HvmrimiDTxvHW4//jLSjxjfAYj/RSoNkEL3bzCHlrHNJaDOJwMmik2 WIJxLuKgIZRJOR/Iu7Etn5G178bXGIXX1g/OUSmkKh1sayFau6JoDfmL6wgexhEZ8FZL c/jw== 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=5XidzjTT5U0GyQSzouIEEodEMvrYzYVEpPhdnrkLjvI=; b=ILB46bXjPVxkt0RF2Tlhe9pxF8kh5R3mgugxRs8w00HRmIllWblmrxuldWX+7vp+cd TUwztI8gdv16FxZ/cfDilbdynMF2OwB0kuHh5KQ9kkyOREmeyAxANy2C0h4vbYfSRSuP S/YNfyQoiQtjN0FyjR/Kly6kVcNKvYcknZSUvCBRI2y/PR5RFw49FjFXz7aniOjjsil+ W1tvDa3+5WjC3v+ci1HC3j+eWK+Y3fTIStNoIVsWI8kFreev5rrb5DgQzQbAYayPdqsN QLQqEucMfBLMVAS1YPQsLHJxT6YrsFyEkORCHWdlCbaGFEEsKufJ69VugYv8KV2+U3as L4YQ== X-Gm-Message-State: APjAAAUnWtypKAAENlVzTYPxpmXVMe7vI/5alCvWRkBps4FB0EUGzAnr 9PkEBZFnA0wZVa/ZKLeLllCyAwTWzQRNVoo8YdSMJA== X-Google-Smtp-Source: APXvYqykY+82NSXYh5ovy9biTQu+p8oM3tmmxObNhKZTni65x9B74TAuNGzO8LJ2zHolFGUwOeEvLPwXUzjjktxVAfk= X-Received: by 2002:a37:9307:: with SMTP id v7mr15107828qkd.495.1561341714326; Sun, 23 Jun 2019 19:01:54 -0700 (PDT) MIME-Version: 1.0 References: <20190624003616.GA90409@raichu> <201906240053.x5O0rexU041293@gndrsh.dnsmgr.net> In-Reply-To: <201906240053.x5O0rexU041293@gndrsh.dnsmgr.net> From: Warner Losh Date: Sun, 23 Jun 2019 20:01:43 -0600 Message-ID: Subject: Re: release notes file To: "Rodney W. Grimes" Cc: Mark Johnston , "freebsd-hackers@freebsd.org" , "Bjoern A. Zeeb" , FreeBSD Release Engineering Team X-Rspamd-Queue-Id: 5C01C80BAB X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20150623.gappssmtp.com header.s=20150623 header.b=s5go2J6o X-Spamd-Result: default: False [-5.01 / 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)[3]; 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)[b.2.7.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.99)[-0.994,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.01)[ip: (-9.51), 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" 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 02:01:56 -0000 > > > 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. > > Even having you do the simple text in the RELNOTES file is 90% of the > work, formatting, markdown, whatever, lets let the doc experts deal > with that. This would be a case where we could consistantly delivery > a fair bit of simple text for them to work on, and it would take work > load off RE@. > I'm starting to think that maybe we have one RELNOTES per repo at the top. It should be the running list of everything, in markdown format in a stylized format so we can parse it mechanically. No special permissions needed, no funky language to learn, no tools to install. We can merge it with a script. We can make sure that all the relnotes: yes entries in the repo have an entry in RELNOTES via a script (or we could just add the commit message as a boiler plate via a script automatically via a cron job that runs daily / weekly). Then it's all there, and we don't have to keep book in multiple files / formats / etc. Developers can get an entry in there with a single line, or they can write their own custom entry if the commit message isn't right. Tech writers could also word-smith things as we go when they have time so it's not a huge burden at the end. And people can look along with svnweb / github (if it's markdown, it will look pretty automatically on github). And it fits in with the efforts to modernize doc process since it gets everybody thinking about and contributing content. Then at release time we parse the markdown file from the 3 repos and convert it to whatever format doc is using and we're done. But regardless of the outcome, having it documented in the developer's handbook would be best. Warner From owner-freebsd-hackers@freebsd.org Mon Jun 24 05:05:55 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 F1DC815C246C for ; Mon, 24 Jun 2019 05:05:54 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 26CA085CB4; Mon, 24 Jun 2019 05:05:51 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (localhost [127.0.0.1]) by gndrsh.dnsmgr.net (8.13.3/8.13.3) with ESMTP id x5O55jqs042162; Sun, 23 Jun 2019 22:05:45 -0700 (PDT) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: (from freebsd-rwg@localhost) by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id x5O55j42042161; Sun, 23 Jun 2019 22:05:45 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201906240505.x5O55j42042161@gndrsh.dnsmgr.net> Subject: Re: release notes file In-Reply-To: To: Warner Losh Date: Sun, 23 Jun 2019 22:05:45 -0700 (PDT) CC: "Rodney W. Grimes" , "freebsd-hackers@freebsd.org" , "Bjoern A. Zeeb" , Mark Johnston , FreeBSD Release Engineering Team X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Rspamd-Queue-Id: 26CA085CB4 X-Spamd-Bar: ++ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [2.19 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-0.18)[-0.179,0]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_SPAM_SHORT(0.72)[0.718,0]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[dnsmgr.net]; AUTH_NA(1.00)[]; RCPT_COUNT_FIVE(0.00)[6]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MX_GOOD(-0.01)[cached: gndrsh.dnsmgr.net]; NEURAL_SPAM_LONG(0.73)[0.726,0]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:13868, ipnet:69.59.192.0/19, country:US]; MID_RHS_MATCH_FROM(0.00)[]; IP_SCORE(0.04)[ip: (0.14), ipnet: 69.59.192.0/19(0.07), asn: 13868(0.05), country: US(-0.06)] 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 05:05:55 -0000 > > > > > 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. > > > > Even having you do the simple text in the RELNOTES file is 90% of the > > work, formatting, markdown, whatever, lets let the doc experts deal > > with that. This would be a case where we could consistantly delivery > > a fair bit of simple text for them to work on, and it would take work > > load off RE@. > > > > I'm starting to think that maybe we have one RELNOTES per repo at the top. I was only thinking for /usr/src, aka ^/head/base/ to start with, as I do not know that we generate release notes stuff like this covering the ports or doc tree, though I certainly agree that the future could expand to those areas. > It should be the running list of everything, in markdown format in a > stylized format so we can parse it mechanically. No special permissions > needed, no funky language to learn, no tools to install. Strike markdown, as Both Glen and myself have expressed pure ascii text just like UPDATING is the path of least resistance. I might be convinced of a very very lightweight xml like thing for parsing purposes, ie the rXXXXXX needs to be locatable. > We can merge it with a script. We can make sure that all the relnotes: yes > entries in the repo have an entry in RELNOTES via a script (or we could > just add the commit message as a boiler plate via a script automatically > via a cron job that runs daily / weekly). Yes, but this needs some more though, even just the one liner I sighted in an earlier reply is fine for an RE@ working on the notes, but perhaps having the whole commit message added by the automation might lead to a shorter cycle time in processing them. > > Then it's all there, and we don't have to keep book in multiple files / > formats / etc. Developers can get an entry in there with a single line, or > they can write their own custom entry if the commit message isn't right. > > Tech writers could also word-smith things as we go when they have time so > it's not a huge burden at the end. And people can look along with svnweb / > github (if it's markdown, it will look pretty automatically on github). > > And it fits in with the efforts to modernize doc process since it gets > everybody thinking about and contributing content. > > Then at release time we parse the markdown file from the 3 repos and > convert it to whatever format doc is using and we're done. > > But regardless of the outcome, having it documented in the developer's > handbook would be best. Other than I do not know of any release notes: yes type things that come from doc/ or ports/ this is all in line with what I had modeled in my mind and was evolving as I had discussions with Glen about it. Oh, and pure simple text files, though as I stated earlier, very light xmlish tagging might be ok. Initially I just wanted a way to record the missed Relnotes: Y entires, as that in itself is a huge step forward in creating more complete release notes. The collection of all the properly done commits is trivial, merging those 2 list is also trivial. The conversion of a commit message to a release notes message is not so trivial, but also not massivly complex, but is a single threaded (one person usually does all that work, Glen or the lead RE for that release.) Having this work shareable would be a huge win. And like UPDATING a minimal set of self documentation in the top of the file would probably go further than anything off in the developers handbook. Oh, and it is also possible to use this to do a: r456789: Relnotes: NO, commit message is incorrect r456789 was reverted in r456987 to record the fact that there is no need to mention that specific commit in the release notes, it was erroniously marked, or become irrelevant for some reason, aka revert, etc... > Warner -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-hackers@freebsd.org Mon Jun 24 13:47:48 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 DFE2715CDBE8 for ; Mon, 24 Jun 2019 13:47:47 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from smtp-out-no.shaw.ca (smtp-out-no.shaw.ca [64.59.134.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 90A9E6EB60; Mon, 24 Jun 2019 13:47:46 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from spqr.komquats.com ([70.67.125.17]) by shaw.ca with ESMTPA id fPJnhK2kUldkPfPJphdveq; Mon, 24 Jun 2019 07:47:38 -0600 X-Authority-Analysis: v=2.3 cv=Ko4zJleN c=1 sm=1 tr=0 a=VFtTW3WuZNDh6VkGe7fA3g==:117 a=VFtTW3WuZNDh6VkGe7fA3g==:17 a=jpOVt7BSZ2e4Z31A5e1TngXxSK0=:19 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=dq6fvYVFJ5YA:10 a=ypVJL4-jAAAA:8 a=6I5d2MoRAAAA:8 a=YxBL1-UpAAAA:8 a=9npE18AETBUPgtKCxG0A:9 a=QEXdDO2ut3YA:10 a=khIbc0fXALFIcTpOSxgJ:22 a=IjZwj45LgO3ly-622nXo:22 a=Ia-lj3WSrqcvXOmTRaiG:22 Received: from [IPv6:2605:8d80:404:19e0:896e:40fe:905f:4d17] (unknown [72.143.239.75]) by spqr.komquats.com (Postfix) with ESMTPSA id B15A096F; Mon, 24 Jun 2019 06:47:34 -0700 (PDT) Date: Mon, 24 Jun 2019 06:47:08 -0700 User-Agent: K-9 Mail for Android In-Reply-To: References: <20190623191818.GA84365@raichu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: release notes file To: freebsd-hackers@freebsd.org, Oliver Pinter , Mark Johnston CC: "freebsd-hackers@freebsd.org" , "re@freebsd.org" From: Cy Schubert Message-ID: X-CMAE-Envelope: MS4wfGQSH61+4CFCmsK99bQRax5ZBJJAUEtgPVo+5hgxXeNCVdZ+xg4V73z+nEACeSCvoSVzTS63lTc+uR0eM9QpD6dOqdVn/jEm0Ze6FfOioFkNCqkN/XXw QxdvtDRP1s3BpRDy/TxfqsXsoX2QeAScIQ3iWzdYVnmERDOcDEx/B8k8W8Amcsy4rwNWigskFHUy3a/8BPoL3e6ad2bNv1HX2PasUyu43NYadOk6z1t+jnlq AXkgEvhkxpeXB0RKr/uLw74hcOqL2pUTiFcoYlpQVYbEVvE36UfhJ98cG3mJfASh X-Rspamd-Queue-Id: 90A9E6EB60 X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-5.70 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; RCPT_COUNT_FIVE(0.00)[5]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MX_GOOD(-0.01)[cached: spqr.komquats.com]; NEURAL_HAM_SHORT(-0.95)[-0.949,0]; R_SPF_NA(0.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[12.134.59.64.list.dnswl.org : 127.0.5.1]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:6327, ipnet:64.59.128.0/20, country:CA]; MID_RHS_MATCH_FROM(0.00)[]; IP_SCORE(-2.54)[ip: (-6.83), ipnet: 64.59.128.0/20(-3.26), asn: 6327(-2.53), country: CA(-0.09)]; RECEIVED_SPAMHAUS_PBL(0.00)[17.125.67.70.zen.spamhaus.org : 127.0.0.11] 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 13:47:48 -0000 On June 23, 2019 2:20:13 PM PDT, Oliver Pinter wrote: >On Sunday, June 23, 2019, Mark Johnston wrote: > >> Hi, >> >> 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 > > > >In the future with git you could easily add meta infos for specific >commits=2E The project currently using this to store git-svn meta, but >you >can add more the one note to each commit=2E >W > > > > >> >> For example: >> >> Index: RELNOTES >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> --- RELNOTES (nonexistent) >> +++ RELNOTES (working copy) >> @@ -0,0 +1,8 @@ >> +Release notes for FreeBSD 13=2E0=2E >> + >> +r349286: >> + swapon(8) can now erase a swap device immediately before >> + enabling it, similar to newfs(8)'s -E option=2E 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=2E >> >> What do folks think? >> _______________________________________________ >> freebsd-hackers@freebsd=2Eorg mailing list >> https://lists=2Efreebsd=2Eorg/mailman/listinfo/freebsd-hackers >> To unsubscribe, send any mail to >"freebsd-hackers-unsubscribe@freebsd=2Eorg" >> >_______________________________________________ >freebsd-hackers@freebsd=2Eorg mailing list >https://lists=2Efreebsd=2Eorg/mailman/listinfo/freebsd-hackers >To unsubscribe, send any mail to >"freebsd-hackers-unsubscribe@freebsd=2Eorg" It should be a =2Emd file to format it properly on github=2E The more I th= ink of it, a Makefile target to install it to / instead of /etc is more int= uitive=2E=20 --=20 Pardon the typos and autocorrect, small keyboard in use=2E Cheers, Cy Schubert FreeBSD UNIX: Web: http://www=2EFreeBSD=2Eorg The need of the many outweighs the greed of the few=2E From owner-freebsd-hackers@freebsd.org Mon Jun 24 13:48:00 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 0992815CDBFE for ; Mon, 24 Jun 2019 13:48:00 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from smtp-out-no.shaw.ca (smtp-out-no.shaw.ca [64.59.134.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 1C4826EB7B; Mon, 24 Jun 2019 13:47:59 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from spqr.komquats.com ([70.67.125.17]) by shaw.ca with ESMTPA id fPK9hK2sildkPfPKAhdvhq; Mon, 24 Jun 2019 07:47:58 -0600 X-Authority-Analysis: v=2.3 cv=Ko4zJleN c=1 sm=1 tr=0 a=VFtTW3WuZNDh6VkGe7fA3g==:117 a=VFtTW3WuZNDh6VkGe7fA3g==:17 a=jpOVt7BSZ2e4Z31A5e1TngXxSK0=:19 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=dq6fvYVFJ5YA:10 a=6I5d2MoRAAAA:8 a=YxBL1-UpAAAA:8 a=lTTchZjeOa9R918DG7oA:9 a=QEXdDO2ut3YA:10 a=IjZwj45LgO3ly-622nXo:22 a=Ia-lj3WSrqcvXOmTRaiG:22 Received: from [IPv6:2605:8d80:404:19e0:896e:40fe:905f:4d17] (unknown [72.143.239.75]) by spqr.komquats.com (Postfix) with ESMTPSA id 02CEB974; Mon, 24 Jun 2019 06:47:56 -0700 (PDT) Date: Mon, 24 Jun 2019 06:41:45 -0700 User-Agent: K-9 Mail for Android In-Reply-To: <20190623191818.GA84365@raichu> References: <20190623191818.GA84365@raichu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: release notes file To: freebsd-hackers@freebsd.org,Mark Johnston CC: re@freebsd.org From: Cy Schubert Message-ID: <56C57458-6274-47C6-A41D-0A6831A3F15E@cschubert.com> X-CMAE-Envelope: MS4wfF+8k4NEvAg2P+jRVjHQMo2tkfgJWUFtKfpVeLHMTdJEiwNS0ZVHfMglJPIRx8TqbYI+YAN5ZyCeldUjKLpJTOmvTi7xnyN5sQMEhc0zjc+GaNschLPe 6EUtwhggbC+GXUPIlzkCf9aTN3oC9QcZZHUjS6kTDoL0rFcPc3pBJnwaG2TN78+dqkYrMQVqWc7csr9NfNb7cGRMl7u4ktJ7U7OEMv8KMLD6OTFRL7JgJ0EA U8YlyKUn4tRYjv1VJUJGvw== X-Rspamd-Queue-Id: 1C4826EB7B X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-5.71 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[17.125.67.70.zen.spamhaus.org : 127.0.0.11]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; TO_DN_SOME(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; IP_SCORE(-2.55)[ip: (-6.85), ipnet: 64.59.128.0/20(-3.27), asn: 6327(-2.53), country: CA(-0.09)]; MX_GOOD(-0.01)[cached: spqr.komquats.com]; NEURAL_HAM_SHORT(-0.95)[-0.953,0]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:6327, ipnet:64.59.128.0/20, country:CA]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[12.134.59.64.list.dnswl.org : 127.0.5.1] 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 13:48:00 -0000 On June 23, 2019 12:18:18 PM PDT, Mark Johnston wrote= : >Hi, > >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 > >For example: > >Index: RELNOTES >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >--- RELNOTES (nonexistent) >+++ RELNOTES (working copy) >@@ -0,0 +1,8 @@ >+Release notes for FreeBSD 13=2E0=2E >+ >+r349286: >+ swapon(8) can now erase a swap device immediately before >+ enabling it, similar to newfs(8)'s -E option=2E 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=2E > >What do folks think? >_______________________________________________ >freebsd-hackers@freebsd=2Eorg mailing list >https://lists=2Efreebsd=2Eorg/mailman/listinfo/freebsd-hackers >To unsubscribe, send any mail to >"freebsd-hackers-unsubscribe@freebsd=2Eorg" There should also be a Makefile target to install it into /etc for people = who do not install sources=2E --=20 Pardon the typos and autocorrect, small keyboard in use=2E Cheers, Cy Schubert FreeBSD UNIX: Web: http://www=2EFreeBSD=2Eorg The need of the many outweighs the greed of the few=2E From owner-freebsd-hackers@freebsd.org Mon Jun 24 13:50:56 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 54F5215CDF09 for ; Mon, 24 Jun 2019 13:50:56 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from smtp-out-no.shaw.ca (smtp-out-no.shaw.ca [64.59.134.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 590C16EEB1; Mon, 24 Jun 2019 13:50:55 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from spqr.komquats.com ([70.67.125.17]) by shaw.ca with ESMTPA id fPMyhK3wDldkPfPMzhdw0k; Mon, 24 Jun 2019 07:50:54 -0600 X-Authority-Analysis: v=2.3 cv=Ko4zJleN c=1 sm=1 tr=0 a=VFtTW3WuZNDh6VkGe7fA3g==:117 a=VFtTW3WuZNDh6VkGe7fA3g==:17 a=jpOVt7BSZ2e4Z31A5e1TngXxSK0=:19 a=IkcTkHD0fZMA:10 a=dq6fvYVFJ5YA:10 a=6I5d2MoRAAAA:8 a=YxBL1-UpAAAA:8 a=og3l_TXpHuICnghziWYA:9 a=u1WIcz-ICccVuO1L:21 a=CdI4npqxOCyQYX9Q:21 a=QEXdDO2ut3YA:10 a=IjZwj45LgO3ly-622nXo:22 a=Ia-lj3WSrqcvXOmTRaiG:22 Received: from [10.225.247.173] (unknown [24.244.23.146]) by spqr.komquats.com (Postfix) with ESMTPSA id 43810987; Mon, 24 Jun 2019 06:50:52 -0700 (PDT) Date: Mon, 24 Jun 2019 06:50:26 -0700 User-Agent: K-9 Mail for Android In-Reply-To: <20190623234845.GE41944@FreeBSD.org> References: <20190623191818.GA84365@raichu> <55030704-F521-4D6E-9B56-4B7F65EFFC38@FreeBSD.org> <20190623234845.GE41944@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: release notes file To: freebsd-hackers@freebsd.org, Glen Barber , "Bjoern A. Zeeb" CC: Mark Johnston ,re@freebsd.org From: Cy Schubert Message-ID: <7802C1A1-8E79-40F1-9253-CA0E632EAD2B@cschubert.com> X-CMAE-Envelope: MS4wfNYfpfsC3PJWFlQFB4ijoumso+qnUfHFc3T+UezK56NPeyVF70lUDLvJ09sDU/WMffy7oKHn89grmQVG+XU5SklKQtVEGhgzJlPCZ+sNgo7w67Rb7K3P gdmlgxxEpMtJC1W/3g1/z3M1+q7G3tfxHGXPKgZP03aOg9udk91twmwNK6YBnaC8fq/v/nA6KkQ9SWzsi11a1Yg8NEWhrYUcUh8ybvKbZXd7h2MHxn2Z9kmB hPT2S2vRwQpshmmWrkXABPMfcp2+Xr59HCmWL3pvmF5XGkt7oLu5N8/yFpH+Eoh6 X-Rspamd-Queue-Id: 590C16EEB1 X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-5.73 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[17.125.67.70.zen.spamhaus.org : 127.0.0.11]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; RCPT_COUNT_FIVE(0.00)[5]; RCVD_COUNT_THREE(0.00)[3]; IP_SCORE(-2.55)[ip: (-6.87), ipnet: 64.59.128.0/20(-3.27), asn: 6327(-2.53), country: CA(-0.09)]; MX_GOOD(-0.01)[cached: spqr.komquats.com]; NEURAL_HAM_SHORT(-0.96)[-0.964,0]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:6327, ipnet:64.59.128.0/20, country:CA]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[12.134.59.64.list.dnswl.org : 127.0.5.1] 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 13:50:56 -0000 On June 23, 2019 4:48:45 PM PDT, Glen Barber 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 FreeBSD UNIX: Web: http://www=2EFreeBSD=2Eorg The need of the many outweighs the greed of the few=2E From owner-freebsd-hackers@freebsd.org Mon Jun 24 13:57:39 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 3D6CF15CE206 for ; Mon, 24 Jun 2019 13:57:39 +0000 (UTC) (envelope-from bapt@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D87736F496; Mon, 24 Jun 2019 13:57:38 +0000 (UTC) (envelope-from bapt@FreeBSD.org) Received: from ivaldir.etoilebsd.net (etoilebsd.net [178.32.217.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: bapt) by smtp.freebsd.org (Postfix) with ESMTPSA id 924F672EA; Mon, 24 Jun 2019 13:57:38 +0000 (UTC) (envelope-from bapt@FreeBSD.org) Received: by ivaldir.etoilebsd.net (Postfix, from userid 1001) id 966CDB6EA4; Mon, 24 Jun 2019 15:57:37 +0200 (CEST) Date: Mon, 24 Jun 2019 15:57:37 +0200 From: Baptiste Daroussin To: Mark Johnston Cc: freebsd-hackers@freebsd.org, re@freebsd.org Subject: Re: release notes file Message-ID: <20190624135737.42mf3fi7q75xipsx@ivaldir.net> References: <20190623191818.GA84365@raichu> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="chvxchzn52lstko7" Content-Disposition: inline In-Reply-To: <20190623191818.GA84365@raichu> User-Agent: NeoMutt/20180716 X-Rspamd-Queue-Id: D87736F496 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-2.98 / 15.00]; local_wl_from(0.00)[FreeBSD.org]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.98)[-0.979,0]; ASN(0.00)[asn:11403, ipnet:2610:1c1:1::/48, country:US] 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 13:57:39 -0000 --chvxchzn52lstko7 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jun 23, 2019 at 03:18:18PM -0400, Mark Johnston wrote: > Hi, >=20 > 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. >=20 > For example: >=20 > Index: RELNOTES > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- 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. >=20 > What do folks think? I do like this idea, and maybe it should be made in a parseable format, so = that it can serve to create some messages to display while running pkg upgrade (= for pkgbase). pkg knows to only print message when going from a given revision of a packa= ge to another (and only in this case) to avoid having too many noise to the outpu= t. I think it would be a nice feature for pkgbase :) Bapt --chvxchzn52lstko7 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEgOTj3suS2urGXVU3Y4mL3PG3PloFAl0Q1s8ACgkQY4mL3PG3 PlqEkxAAroHAVOQ3QQX/PYh5N4zdVhgesT9S23cGGvwXgLk5VWoG3q3Tvbg/V0c/ utdIRgJrSGd96/U3roQmOK8LtWR144zdLQCwUDPe5JUBwUFAHGL+KlOW8K9tAPbJ ++bN+UxxBk9KCGYRiCBUOkm+OJz25I1AaIEqj/t0zHkoYh7H23lVz/0gRs61FZ9s plPpmosTmZPEd6fju07TkBoa/lA4WtK8wGqD2iQF6SLCbuFIcBDqwR2PQQZSwJ+C RiEd2I0R7UlU4i3x98zMUCF5mo6OdEa7U/BzfJQFtrlj6qxCF3WYLKijtBJDWBLk D98/ocy/MelHwxticUOiQgBtBLCefP0YRA0l6B52uZHkUh+YANPCnpKL8Kn945ls Lef6KW7V+tPuwg+5cGWRuybUySGKndQHHGu38tAvXvHSKHbWi0bpILg1MQIn2sly okZ1pubqcs7yzD/6zuohXbQ21NJdqOJUq36t8Z0EcOZWP+xi8zaZzU2nXr10GqFI r8mO/DmA6v0cUmFqRvYYqEWIDhTMa0YU9STIwcB98ZyTArHsUNXIJWVLLaCZStrk H2gRVJgjjwVyVp0/ePLZIo0OLQP0poGrQCkpKYwXNfpgeRt5pP2C46rHgPLJsF8o baZuE0ovS4IblczeA7D1T6K3WafVBpo/ETktgnz36S5Ff77NyXY= =iA1L -----END PGP SIGNATURE----- --chvxchzn52lstko7-- From owner-freebsd-hackers@freebsd.org Mon Jun 24 15:08:48 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 7478815D06D8 for ; Mon, 24 Jun 2019 15:08:48 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 916C67228C; Mon, 24 Jun 2019 15:08:47 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (localhost [127.0.0.1]) by gndrsh.dnsmgr.net (8.13.3/8.13.3) with ESMTP id x5OF8hOn044130; Mon, 24 Jun 2019 08:08:43 -0700 (PDT) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: (from freebsd-rwg@localhost) by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id x5OF8hi4044129; Mon, 24 Jun 2019 08:08:43 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201906241508.x5OF8hi4044129@gndrsh.dnsmgr.net> Subject: Re: release notes file In-Reply-To: <56C57458-6274-47C6-A41D-0A6831A3F15E@cschubert.com> To: Cy Schubert Date: Mon, 24 Jun 2019 08:08:43 -0700 (PDT) CC: freebsd-hackers@freebsd.org, Mark Johnston , re@freebsd.org X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Rspamd-Queue-Id: 916C67228C X-Spamd-Bar: ++ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [2.40 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.11)[-0.109,0]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; TO_DN_SOME(0.00)[]; NEURAL_SPAM_SHORT(0.91)[0.906,0]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[dnsmgr.net]; AUTH_NA(1.00)[]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MX_GOOD(-0.01)[cached: gndrsh.dnsmgr.net]; NEURAL_SPAM_LONG(0.67)[0.673,0]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:13868, ipnet:69.59.192.0/19, country:US]; MID_RHS_MATCH_FROM(0.00)[]; IP_SCORE(0.04)[ip: (0.14), ipnet: 69.59.192.0/19(0.07), asn: 13868(0.05), country: US(-0.06)] 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:08:48 -0000 > On June 23, 2019 12:18:18 PM PDT, 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. > > > >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@freebsd.org mailing list > >https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > >To unsubscribe, send any mail to > >"freebsd-hackers-unsubscribe@freebsd.org" > > There should also be a Makefile target to install it into /etc for people who do not install sources. For those that did not install src's there is the formal Release Notes, which is what is condensed from this. Though the idea of a Makefile entry to populate /etc with a version of this for snapshots and other such things is an idea worth considering. > Cy Schubert -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-hackers@freebsd.org Mon Jun 24 15:41:22 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 3075115D0E9A for ; Mon, 24 Jun 2019 15:41:22 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from smtp-out-no.shaw.ca (smtp-out-no.shaw.ca [64.59.134.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id DF25973173; Mon, 24 Jun 2019 15:41:20 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from spqr.komquats.com ([70.67.125.17]) by shaw.ca with ESMTPA id fR5ohKkuDldkPfR5pheIgP; Mon, 24 Jun 2019 09:41:19 -0600 X-Authority-Analysis: v=2.3 cv=Ko4zJleN c=1 sm=1 tr=0 a=VFtTW3WuZNDh6VkGe7fA3g==:117 a=VFtTW3WuZNDh6VkGe7fA3g==:17 a=jpOVt7BSZ2e4Z31A5e1TngXxSK0=:19 a=IkcTkHD0fZMA:10 a=dq6fvYVFJ5YA:10 a=6I5d2MoRAAAA:8 a=YxBL1-UpAAAA:8 a=n6k8NqbHqnZ7CfTDqAUA:9 a=QEXdDO2ut3YA:10 a=IjZwj45LgO3ly-622nXo:22 a=Ia-lj3WSrqcvXOmTRaiG:22 Received: from android-9b917f0ce39da6e6.esitwifi.local (S0106788a207e2972.gv.shawcable.net [70.66.154.233]) by spqr.komquats.com (Postfix) with ESMTPSA id 617E4AAA; Mon, 24 Jun 2019 08:41:15 -0700 (PDT) Date: Mon, 24 Jun 2019 07:57:02 -0700 User-Agent: K-9 Mail for Android In-Reply-To: <20190624003616.GA90409@raichu> References: <20190623191818.GA84365@raichu> <55030704-F521-4D6E-9B56-4B7F65EFFC38@FreeBSD.org> <20190624003616.GA90409@raichu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: release notes file To: freebsd-hackers@freebsd.org, Mark Johnston , "Bjoern A. Zeeb" CC: re@freebsd.org From: Cy Schubert Message-ID: <8FF694F5-D5FC-467E-ADBE-244C3A3254D2@cschubert.com> X-CMAE-Envelope: MS4wfFv+a11HJqwrLn5fel1rKPYbFGEWiPEIwNo+celwsrLqLnENo43eucffBRFkx51C3ytMjchVFAb2Z5rfHsbKjGV51dw3lAyPPJ2YmwjvmvHs1r9szHVL O6SSbvZajaMg2ty1kJwDQ9KWCoTHlj+xOpjE2iWYfAjeT//KjMqCVLlg5T/Eb+xx6xP7WSiBGGJC20mBuwJu4xBkEcx4UzNKccOq61EXaUUo1+Q11Bge7EOp wO5DUupeb8VkzwmO28DuuT6+7cUzc0A4GylU1z9c06M= X-Rspamd-Queue-Id: DF25973173 X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-5.72 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; RCVD_COUNT_THREE(0.00)[3]; IP_SCORE(-2.56)[ip: (-6.91), ipnet: 64.59.128.0/20(-3.27), asn: 6327(-2.54), country: CA(-0.09)]; MX_GOOD(-0.01)[cached: spqr.komquats.com]; NEURAL_HAM_SHORT(-0.95)[-0.948,0]; R_SPF_NA(0.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[13.134.59.64.list.dnswl.org : 127.0.5.1]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; RECEIVED_SPAMHAUS_PBL(0.00)[17.125.67.70.zen.spamhaus.org : 127.0.0.11,233.154.66.70.zen.spamhaus.org : 127.0.0.11]; ASN(0.00)[asn:6327, ipnet:64.59.128.0/20, country:CA]; MID_RHS_MATCH_FROM(0.00)[]; FROM_EQ_ENVFROM(0.00)[] 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:41:22 -0000 On June 23, 2019 5:36:16 PM PDT, Mark Johnston 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=20 >> > write >> > the text of a release note=2E I would like to propose adding a=20 >> > 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=20 >> people, and the docs people, and all other kinds of hats can put >things=20 >> in there as well? > >Virtually all of the 12=2E0 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)=2E 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=2E Can we just put >them=20 >> in the right place and just fill them from a skeleton where they >should=20 >> be and naturally grow the document (feel free to use a different >markup=20 >> language once doc is ready for that)=2E >>=20 >> Oh, with that release notes are written automatically and you are >still=20 >> responsible for that your stuff is in there=2E And the release notes >only=20 >> 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=20 >> just vanish as we=E2=80=99d have these updated at least every 10 minute= s=20 >> automatically =2E=2E on our web server under /releases/ where they belo= ng >=2E=2E >>=20 >> 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=2E There are lots of >__FreeBSD_version bumps that go undocumented until someone else goes in >and fills in the missing entries=2E A plain-text file in src repo for >src >release notes is low-friction and creates only marginally more work for >RE=2E "What's cooking for 13?" can just point to the copy of RELNOTES in >svnweb=2E > >That said, I personally would try to commit my release notes to a doc >repo file if one existed=2E I've spent a few minutes trying to compile >the 12=2E0 notes on my desktop and have not been able to get past, >"cannot >parse http://www=2EFreeBSD=2Eorg/XML/share/xml/freebsd-xhtml-release=2Exs= l"=2E >So, I'm probably not a good person to set up release notes for 13=2E0=2E = I >will help fill in entries for commits since the 12=2E0 if someone else >does that setup=2E >_______________________________________________ >freebsd-hackers@freebsd=2Eorg mailing list >https://lists=2Efreebsd=2Eorg/mailman/listinfo/freebsd-hackers >To unsubscribe, send any mail to >"freebsd-hackers-unsubscribe@freebsd=2Eorg" Src and ports should each have their own RELNOTES file=2E The only operational concern I have is trimming the file, probably when a = branch goes EOL=2E --=20 Pardon the typos and autocorrect, small keyboard in use=2E Cheers, Cy Schubert FreeBSD UNIX: Web: http://www=2EFreeBSD=2Eorg The need of the many outweighs the greed of the few=2E 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 From owner-freebsd-hackers@freebsd.org Mon Jun 24 16:14:07 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 8E8ED15D1F3C for ; Mon, 24 Jun 2019 16:14:07 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6B1A374ED4; Mon, 24 Jun 2019 16:14:06 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (localhost [127.0.0.1]) by gndrsh.dnsmgr.net (8.13.3/8.13.3) with ESMTP id x5OGE2xk044470; Mon, 24 Jun 2019 09:14:02 -0700 (PDT) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: (from freebsd-rwg@localhost) by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id x5OGE2UH044469; Mon, 24 Jun 2019 09:14:02 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201906241614.x5OGE2UH044469@gndrsh.dnsmgr.net> Subject: Re: release notes file In-Reply-To: <8FF694F5-D5FC-467E-ADBE-244C3A3254D2@cschubert.com> To: Cy Schubert Date: Mon, 24 Jun 2019 09:14:02 -0700 (PDT) CC: freebsd-hackers@freebsd.org, Mark Johnston , "Bjoern A. Zeeb" , re@freebsd.org X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Rspamd-Queue-Id: 6B1A374ED4 X-Spamd-Bar: ++ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [2.81 / 15.00]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_SPAM_SHORT(0.90)[0.904,0]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[dnsmgr.net]; AUTH_NA(1.00)[]; RCPT_COUNT_FIVE(0.00)[5]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MX_GOOD(-0.01)[cached: gndrsh.dnsmgr.net]; NEURAL_SPAM_LONG(0.85)[0.847,0]; NEURAL_SPAM_MEDIUM(0.13)[0.126,0]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:13868, ipnet:69.59.192.0/19, country:US]; MID_RHS_MATCH_FROM(0.00)[]; IP_SCORE(0.04)[ip: (0.14), ipnet: 69.59.192.0/19(0.07), asn: 13868(0.05), country: US(-0.06)] 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 16:14:07 -0000 > 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 ?What?s cooking for 13?? or similar could > >> just vanish as we?d have these updated at least every 10 minutes > >> 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. There is no doubt the file needs trimming, it is a matter of what to trim and when to trim it. Further though and discussion on that needs to occur, it is not a clean and dry answer. Technically when you create the branch there are no new commits in that branch that need Relnotes notices, that data is all in the parent branch. The version of the RELNOTES file at this point could be very valuable, or could be noise that clutters the process. I can see that there is the issue of you need to bring over all the parent branch relnotes related entries, that are applicable, so maybe that goes into a seperate section to be weeded through? Glen showed a graph that was probably from some of the discussions I have had with him on this topic. And given he has created more release notes than any of us it is him who has the expertise in what data it is he needs in that creation process, so I would defer the decision to him, though I am sure he is open to inputs. -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-hackers@freebsd.org Mon Jun 24 16:29:52 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 8119915D22E9 for ; Mon, 24 Jun 2019 16:29:52 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 96A6575620; Mon, 24 Jun 2019 16:29:51 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (localhost [127.0.0.1]) by gndrsh.dnsmgr.net (8.13.3/8.13.3) with ESMTP id x5OGTmsC044505; Mon, 24 Jun 2019 09:29:48 -0700 (PDT) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: (from freebsd-rwg@localhost) by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id x5OGTmpd044504; Mon, 24 Jun 2019 09:29:48 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201906241629.x5OGTmpd044504@gndrsh.dnsmgr.net> Subject: Re: release notes file In-Reply-To: To: Warner Losh Date: Mon, 24 Jun 2019 09:29:48 -0700 (PDT) CC: Cy Schubert , "freebsd-hackers@freebsd.org" , "Bjoern A. Zeeb" , Mark Johnston , FreeBSD Release Engineering Team X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Rspamd-Queue-Id: 96A6575620 X-Spamd-Bar: ++ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [2.77 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_SPAM_SHORT(0.90)[0.900,0]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[dnsmgr.net]; AUTH_NA(1.00)[]; RCPT_COUNT_FIVE(0.00)[6]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MX_GOOD(-0.01)[cached: gndrsh.dnsmgr.net]; NEURAL_SPAM_LONG(0.84)[0.844,0]; NEURAL_SPAM_MEDIUM(0.09)[0.092,0]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:13868, ipnet:69.59.192.0/19, country:US]; MID_RHS_MATCH_FROM(0.00)[]; IP_SCORE(0.04)[ip: (0.14), ipnet: 69.59.192.0/19(0.07), asn: 13868(0.05), country: US(-0.06)] 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 16:29:52 -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 ?What?s cooking for 13?? or similar could > > >> just vanish as we?d have these updated at least every 10 minutes > > >> 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. I disagree, truncating the file on -current destroys the list of changes that are still in current that need to get into the next set of release notes. Howerver there is 1 point on head/ to truncate the file. That is when we create a new .0 branch as that is the tree state that has nothing to put in the release notes. This may be the most sane path forward that I had not thought of before. All other branched versions can just continue to grow until EOL. This bounds the file to about a 2.5 year collection in head/, and a 5.0 year collection in stable/. It may make since to truncate on stable/X when stable/X.Y's are created. I think we need to be fairly careful with the MFCing of this, that may work fine for things that are commited with a RELNOTES entry, something in the back of my head is screaming lots of merge conflicts but I can not put a solid finger on it. Something just hit me, what commit number goes in this file, if we list it by rXXXXXX of head, that has a rYYYYYY when MFC'ed, probably need to track both? Which means all existing entries get an added line at stable/X creation to indicated the commit that created the branch? If we try to simplify and only track by head commit that makes it harded to go find the MFC and see if there was merge munging to make it work. > Warner -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-hackers@freebsd.org Mon Jun 24 17:06:37 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 08A1915D2E86 for ; Mon, 24 Jun 2019 17:06:37 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from smtp-out-so.shaw.ca (smtp-out-so.shaw.ca [64.59.136.139]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id C7D6776A7C; Mon, 24 Jun 2019 17:06:34 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from spqr.komquats.com ([70.67.125.17]) by shaw.ca with ESMTPA id fSQFhoxISGusjfSQHhalbC; Mon, 24 Jun 2019 11:06:31 -0600 X-Authority-Analysis: v=2.3 cv=fOdHIqSe c=1 sm=1 tr=0 a=VFtTW3WuZNDh6VkGe7fA3g==:117 a=VFtTW3WuZNDh6VkGe7fA3g==:17 a=jpOVt7BSZ2e4Z31A5e1TngXxSK0=:19 a=IkcTkHD0fZMA:10 a=dq6fvYVFJ5YA:10 a=iKhvJSA4AAAA:8 a=YxBL1-UpAAAA:8 a=6I5d2MoRAAAA:8 a=eeSdjhnMUMhRrhh-RzUA:9 a=4pr309j300RNxBSQ:21 a=K4irkvPNajIRuIrX:21 a=QEXdDO2ut3YA:10 a=odh9cflL3HIXMm4fY7Wr:22 a=Ia-lj3WSrqcvXOmTRaiG:22 a=IjZwj45LgO3ly-622nXo:22 Received: from android-9b917f0ce39da6e6.esitwifi.local (S0106788a207e2972.gv.shawcable.net [70.66.154.233]) by spqr.komquats.com (Postfix) with ESMTPSA id 1832BB59; Mon, 24 Jun 2019 10:06:26 -0700 (PDT) Date: Mon, 24 Jun 2019 10:06:02 -0700 User-Agent: K-9 Mail for Android In-Reply-To: <201906241629.x5OGTmpd044504@gndrsh.dnsmgr.net> References: <201906241629.x5OGTmpd044504@gndrsh.dnsmgr.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: release notes file To: "Rodney W. Grimes" , Warner Losh CC: "freebsd-hackers@freebsd.org" , "Bjoern A. Zeeb" , Mark Johnston , FreeBSD Release Engineering Team From: Cy Schubert Message-ID: <2BD397BB-FD96-4A06-9263-DD35B2CA494D@cschubert.com> X-CMAE-Envelope: MS4wfFjQd+0BohiBZ34aGNbyc7umoozE7cSYIXHVkJcBPrkcWHsPiHJ0E2XCDIqsrmcNo8mleJT6XJisU+8zAuaSoq52yMlD3g8IZtnn11ijK2V7VPhslNa7 ghMI9qJ0X/Ioi0vUijJKa2YFabE/9OHOWn6neIbgzTPDyt+RylcUZJyBA9wkOVcF+Cr3eSEr4QNOGQL8EQ/C8xdjdW+XU/aAlJIiLnjfEEdNWglx9Y1v2Pp5 Tl1ZnzO4VhjHADlwCYzKaJ4MUyBUNS3bKUsKkgl+8YBWHi987sxCzhJ2lbp9ZQhWleEZK/Rm60EavIz4bvEQAh+JsMwi7o8BrkAe4Og+/3E= X-Rspamd-Queue-Id: C7D6776A7C X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-5.58 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; RCPT_COUNT_FIVE(0.00)[6]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MX_GOOD(-0.01)[cached: spqr.komquats.com]; NEURAL_HAM_SHORT(-0.98)[-0.977,0]; RECEIVED_SPAMHAUS_PBL(0.00)[17.125.67.70.zen.spamhaus.org : 127.0.0.11,233.154.66.70.zen.spamhaus.org : 127.0.0.11]; R_SPF_NA(0.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[139.136.59.64.list.dnswl.org : 127.0.5.1]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:6327, ipnet:64.59.128.0/20, country:CA]; MID_RHS_MATCH_FROM(0.00)[]; IP_SCORE(-2.39)[ip: (-6.05), ipnet: 64.59.128.0/20(-3.27), asn: 6327(-2.54), country: CA(-0.09)]; FROM_EQ_ENVFROM(0.00)[] 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 17:06:37 -0000 On June 24, 2019 9:29:48 AM PDT, "Rodney W=2E Grimes" wrote: >> On Mon, Jun 24, 2019 at 9:44 AM Cy Schubert > >> wrote: >>=20 >> > On June 23, 2019 5:36:16 PM PDT, Mark Johnston >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: >> > >> >> > >> Hi, >> > >> >> > >> > 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 >> > >> >> > >> 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? >> > > >> > >Virtually all of the 12=2E0 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)=2E 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=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 >> > >> >> > >> 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? >> > >> >> > >> And the wiki pages like ?What?s cooking for 13?? or similar >could >> > >> just vanish as we?d have these updated at least every 10 minutes >> > >> automatically =2E=2E on our web server under /releases/ where they >belong >> > >=2E=2E >> > >> >> > >> 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=2E There are lots >of >> > >__FreeBSD_version bumps that go undocumented until someone else >goes in >> > >and fills in the missing entries=2E A plain-text file in src repo >for >> > >src >> > >release notes is low-friction and creates only marginally more >work for >> > >RE=2E "What's cooking for 13?" can just point to the copy of >RELNOTES in >> > >svnweb=2E >> > > >> > >That said, I personally would try to commit my release notes to a >doc >> > >repo file if one existed=2E I've spent a few minutes trying to >compile >> > >the 12=2E0 notes on my desktop and have not been able to get past, >> > >"cannot >> > >parse >http://www=2EFreeBSD=2Eorg/XML/share/xml/freebsd-xhtml-release=2Exsl"=2E >> > >So, I'm probably not a good person to set up release notes for >13=2E0=2E I >> > >will help fill in entries for commits since the 12=2E0 if someone >else >> > >does that setup=2E >> > >_______________________________________________ >> > >freebsd-hackers@freebsd=2Eorg mailing list >> > >https://lists=2Efreebsd=2Eorg/mailman/listinfo/freebsd-hackers >> > >To unsubscribe, send any mail to >> > >"freebsd-hackers-unsubscribe@freebsd=2Eorg" >> > >> > Src and ports should each have their own RELNOTES file=2E >> > >> > The only operational concern I have is trimming the file, probably >when a >> > branch goes EOL=2E >> > >>=20 >> I'd add truncating the file on -current to the list of things we do >when we >> branch=2E then we can MFC RELNOTES as we MFC the features they >describe=2E > >I disagree, truncating the file on -current destroys the list of >changes that are still in current that need to get into the next >set of release notes=2E > >Howerver there is 1 point on head/ to truncate the file=2E >That is when we create a new =2E0 branch as that is the tree state >that has nothing to put in the release notes=2E This may be the >most sane path forward that I had not thought of before=2E All >other branched versions can just continue to grow until EOL=2E >This bounds the file to about a 2=2E5 year collection in head/, >and a 5=2E0 year collection in stable/=2E >It may make since to truncate on stable/X when stable/X=2EY's >are created=2E > >I think we need to be fairly careful with the MFCing of this, >that may work fine for things that are commited with a RELNOTES >entry, something in the back of my head is screaming lots of >merge conflicts but I can not put a solid finger on it=2E > >Something just hit me, what commit number goes in this file, >if we list it by rXXXXXX of head, that has a rYYYYYY when MFC'ed, >probably need to track both? Which means all existing entries get >an added line at stable/X creation to indicated the commit that >created the branch? If we try to simplify and only track by=20 >head commit that makes it harded to go find the MFC and see >if there was merge munging to make it work=2E > >> Warner Which is why trimming at branch EOL probably makes the most sense=2E It's = simple and easy to implement=2E As for what to do about MFCs and more specifically conflicts, conflicts wi= ll be unavoidable=2E IMO conflicts with RELNOTES will be as likely as with = UPDATING or Obsoletefiles=2E=20 --=20 Pardon the typos and autocorrect, small keyboard in use=2E Cheers, Cy Schubert FreeBSD UNIX: Web: http://www=2EFreeBSD=2Eorg The need of the many outweighs the greed of the few=2E From owner-freebsd-hackers@freebsd.org Mon Jun 24 17:45:30 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 5D69215D3D1A for ; Mon, 24 Jun 2019 17:45:30 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qt1-x832.google.com (mail-qt1-x832.google.com [IPv6:2607:f8b0:4864:20::832]) (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 D919877EAF for ; Mon, 24 Jun 2019 17:45:28 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qt1-x832.google.com with SMTP id w40so4848574qtk.0 for ; Mon, 24 Jun 2019 10:45:28 -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=/CueTMrZsSuAkEmaN1L8sJk2REVGN2bBs+aGTIeZeHY=; b=atYNuDhf9oR8ZBOREzcAVlgETP7vt+8yxHH+4pHVVQEdogPjOWAtw6KUnvY/EkSnJc 5gcsSPVZ259t8o1zyRp6+nSzjLo0DpsQeITpNC1lIMQQRpJQBJ+dWM90+qZ5C3S1aj5p 5jqq2spMMabO0BzLKblOCKiJT5VLAj4b1wCPrv/WvgWi2QP7PRblRyvsRuhJ9qrTyOcc svvfcOvskM6k3qMGagYt17HkZnLDOsI4oOAKtIJHMWA2r0r7sm+cpc6XetKM9MgARZ/1 6DzQ4KtXw+SdzRBQS+B5orll5jP+uvus1uGsxqYZsEtNWptm6qqGXmB3ic3c0a0VT3sY /opA== 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=/CueTMrZsSuAkEmaN1L8sJk2REVGN2bBs+aGTIeZeHY=; b=BZVU14jaP1em0AVS2vYM+JppzwxRstRe4Mp7hge8XPldMow9cSFg+b4TfKEARmc8Po oX1LNnaVVCqU+l12w2b9TqTOG5PXzy9JREmyvg2swir9X/4/uv0TB+JOTiVdy68AMZ6C xuX4vLcZO5HEHuFWU/wcowRHGU3O4E3yfhQCljEWllBPkfWYSwuLqTyw4hOWghOnBMaE MwvbnqAGsrALI88LIaPSctR431SrKE2SMkVS4+y/owUwpT0RGQ42HBGGeFMTFuAUURVo W5UOll6gMi2qx9gtyWiOMYdL74anKS2H9BrCHPaE4zHycBzkl/g8EMlV28b3jd5GYpHh hsRQ== X-Gm-Message-State: APjAAAUt0n0yPdRHI/M5ES9OomCfFTsNb8EKuQw88iX6TrNKB2saXym7 6luaTId/e1hgYXkKEP2CYmqI0Y6NwNV+MkucZvBNrQ== X-Google-Smtp-Source: APXvYqw9nt8ssM74ESl/9TKQxabWjV5ReCOzyP48K0vMaHJ1rjKbSKyhgw7bj8Qw6uW5ioXrXPBgRwfN2T9GS1fTmvA= X-Received: by 2002:aed:3e1d:: with SMTP id l29mr117565524qtf.175.1561398327968; Mon, 24 Jun 2019 10:45:27 -0700 (PDT) MIME-Version: 1.0 References: <201906241629.x5OGTmpd044504@gndrsh.dnsmgr.net> <2BD397BB-FD96-4A06-9263-DD35B2CA494D@cschubert.com> In-Reply-To: <2BD397BB-FD96-4A06-9263-DD35B2CA494D@cschubert.com> From: Warner Losh Date: Mon, 24 Jun 2019 11:45:16 -0600 Message-ID: Subject: Re: release notes file To: Cy Schubert Cc: "Rodney W. Grimes" , "freebsd-hackers@freebsd.org" , "Bjoern A. Zeeb" , Mark Johnston , FreeBSD Release Engineering Team X-Rspamd-Queue-Id: D919877EAF X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20150623.gappssmtp.com header.s=20150623 header.b=atYNuDhf X-Spamd-Result: default: False [-4.90 / 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)[6]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20150623.gappssmtp.com:+]; MX_GOOD(-0.01)[cached: ALT1.aspmx.l.google.com]; RCVD_IN_DNSWL_NONE(0.00)[2.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.90)[-0.902,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(-2.99)[ip: (-9.43), ipnet: 2607:f8b0::/32(-3.15), asn: 15169(-2.33), country: US(-0.06)]; RCVD_COUNT_TWO(0.00)[2] Content-Type: text/plain; charset="UTF-8" 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 17:45:30 -0000 On Mon, Jun 24, 2019 at 11:06 AM Cy Schubert wrote: > On June 24, 2019 9:29:48 AM PDT, "Rodney W. Grimes" < > freebsd-rwg@gndrsh.dnsmgr.net> wrote: > >> 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 ?What?s cooking for 13?? or similar > >could > >> > >> just vanish as we?d have these updated at least every 10 minutes > >> > >> 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. > > > >I disagree, truncating the file on -current destroys the list of > >changes that are still in current that need to get into the next > >set of release notes. > > > >Howerver there is 1 point on head/ to truncate the file. > >That is when we create a new .0 branch as that is the tree state > >that has nothing to put in the release notes. This may be the > >most sane path forward that I had not thought of before. All > >other branched versions can just continue to grow until EOL. > >This bounds the file to about a 2.5 year collection in head/, > >and a 5.0 year collection in stable/. > >It may make since to truncate on stable/X when stable/X.Y's > >are created. > > > >I think we need to be fairly careful with the MFCing of this, > >that may work fine for things that are commited with a RELNOTES > >entry, something in the back of my head is screaming lots of > >merge conflicts but I can not put a solid finger on it. > > > >Something just hit me, what commit number goes in this file, > >if we list it by rXXXXXX of head, that has a rYYYYYY when MFC'ed, > >probably need to track both? Which means all existing entries get > >an added line at stable/X creation to indicated the commit that > >created the branch? If we try to simplify and only track by > >head commit that makes it harded to go find the MFC and see > >if there was merge munging to make it work. > > > >> Warner > > Which is why trimming at branch EOL probably makes the most sense. It's > simple and easy to implement. > I don't understand this at all. When we branch a new stable release, we know that on the new current release we have nothing not in the release notes file. What does branch EOL have to do with that? > As for what to do about MFCs and more specifically conflicts, conflicts > will be unavoidable. IMO conflicts with RELNOTES will be as likely as with > UPDATING or Obsoletefiles. > Yea. If we keep the structure of the file super simple (like markdown), then it doesn't matter. You fix the conflicts and go. The merged version need not be tracked since you know it's merged if it is in RELNOTES, and most MFCs don't replicate the full context of the original commit any, but just have a pointer to it. Warner From owner-freebsd-hackers@freebsd.org Mon Jun 24 17:52:18 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 3859215D4092 for ; Mon, 24 Jun 2019 17:52:18 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-io1-xd41.google.com (mail-io1-xd41.google.com [IPv6:2607:f8b0:4864:20::d41]) (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 95CF580369; Mon, 24 Jun 2019 17:52:17 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mail-io1-xd41.google.com with SMTP id m24so242248ioo.2; Mon, 24 Jun 2019 10:52:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=jOpNEIlseak6XfSB9qecVyIg6z320iK6tufnV9KpUD0=; b=k5nWuIR1F7hy5wL6c3VyWGjB7lX+D9u9ST7e44MBqE49MYii1RBCq4NJkD8aMySNd+ vym26JSysQWIWgWS6dAMmVCyIy0C2RWQljG9XPdZ9UqLCJc7VncPRKmIboyrdAjjY/Mw wXXyH4mDY3e28WIbxlIRUWfBVo2aCn3r4PdB0YF/krvT2HRBg6EMu4+RetzssnayzUP/ aGGmd27hVOTxgUtyM1zpyZkDfObmBRchAOWKXkDEryO/DgPbv8/kF4qmQYKPK8ABLo/R Zs5ivK1swTejQJrtuVWdcQUXxexDYDk+geDi3fgrr658R3u3FBdNE9ZJUzlwEAzxvXRY 6okA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to:user-agent; bh=jOpNEIlseak6XfSB9qecVyIg6z320iK6tufnV9KpUD0=; b=eDM+EaJSKn04ua1k6UHD47Hv1hAYgW8S74M1XiWDWcKjGLFxfmiM3B3V3y+7lOYxc7 R3CO7YjHX0xLl2R4DZrPId3AI168YePbxDyG9fChhvm4XBjuEchWYFeVd9D/KJxHV4lb I3JXAFGudRzh7z98DrKYzoXeYZsW7cn7O27hna50K9qPUTWDlrV4LSDRP18SnCCvqvQV ShdwVU0jb6UBGFvUHxyJkrLg02U1wLxbVdNlZuZ7B+cttwLC7QXhyh3jP9fsQ+gP08Tz kAeS6H2OLQp6nUBYLlYzZmtFkV2NaKIyYq5QPd7MaMAIOeY5zbPrK8waUUtoEPbf3q2t 0wpQ== X-Gm-Message-State: APjAAAWqbiwTZJQn/IEx1YrydQ+/9TQ2QkKlPe3US7xWj5PNY3+aWpZc c65XeNQDPeOvVvM32IkVuv/Ml/3x X-Google-Smtp-Source: APXvYqx63+LQIamqHMa1Zh4QZTPKuxRa7AKuZDjk3i5uWOfjlmv4qCM8qo/xdRHOeCZsua/MTj0l5A== X-Received: by 2002:a6b:7f0b:: with SMTP id l11mr113762531ioq.282.1561398736589; Mon, 24 Jun 2019 10:52:16 -0700 (PDT) Received: from raichu (toroon0560w-lp140-05-70-29-85-38.dsl.bell.ca. [70.29.85.38]) by smtp.gmail.com with ESMTPSA id p9sm10679666ioj.49.2019.06.24.10.52.15 (version=TLS1_3 cipher=AEAD-AES256-GCM-SHA384 bits=256/256); Mon, 24 Jun 2019 10:52:15 -0700 (PDT) Sender: Mark Johnston Date: Mon, 24 Jun 2019 13:52:11 -0400 From: Mark Johnston To: Baptiste Daroussin Cc: freebsd-hackers@freebsd.org, re@freebsd.org Subject: Re: release notes file Message-ID: <20190624175211.GA66843@raichu> References: <20190623191818.GA84365@raichu> <20190624135737.42mf3fi7q75xipsx@ivaldir.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190624135737.42mf3fi7q75xipsx@ivaldir.net> User-Agent: Mutt/1.12.0 (2019-05-25) X-Rspamd-Queue-Id: 95CF580369 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=k5nWuIR1; spf=pass (mx1.freebsd.org: domain of markjdb@gmail.com designates 2607:f8b0:4864:20::d41 as permitted sender) smtp.mailfrom=markjdb@gmail.com X-Spamd-Result: default: False [-3.57 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[freebsd.org]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; RCVD_COUNT_THREE(0.00)[3]; IP_SCORE(-0.88)[ip: (1.15), ipnet: 2607:f8b0::/32(-3.15), asn: 15169(-2.33), country: US(-0.06)]; DKIM_TRACE(0.00)[gmail.com:+]; MX_GOOD(-0.01)[cached: alt3.gmail-smtp-in.l.google.com]; RCVD_IN_DNSWL_NONE(0.00)[1.4.d.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.98)[-0.981,0]; FORGED_SENDER(0.30)[markj@freebsd.org,markjdb@gmail.com]; MIME_TRACE(0.00)[0:+]; MID_RHS_NOT_FQDN(0.50)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[markj@freebsd.org,markjdb@gmail.com] 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 17:52:18 -0000 On Mon, Jun 24, 2019 at 03:57:37PM +0200, Baptiste Daroussin wrote: > On Sun, Jun 23, 2019 at 03:18:18PM -0400, 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. > > > > 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? > > I do like this idea, and maybe it should be made in a parseable format, so that > it can serve to create some messages to display while running pkg upgrade (for > pkgbase). > > pkg knows to only print message when going from a given revision of a package to > another (and only in this case) to avoid having too many noise to the output. Can you explain a bit further? I'm only familiar with pkg-message, which is unstructured and always printed AFAIK. > I think it would be a nice feature for pkgbase :) From owner-freebsd-hackers@freebsd.org Mon Jun 24 19:28:40 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 3316F15D70FC for ; Mon, 24 Jun 2019 19:28:40 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from smtp-out-no.shaw.ca (smtp-out-no.shaw.ca [64.59.134.9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id BDD28845DD; Mon, 24 Jun 2019 19:28:38 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from spqr.komquats.com ([70.67.125.17]) by shaw.ca with ESMTPA id fUdghNfRRsAGkfUdhhjtnj; Mon, 24 Jun 2019 13:28:31 -0600 X-Authority-Analysis: v=2.3 cv=WeVylHpX c=1 sm=1 tr=0 a=VFtTW3WuZNDh6VkGe7fA3g==:117 a=VFtTW3WuZNDh6VkGe7fA3g==:17 a=jpOVt7BSZ2e4Z31A5e1TngXxSK0=:19 a=kj9zAlcOel0A:10 a=dq6fvYVFJ5YA:10 a=xfDLHkLGAAAA:8 a=YxBL1-UpAAAA:8 a=iKhvJSA4AAAA:8 a=6I5d2MoRAAAA:8 a=ihLmRic6LxAFEx1RyPEA:9 a=rVnsKfbM7t8OGkJA:21 a=-xq0APv4xBvugdXA:21 a=CjuIK1q_8ugA:10 a=IfaqVvZgccqrtc8gcwf2:22 a=Ia-lj3WSrqcvXOmTRaiG:22 a=odh9cflL3HIXMm4fY7Wr:22 a=IjZwj45LgO3ly-622nXo:22 Received: from slippy.cwsent.com (slippy8 [10.2.2.6]) by spqr.komquats.com (Postfix) with ESMTPS id 3B00DD13; Mon, 24 Jun 2019 12:28:27 -0700 (PDT) Received: from slippy.cwsent.com (localhost [127.0.0.1]) by slippy.cwsent.com (8.15.2/8.15.2) with ESMTP id x5OJSQMR005258; Mon, 24 Jun 2019 12:28:26 -0700 (PDT) (envelope-from Cy.Schubert@cschubert.com) Received: from slippy (cy@localhost) by slippy.cwsent.com (8.15.2/8.15.2/Submit) with ESMTP id x5OJSQhm005255; Mon, 24 Jun 2019 12:28:26 -0700 (PDT) (envelope-from Cy.Schubert@cschubert.com) Message-Id: <201906241928.x5OJSQhm005255@slippy.cwsent.com> X-Authentication-Warning: slippy.cwsent.com: cy owned process doing -bs X-Mailer: exmh version 2.9.0 11/07/2018 with nmh-1.7.1 Reply-to: Cy Schubert From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.cschubert.com/ To: Warner Losh cc: Cy Schubert , "Rodney W. Grimes" , "freebsd-hackers@freebsd.org" , "Bjoern A. Zeeb" , Mark Johnston , FreeBSD Release Engineering Team Subject: Re: release notes file In-Reply-To: Message from Warner Losh of "Mon, 24 Jun 2019 11:45:16 -0600." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 24 Jun 2019 12:28:26 -0700 X-CMAE-Envelope: MS4wfPq/qw2KuS0c5Y9qS13L278qG8NDjv+xorAToUMVwBtVqfpzXbeeGMsvouuCk9xFxt3a6Gq4oc+nltoQIyxlinaTSplsyVBBV9UF4G6cpXrswh633zvK EgcG0SjkM9WqHGDgwSYe4f4/vvoZN9/ZhCIXs91z0eDIHwoCRmC8j4qXPO6SmOnGbEcQsf/Wz5ywFx8NA8z74+67pxcy9/ykCYiU6UnR2kEBPEycGEhKW0w0 Ps0IVEUlBgkao3nyXxpmaLviNgfJXIcVM4Yy61Gdm/3JhklT5VbK/dU3t1H9aALU5pPY7tUnOZNFEOyXjxcrFa7dRxRbTFMIYNNl4TTCQ/c= X-Rspamd-Queue-Id: BDD28845DD X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-5.24 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; HAS_REPLYTO(0.00)[Cy.Schubert@cschubert.com]; TO_DN_SOME(0.00)[]; MV_CASE(0.50)[]; HAS_XAW(0.00)[]; MX_GOOD(-0.01)[cached: spqr.komquats.com]; NEURAL_HAM_SHORT(-0.99)[-0.989,0]; RCPT_COUNT_SEVEN(0.00)[7]; RECEIVED_SPAMHAUS_PBL(0.00)[17.125.67.70.zen.spamhaus.org : 127.0.0.11]; RCVD_IN_DNSWL_LOW(-0.10)[9.134.59.64.list.dnswl.org : 127.0.5.1]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:6327, ipnet:64.59.128.0/20, country:CA]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; RCVD_COUNT_FIVE(0.00)[5]; REPLYTO_EQ_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; R_SPF_NA(0.00)[]; IP_SCORE(-2.54)[ip: (-6.79), ipnet: 64.59.128.0/20(-3.27), asn: 6327(-2.54), country: CA(-0.09)] 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 19:28:40 -0000 In message , Warner Losh writes: > --000000000000b1250d058c156094 > Content-Type: text/plain; charset="UTF-8" > > On Mon, Jun 24, 2019 at 11:06 AM Cy Schubert > wrote: > > > On June 24, 2019 9:29:48 AM PDT, "Rodney W. Grimes" < > > freebsd-rwg@gndrsh.dnsmgr.net> wrote: > > >> 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 ?What?s cooking for 13?? or similar > > >could > > >> > >> just vanish as we?d have these updated at least every 10 minutes > > >> > >> 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. > > > > > >I disagree, truncating the file on -current destroys the list of > > >changes that are still in current that need to get into the next > > >set of release notes. > > > > > >Howerver there is 1 point on head/ to truncate the file. > > >That is when we create a new .0 branch as that is the tree state > > >that has nothing to put in the release notes. This may be the > > >most sane path forward that I had not thought of before. All > > >other branched versions can just continue to grow until EOL. > > >This bounds the file to about a 2.5 year collection in head/, > > >and a 5.0 year collection in stable/. > > >It may make since to truncate on stable/X when stable/X.Y's > > >are created. > > > > > >I think we need to be fairly careful with the MFCing of this, > > >that may work fine for things that are commited with a RELNOTES > > >entry, something in the back of my head is screaming lots of > > >merge conflicts but I can not put a solid finger on it. > > > > > >Something just hit me, what commit number goes in this file, > > >if we list it by rXXXXXX of head, that has a rYYYYYY when MFC'ed, > > >probably need to track both? Which means all existing entries get > > >an added line at stable/X creation to indicated the commit that > > >created the branch? If we try to simplify and only track by > > >head commit that makes it harded to go find the MFC and see > > >if there was merge munging to make it work. > > > > > >> Warner > > > > Which is why trimming at branch EOL probably makes the most sense. It's > > simple and easy to implement. > > > > I don't understand this at all. When we branch a new stable release, we > know that on the new current release we have nothing not in the release > notes file. What does branch EOL have to do with that? You're right. My point was to avoid some kind of complicated scheme. > > > > As for what to do about MFCs and more specifically conflicts, conflicts > > will be unavoidable. IMO conflicts with RELNOTES will be as likely as with > > UPDATING or Obsoletefiles. > > > > Yea. If we keep the structure of the file super simple (like markdown), > then it doesn't matter. You fix the conflicts and go. The merged version > need not be tracked since you know it's merged if it is in RELNOTES, and > most MFCs don't replicate the full context of the original commit any, but > just have a pointer to it. -- Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. From owner-freebsd-hackers@freebsd.org Tue Jun 25 06:34:32 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 CA62B15C23B7 for ; Tue, 25 Jun 2019 06:34:31 +0000 (UTC) (envelope-from bapt@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 70348742AB; Tue, 25 Jun 2019 06:34:31 +0000 (UTC) (envelope-from bapt@freebsd.org) Received: from ivaldir.etoilebsd.net (etoilebsd.net [178.32.217.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: bapt) by smtp.freebsd.org (Postfix) with ESMTPSA id 04BF1E8AD; Tue, 25 Jun 2019 06:34:31 +0000 (UTC) (envelope-from bapt@freebsd.org) Received: by ivaldir.etoilebsd.net (Postfix, from userid 1001) id DACB7B71AC; Tue, 25 Jun 2019 08:34:29 +0200 (CEST) Date: Tue, 25 Jun 2019 08:34:29 +0200 From: Baptiste Daroussin To: Mark Johnston Cc: freebsd-hackers@freebsd.org, re@freebsd.org Subject: Re: release notes file Message-ID: <20190625063429.r7ed72mutrytv4tb@ivaldir.net> References: <20190623191818.GA84365@raichu> <20190624135737.42mf3fi7q75xipsx@ivaldir.net> <20190624175211.GA66843@raichu> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="wu6mcrkjoufeeba3" Content-Disposition: inline In-Reply-To: <20190624175211.GA66843@raichu> User-Agent: NeoMutt/20180716 X-Rspamd-Queue-Id: 70348742AB X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-2.97 / 15.00]; local_wl_from(0.00)[freebsd.org]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.97)[-0.972,0]; ASN(0.00)[asn:11403, ipnet:96.47.64.0/20, country:US] 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: Tue, 25 Jun 2019 06:34:32 -0000 --wu6mcrkjoufeeba3 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jun 24, 2019 at 01:52:11PM -0400, Mark Johnston wrote: > On Mon, Jun 24, 2019 at 03:57:37PM +0200, Baptiste Daroussin wrote: > > On Sun, Jun 23, 2019 at 03:18:18PM -0400, Mark Johnston wrote: > > > Hi, > > >=20 > > > 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 wri= te > > > the text of a release note. I would like to propose adding a top-lev= el > > > 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. > > >=20 > > > For example: > > >=20 > > > Index: RELNOTES > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > --- 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. > > >=20 > > > What do folks think? > >=20 > > I do like this idea, and maybe it should be made in a parseable format,= so that > > it can serve to create some messages to display while running pkg upgra= de (for > > pkgbase). > >=20 > > pkg knows to only print message when going from a given revision of a p= ackage to > > another (and only in this case) to avoid having too many noise to the o= utput. >=20 > Can you explain a bit further? I'm only familiar with pkg-message, > which is unstructured and always printed AFAIK. Since pkg 1.11 messages can be written in a structured format, see: https://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/pkg-file= s.html#porting-message I am not asking for RELNOTES to be in the same format but something that ca= n be parsable with awk(1) for example and transformed into ucl base pkg-messages would be imho useful for adding messages to pkgbase. Best regards, Bapt --wu6mcrkjoufeeba3 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEgOTj3suS2urGXVU3Y4mL3PG3PloFAl0RwHMACgkQY4mL3PG3 Plo1zg//RrGzHryml/ReVLLGwL+P/Jua5IFRFq1Kvg3Y1wmWqbMnu2i3Y3Q9DrsT bO2ONpgMaEDEjNi1VYB07CGA/n8+AFX4q/FqYAu358QbXPmKFE3q4NvJpTt3b0ma i5T/EHKewRqfJjy6E65G12Vv7iXpRF+Wo3HuxPm6wJ/vc9QLlTJCVpnRZjQlzT05 bFjxp6Pk//WV+ZlFv+O94Gx0AIBc0FLbrWaKmd6/Q9MjkYQ5wV1G+Bob+mowle5I z+YGmDlYkzoSesJzFoGF5aGsekeJbi1eoszGdWPPu7MbUF1TVz33kaf9vcQM+g+Y 7zMYG2ND/go6Lk+LjXscZtcAi6tJXjE+wyChWNDVDioAsalEyaAZBGLEc/PBd8YN pPD+lEo/iVUzgJj8wRzwhkzjhHTmlKB11W/VDMTCpuLNwORj9097NFEzmJeWmbwM 2g2+3UURboWSYAciSNeHjNMNgGQHq7AbbAsJCDs2l/UQUuEzUf0lP/auRVOtOZ06 OlxS2EvAaau8CXyKUO5tivPQEX2bGe2n04/iUov1QERJ5P/pabT8RXUMgag9jgxm HT37e66qH5QzqTA3SIRPez1Za6ddkbi51Vj4yFOUUkOvJNL1FlukJu//1FuJ3F98 PIMVeZuPhSaqzTkv8DZzbDz1RUGQXTELU3RBSBhqspfp3jNP0uA= =h5WY -----END PGP SIGNATURE----- --wu6mcrkjoufeeba3-- From owner-freebsd-hackers@freebsd.org Tue Jun 25 22:25:05 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 E36AB15D8B66 for ; Tue, 25 Jun 2019 22:25:04 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound3d.ore.mailhop.org (outbound3d.ore.mailhop.org [54.186.57.195]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 27F29816FB for ; Tue, 25 Jun 2019 22:25:03 +0000 (UTC) (envelope-from ian@freebsd.org) ARC-Seal: i=1; a=rsa-sha256; t=1561500530; cv=none; d=outbound.mailhop.org; s=arc-outbound20181012; b=MUPvQrTVNUnJlMC/AOEXIMNA7p5jmoja+OucGJX8jBWLo6E2bjpUiKL10IN+r/xiHhrIQsYGjEqU0 dWSWQ/m5A3IVr9NuRjNWgzLxdR0e9vxL+RqeVsmzPfuUlUeNQegmlCzdqGDChtx0PgBqjJWn70d34t Z8Ili4uBEGOtjXhERd36R35AC5LtMmc8pLMmVTnen4jx1xC3n9fqSTaYTugkWY+Biq4aDpcRPauNir fPdzBJIHj66m1Uj6PV3qyPH/Q7gno6rUzd15FAJVXoRdPXMkqgFv18xtpHrGQns+iCJDfKOQIgzuUX f+OlI2zNx8PXXF1UjJg85AidJ7CEXRw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=arc-outbound20181012; h=content-transfer-encoding:mime-version:content-type:date:to:from:subject: message-id:dkim-signature:from; bh=WJG2hMVzBnzmYNSC3bOxg2T5h6pcX7Vnf9WMM+YKJuI=; b=MNt0SuCFkih/FZyCMMx/jp/jKcV3s9vGZz/we2ebxopvmhIXIWnlqXhgZZRlAKJnAxS3KUiSzFw4o 5nIsimUz/4KU1gdv7Ty82cupEej3OBhltFbjytUXZaxSVR6Aeepr474iKj4XbxFxAf4VGzg425k1qk H5xhCEOvRUbGnbsBYhYkuuODr7036TF8JJCMxy11t5jWyvzVp2SUg+NdmUG1Tr4zEQ8//TsELNT12H cT3NnhxZYySP0CcqkbYX+s3ayfjPEfx+AsxEvJy27svOhxdciXiDId0nghhV7A3tb863W52GMg5HbB Tg1kXefUBAX8+1NUz6P6Iafh6tf0VRg== ARC-Authentication-Results: i=1; outbound3.ore.mailhop.org; spf=softfail smtp.mailfrom=freebsd.org smtp.remote-ip=67.177.211.60; dmarc=none header.from=freebsd.org; arc=none header.oldest-pass=0; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=dkim-high; h=content-transfer-encoding:mime-version:content-type:date:to:from:subject: message-id:from; bh=WJG2hMVzBnzmYNSC3bOxg2T5h6pcX7Vnf9WMM+YKJuI=; b=B3wGS8Ov5w/XQwbzrOf8BiHk/t8s+8/Slb+ts8yiQDN9uqmcYxzuUxjjvT3AYZaFw2jwvMIp+fAf+ LZint79JNvJrcq67135xdMpOGHIRbIBlKLcCtO7EqxLD5tkJcu9sRdBrIV/ihdrL4o8wj00KV5Nrys XHo5p+OCfRC4i16p5ajxbxAf2TiFYVZYYO9yIM8WoJPWBEHYoCS/Vl9hmC6cKnNSqWVUWz8ETOVIVJ W78bnrei8c9Dh9izbOaQ2Z4KFRfgaSUfPvWrx8XSTZYnnYqo+R6lWMm50GeRWDni9fOP51skBdrG1U OgP2Ald1sq9qukmdPGSZ+Ezxofahtzg== X-MHO-RoutePath: aGlwcGll X-MHO-User: ce720a12-9795-11e9-a4fc-d9033e875444 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 67.177.211.60 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [67.177.211.60]) by outbound3.ore.mailhop.org (Halon) with ESMTPSA id ce720a12-9795-11e9-a4fc-d9033e875444; Tue, 25 Jun 2019 22:08:49 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id x5PM8lPF048202; Tue, 25 Jun 2019 16:08:47 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: Subject: Limiting the size of syslogd output files using options in syslog.conf From: Ian Lepore To: freebsd-embedded@freebsd.org, freebsd-hackers@freebsd.org Date: Tue, 25 Jun 2019 16:08:47 -0600 Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.5 FreeBSD GNOME Team Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 27F29816FB X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-2.99 / 15.00]; local_wl_from(0.00)[freebsd.org]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.99)[-0.985,0]; ASN(0.00)[asn:16509, ipnet:54.186.0.0/15, country:US]; NEURAL_HAM_LONG(-1.00)[-1.000,0] 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: Tue, 25 Jun 2019 22:25:05 -0000 I've posted a review of a small syslogd change which lets you set a limit on the size of syslogd output files in /etc/syslog.conf. The idea is to prevent filling up a filesystem on emmc or sdcard or other small storage device on an embedded system with unexpected logging triggered by some error or failing hardware. If you're interested, please see the review at https://reviews.freebsd.org/D20764 -- Ian From owner-freebsd-hackers@freebsd.org Tue Jun 25 23:07:09 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 4E1BA15D94B3 for ; Tue, 25 Jun 2019 23:07:09 +0000 (UTC) (envelope-from kudzu@tenebras.com) Received: from mail-qk1-x72e.google.com (mail-qk1-x72e.google.com [IPv6:2607:f8b0:4864:20::72e]) (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 2C47482800 for ; Tue, 25 Jun 2019 23:07:08 +0000 (UTC) (envelope-from kudzu@tenebras.com) Received: by mail-qk1-x72e.google.com with SMTP id s22so94687qkj.12 for ; Tue, 25 Jun 2019 16:07:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tenebras-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=kjt6kvVJSeUdqdD6RxnC2je+HannTYuOBNf0LXQnnbU=; b=1P8p+UCs0FP3ETzCEjmoth8LTXn/5uZJoS06KHpl5iwPjQyctJ5KUkqI+H2qEd9eMj 4oU2CFgn6FQvzbc9hmst+WmS7CvUQZeXtqvVfuwScubrGAnwedDUH/LIpPBqgiou2swe PIT4bGm36WRQbJko4xqvQkc+jzXcCm9jhxX62+ZZRaUFpewxDEM8T7JqlPUdSeEAhnvY NdwHB3SGNcjTIqTK9Ag37mXP39oXpidVlEaz8vWa6YllKEw6TGd6/qu6BwQFYDqonntT PfZ3Xk72o75CClDYWXhEwtYVZvl5O2unu/hDkrEGRSEQR7Ovzhhz3b8EBnvobrDsjzIv nKjQ== 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=kjt6kvVJSeUdqdD6RxnC2je+HannTYuOBNf0LXQnnbU=; b=N7MH+a8TxK6i9yss1J7oNBHmlHNQ9cn20Mn66ZGcA8sDQF+fEQEX+ORD60Jty5Pqip gfqvxg8qUKw//yOjCgLsZ6mkiezexfXn9VSnlaLISJbw/RSZk69h+itRGZLCSBEqC897 oiqL5hoKEDfkHD5NctPcCHfSz1svQfsh95ozIkDOtKdXPe0rP263wBh3CV51QS6YsHAC WxeZkgmPpDiaVDstU+RU4FZkRZ2GUwdlrj+ddW3XCglK2Yd53/SjZo9XHaDi9uNKWVV9 MuwRbQoxbt6FhI+bKM0ANOPaEHlLYu25mjCqlUkaS3Q5ODQ5Lh8285MAMbZooOdsFvJV huog== X-Gm-Message-State: APjAAAWUaXiglJnLvfZ2hLul1me3JBWVPlBTg41/u1ubqowApLzIRwd5 EOjpoF036PPsqyyjPQI+xhveSBx1WLZDAme30k0wXsAf0X0= X-Google-Smtp-Source: APXvYqwyvGf0P7x6P16tl0G3i6C276ps2PYG6fsRLCC6SdfK1F6/kfICj8xcvlalXQHXmSMGpeEwNTA+HL74yBDyD7o= X-Received: by 2002:ae9:ee17:: with SMTP id i23mr1074901qkg.399.1561504027270; Tue, 25 Jun 2019 16:07:07 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Michael Sierchio Date: Tue, 25 Jun 2019 16:06:30 -0700 Message-ID: Subject: Re: Limiting the size of syslogd output files using options in syslog.conf To: Ian Lepore Cc: freebsd-embedded@freebsd.org, freebsd-hackers@freebsd.org X-Rspamd-Queue-Id: 2C47482800 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; dkim=pass header.d=tenebras-com.20150623.gappssmtp.com header.s=20150623 header.b=1P8p+UCs X-Spamd-Result: default: False [-6.28 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[tenebras-com.20150623.gappssmtp.com:s=20150623]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; 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)[tenebras.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MX_GOOD(-0.01)[cached: alt1.aspmx.l.google.com]; DKIM_TRACE(0.00)[tenebras-com.20150623.gappssmtp.com:+]; RCVD_IN_DNSWL_NONE(0.00)[e.2.7.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.98)[-0.983,0]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; IP_SCORE(-2.99)[ip: (-9.41), ipnet: 2607:f8b0::/32(-3.14), asn: 15169(-2.33), country: US(-0.06)] X-Mailman-Approved-At: Wed, 26 Jun 2019 01:54:14 +0000 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: Tue, 25 Jun 2019 23:07:09 -0000 Apologies, but I don't understand the point of this at all. I object especially to idea of patching syslogd when EVERYTHING you seek can be accomplished with appropriate settings in /etc/newsyslog.conf and changing its entry in /etc/crontab to run more frequently. You can control the size and number of files there. You can also do remote syslog. Do you need to rotate logs more than once per minute? On Tue, Jun 25, 2019 at 3:25 PM Ian Lepore wrote: > I've posted a review of a small syslogd change which lets you set a > limit on the size of syslogd output files in /etc/syslog.conf. The > idea is to prevent filling up a filesystem on emmc or sdcard or other > small storage device on an embedded system with unexpected logging > triggered by some error or failing hardware. > > If you're interested, please see the review at > > https://reviews.freebsd.org/D20764 > > -- Ian > > _______________________________________________ > freebsd-embedded@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-embedded > To unsubscribe, send any mail to "freebsd-embedded-unsubscribe@freebsd.or= g > " > --=20 "Well," Brahm=C4=81 said, "even after ten thousand explanations, a fool is = no wiser, but an intelligent person requires only two thousand five hundred." - The Mah=C4=81bh=C4=81rata From owner-freebsd-hackers@freebsd.org Wed Jun 26 05:07:12 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 DBE7C15B34D5; Wed, 26 Jun 2019 05:07:12 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 542568D511; Wed, 26 Jun 2019 05:07:10 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (v-critter.freebsd.dk [192.168.55.3]) by phk.freebsd.dk (Postfix) with ESMTP id EC9042025698; Wed, 26 Jun 2019 05:07:02 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.15.2/8.15.2) with ESMTPS id x5Q572RL030084 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Wed, 26 Jun 2019 05:07:02 GMT (envelope-from phk@critter.freebsd.dk) Received: (from phk@localhost) by critter.freebsd.dk (8.15.2/8.15.2/Submit) id x5Q572Zk030083; Wed, 26 Jun 2019 05:07:02 GMT (envelope-from phk) To: Ian Lepore cc: freebsd-embedded@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: Limiting the size of syslogd output files using options in syslog.conf In-reply-to: From: "Poul-Henning Kamp" References: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <30081.1561525622.1@critter.freebsd.dk> Content-Transfer-Encoding: quoted-printable Date: Wed, 26 Jun 2019 05:07:02 +0000 Message-ID: <30082.1561525622@critter.freebsd.dk> X-Rspamd-Queue-Id: 542568D511 X-Spamd-Bar: +++ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [3.73 / 15.00]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_SPAM_SHORT(0.96)[0.958,0]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[freebsd.dk]; AUTH_NA(1.00)[]; TO_DN_SOME(0.00)[]; NEURAL_SPAM_MEDIUM(0.46)[0.462,0]; RCVD_COUNT_THREE(0.00)[4]; IP_SCORE(0.06)[ip: (0.11), ipnet: 130.225.0.0/16(0.06), asn: 1835(0.16), country: EU(-0.00)]; MX_GOOD(-0.01)[phk.freebsd.dk]; NEURAL_SPAM_LONG(0.96)[0.956,0]; R_SPF_NA(0.00)[]; FORGED_SENDER(0.30)[phk@phk.freebsd.dk,phk@critter.freebsd.dk]; RCVD_NO_TLS_LAST(0.10)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:1835, ipnet:130.225.0.0/16, country:EU]; FROM_NEQ_ENVFROM(0.00)[phk@phk.freebsd.dk,phk@critter.freebsd.dk] 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: Wed, 26 Jun 2019 05:07:13 -0000 -------- In message , I= an Le pore writes: >I've posted a review of a small syslogd change which lets you set a >limit on the size of syslogd output files in /etc/syslog.conf. The >idea is to prevent filling up a filesystem on emmc or sdcard or other >small storage device on an embedded system with unexpected logging >triggered by some error or failing hardware. You should consider fifolog(1) in such environments. -- = Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe = Never attribute to malice what can adequately be explained by incompetence= . From owner-freebsd-hackers@freebsd.org Wed Jun 26 14:50:10 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 719EB15CA161 for ; Wed, 26 Jun 2019 14:50:10 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1a.eu.mailhop.org (outbound1a.eu.mailhop.org [52.58.109.202]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id BDC2970AEF for ; Wed, 26 Jun 2019 14:50:09 +0000 (UTC) (envelope-from ian@freebsd.org) ARC-Seal: i=1; a=rsa-sha256; t=1561560601; cv=none; d=outbound.mailhop.org; s=arc-outbound20181012; b=Pb7LEQukgTdQGycqv9V8HIbiKaqY4Bx4Ine7VBAFDWs1uACJO44bkN78zDCVF4KnT742k0gOMbIqE LGACLVnq0RI2Wrf6CJwt32joSN0jkfI1ZizJBzd0ytyoomVu/9IFozi0cUgsH/dxN5DkZKK1IVRXN+ ZoVlsV2v7d++thki8ETVsmj/354A11ZUNEFrIs1VIRoSBi7thLu+ti3dsWBonObk3M3T7S3tj5BTyf OO0W2jwDz7SKMAo/mMILckGOrK9FDLNVi6u3+tdWDqINHtLcWYwlrU29ZzpOoaONd+x+IS5taX1Ywj ZCoN9HjRWw7LLJnLA/b7rHSSZeOVgRg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=arc-outbound20181012; h=content-transfer-encoding:mime-version:content-type:references:in-reply-to: date:cc:to:from:subject:message-id:dkim-signature:from; bh=mShiKk6bGlJpZdxfTAZKtDSSxUYY1w81EfM2mEQkUAY=; b=GCpaLpSjFi/S+B7powMn4wQRm/0BE9/Z3slJwnhlTKmYtrkgAzM45EMlOKRmrZLT4ZcYgHrRWFWbV 37+N5rIfw3DchNIQQsDvKDb6bjdLPcf8a1fpGCLIN5ZI20pUyzS91PwrvVFKbuZ4/1T0Z2ztnRGB8U iOp6wT5dqWYjRFKMHjLJLiyb3XbEXpvTpqMGxaOgfCde6hgtsp4sw54C8H6dBQI0w24GRvsbjPhOQf nIFP6JuCVUCVWVWxN92icCC+vAxVJsmlhUk5I03KHwfiyxGJHFZxe1M4rJPCEQKsXIAg+wohgr4jzv 5Kd0FGZeyFXGpKVJqcXpNhohPiAOFZg== ARC-Authentication-Results: i=1; outbound2.eu.mailhop.org; spf=softfail smtp.mailfrom=freebsd.org smtp.remote-ip=67.177.211.60; dmarc=none header.from=freebsd.org; arc=none header.oldest-pass=0; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=dkim-high; h=content-transfer-encoding:mime-version:content-type:references:in-reply-to: date:cc:to:from:subject:message-id:from; bh=mShiKk6bGlJpZdxfTAZKtDSSxUYY1w81EfM2mEQkUAY=; b=tiISJ2kQw+SP4ikJCjZ7Hyu/EtBlfgNiE2bB/Y/meuIm/94qKjoL/JE8Q3CuBd2PM4TSB46rjarZo HsnnFoSXMPPHw2htQbIyQv+1FdDcZ9J54LLwY8uHz3qNx2onL0hkA9nHmnALvWWzDNyK6dKQ50GMJu KzXX8GQ4IFv4qQh3UgqfyGUTrDQ6hiy2vGn2h4Yeubqt0NNRGA28nGpcZga4lN4FBogajQVCT1+ogi erGmYmWY5rC5ntNWcDYEDyHSjcFhmiJzmIPStlMMVA5TjCibItxpoleTnaKOCf8oFsqN8Qr7WBy171 8aMI++i14OZW+2nhAExldAk6zSDtpJA== X-MHO-RoutePath: aGlwcGll X-MHO-User: aa1e52f3-9821-11e9-bbea-3f55ba53af12 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 67.177.211.60 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [67.177.211.60]) by outbound2.eu.mailhop.org (Halon) with ESMTPSA id aa1e52f3-9821-11e9-bbea-3f55ba53af12; Wed, 26 Jun 2019 14:49:58 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id x5QEnuVK051004; Wed, 26 Jun 2019 08:49:56 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: Subject: Re: Limiting the size of syslogd output files using options in syslog.conf From: Ian Lepore To: Michael Sierchio Cc: freebsd-hackers@freebsd.org, freebsd-embedded@freebsd.org Date: Wed, 26 Jun 2019 08:49:56 -0600 In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.5 FreeBSD GNOME Team Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: BDC2970AEF X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-2.98 / 15.00]; local_wl_from(0.00)[freebsd.org]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.98)[-0.978,0]; ASN(0.00)[asn:16509, ipnet:52.58.0.0/15, country:US]; NEURAL_HAM_LONG(-1.00)[-1.000,0] 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: Wed, 26 Jun 2019 14:50:10 -0000 On Tue, 2019-06-25 at 16:06 -0700, Michael Sierchio wrote: > Apologies, but I don't understand the point of this at all. I object > especially to idea of patching syslogd when EVERYTHING you seek can > be > accomplished with appropriate settings in /etc/newsyslog.conf and > changing > its entry in /etc/crontab to run more frequently. You can control the > size > and number of files there. > > You can also do remote syslog. > > Do you need to rotate logs more than once per minute? > > Newsyslog handles expected log growth. I guess you've never had a hardware device or other problem unexpectedly trigger the writing of hundreds or thousands of lines of output per minute to syslog? It happens. You write apps that try to strike a sensible balance between logging important events and not logging so much it leads to problems, then something unexpected happens and your carefully crafted logging starts happening at 200hz and actually contributes to the problem. We've been using this code at $work since 2003; it appears in dozens of different products ranging from lab instruments to national timescale systems. People using the products experiencing such problems just want the device to keep working as best it can. They don't want repeated mysterious reboots because of things like /var filling up. (In the case of products like lab instruments, they don't really perceive the thing to be a computer running an OS at all.) And most of all, when something does go wrong and they get our support engineers to look into it, they don't want to hear "We can't figure out what happened originally to cause this problem because all the logging got rotated out of existence." Newsyslog does exactly the opposite of what you want in that situation... it purposely destroys the valuable information about the original problem while carefully preserving the useless fallout that follows. Over the years we've upstreamed every freebsd customization we've ever done at $work except this one. The only reason I've been carrying this one local mod is because it seemed too specialized to be useful to anyone else. Then yesterday someone working on an embedded-system product asked me on irc how to solve the problem of unexpected log spewage, so I offered the solution we've been using. -- Ian > > On Tue, Jun 25, 2019 at 3:25 PM Ian Lepore wrote: > > > I've posted a review of a small syslogd change which lets you set a > > limit on the size of syslogd output files in /etc/syslog.conf. The > > idea is to prevent filling up a filesystem on emmc or sdcard or > > other > > small storage device on an embedded system with unexpected logging > > triggered by some error or failing hardware. > > > > If you're interested, please see the review at > > > > https://reviews.freebsd.org/D20764 > > > > -- Ian > > > > _______________________________________________ > > freebsd-embedded@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-embedded > > To unsubscribe, send any mail to " > > freebsd-embedded-unsubscribe@freebsd.org > > " > > > > From owner-freebsd-hackers@freebsd.org Wed Jun 26 14:54:33 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 E0BEE15CA45E for ; Wed, 26 Jun 2019 14:54:32 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound2m.ore.mailhop.org (outbound2m.ore.mailhop.org [54.149.155.156]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 238BD70F4A for ; Wed, 26 Jun 2019 14:54:31 +0000 (UTC) (envelope-from ian@freebsd.org) ARC-Seal: i=1; a=rsa-sha256; t=1561560865; cv=none; d=outbound.mailhop.org; s=arc-outbound20181012; b=MCsNhefG3iLH5NGDVzFhLaLfu7jXc9Ou7SzgzmD7+wvvO2bvMSTh5fInrnSrl34P0EHdGBAQiW0Y+ XkNbHzF7VeI3gkJ5adUy107kBzmz6ZosjcdIzpxoeJvh5yqnCuMvsVNrtGNgYp1xgvDoT2d8yeP3rP VIv8GmBDRBAUHhdfs6Txbb8o6ALqCWDgu4GWT6PLpGkD8PUulygecurF+9wHhtagMbuoidTYtby8hm 6kBiRfU2FTLxbdA8tTqJBGENzLvInxdMqNJtitoaWHJZqHCUJ5AeqDVugbj9WdZHSrgzuXzyypT3vz uEf3zjLyHw8cP08d0zq9Y0paBYsW2VA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=arc-outbound20181012; h=content-transfer-encoding:mime-version:content-type:references:in-reply-to: date:cc:to:from:subject:message-id:dkim-signature:from; bh=3nL4t5dWWVna4zBaWNEvII39UnwWgBYtk1N5wXDFIWo=; b=f9G8c4OoDwEy5wnk8+y5g4IpQes9alwHgNsxsQ8ctXFKDP5P5cmP0AX+nf2y2zprDMcrDEQGNfVba V0mzXNC2C3Lp2II932jFahJeyciT+tYXcIYA+GDWqy5TTMAv/FzpfxVAQTEaAS5XRrCApjsKG824V0 TfoEJ8Pbr9fWQWC/zNR6gPK9Jusaxrg+xDT9LkHe6N9GltPWZaqFSwdUPbBU11uuZll84sH20VR3iJ ov5yOhwvzepYVd+95quPnVkKakgZ53miCbZGBPQVeDY6F6Y89brzUtCZs1M1eKI4+0/tkoJ+YMBJyj M/TD5BP4ge7jywhWP8qUhmIMQ8p8jCg== ARC-Authentication-Results: i=1; outbound4.ore.mailhop.org; spf=softfail smtp.mailfrom=freebsd.org smtp.remote-ip=67.177.211.60; dmarc=none header.from=freebsd.org; arc=none header.oldest-pass=0; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=dkim-high; h=content-transfer-encoding:mime-version:content-type:references:in-reply-to: date:cc:to:from:subject:message-id:from; bh=3nL4t5dWWVna4zBaWNEvII39UnwWgBYtk1N5wXDFIWo=; b=vBUEhpdWH4ighJPiaY0YVcdmgla1A63UjT3bdm1ckDHw0m2PprXi1F2M4ODJSJMRxeyeO6FabrBOa Gyuv4mTrEo8CLWSK2nfQR8oJD8fQT4WyI5PuqO3xKRdGgpoxyVVtk+0otLP3S/m7Q1Z0uYoydNkMoL X9BxD87oHaWQnmEdaGzJSn0yrC8Mn8NAXFq17G7N7Ha79gy9IIb6KhLP3/Vm3CT3umh9mJ3Kwamw05 mx7PKVzFK0fP1l8jfM88Alyx9YPJqsdt+fGtmIuRWv01+kQTByiNyJbMGtels4Sw9kGf6lfmfVCD3t 0u/PuJABTwFksRFNeJXf00RRp6riL/A== X-MHO-RoutePath: aGlwcGll X-MHO-User: 49388d28-9822-11e9-8d98-0b538189c249 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 67.177.211.60 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [67.177.211.60]) by outbound4.ore.mailhop.org (Halon) with ESMTPSA id 49388d28-9822-11e9-8d98-0b538189c249; Wed, 26 Jun 2019 14:54:24 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id x5QEsNN1051017; Wed, 26 Jun 2019 08:54:23 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: Subject: Re: Limiting the size of syslogd output files using options in syslog.conf From: Ian Lepore To: Poul-Henning Kamp Cc: freebsd-hackers@freebsd.org, freebsd-embedded@freebsd.org Date: Wed, 26 Jun 2019 08:54:23 -0600 In-Reply-To: <30082.1561525622@critter.freebsd.dk> References: <30082.1561525622@critter.freebsd.dk> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.5 FreeBSD GNOME Team Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 238BD70F4A X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-2.99 / 15.00]; local_wl_from(0.00)[freebsd.org]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.99)[-0.992,0]; ASN(0.00)[asn:16509, ipnet:54.148.0.0/15, country:US] 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: Wed, 26 Jun 2019 14:54:33 -0000 On Wed, 2019-06-26 at 05:07 +0000, Poul-Henning Kamp wrote: > -------- > In message < > bf597c3830ebabbef6ac422a5d648e1eed13fac5.camel@freebsd.org>, Ian Le > pore writes: > > I've posted a review of a small syslogd change which lets you set a > > limit on the size of syslogd output files in /etc/syslog.conf. The > > idea is to prevent filling up a filesystem on emmc or sdcard or > > other > > small storage device on an embedded system with unexpected logging > > triggered by some error or failing hardware. > > You should consider fifolog(1) in such environments. > > fifolog looks pretty cool and I had no idea it existed, so thanks for the pointer; I may find useful things to do with it. But for the problem of unexpected syslog spewage it has exactly the same problem as running newsyslog very frequently: by design it discards the information you most want preserved (the triggering event that led to unexpected log spewage) while carefully preserving all the following noise which is typically more about symptoms rather than causes of the problem. -- Ian From owner-freebsd-hackers@freebsd.org Wed Jun 26 15:15:38 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 DDB6215CAC2F; Wed, 26 Jun 2019 15:15:37 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from smtp-out-so.shaw.ca (smtp-out-so.shaw.ca [64.59.136.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 2A3A071AE7; Wed, 26 Jun 2019 15:15:35 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from spqr.komquats.com ([70.67.125.17]) by shaw.ca with ESMTPA id g9dxh2vO1Gusjg9dyhhqjy; Wed, 26 Jun 2019 09:15:32 -0600 X-Authority-Analysis: v=2.3 cv=fOdHIqSe c=1 sm=1 tr=0 a=VFtTW3WuZNDh6VkGe7fA3g==:117 a=VFtTW3WuZNDh6VkGe7fA3g==:17 a=jpOVt7BSZ2e4Z31A5e1TngXxSK0=:19 a=IkcTkHD0fZMA:10 a=dq6fvYVFJ5YA:10 a=6I5d2MoRAAAA:8 a=YxBL1-UpAAAA:8 a=6rM6nHsMst5jgpFo25wA:9 a=QEXdDO2ut3YA:10 a=IjZwj45LgO3ly-622nXo:22 a=Ia-lj3WSrqcvXOmTRaiG:22 Received: from android-9b917f0ce39da6e6.esitwifi.local (S0106788a207e2972.gv.shawcable.net [70.66.154.233]) by spqr.komquats.com (Postfix) with ESMTPSA id 5707541D; Wed, 26 Jun 2019 08:15:28 -0700 (PDT) Date: Wed, 26 Jun 2019 08:15:05 -0700 User-Agent: K-9 Mail for Android In-Reply-To: References: <30082.1561525622@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: Limiting the size of syslogd output files using options in syslog.conf To: freebsd-hackers@freebsd.org, Ian Lepore , Poul-Henning Kamp CC: freebsd-embedded@freebsd.org From: Cy Schubert Message-ID: <79F61714-D4EC-4A15-90AF-0E48BE684244@cschubert.com> X-CMAE-Envelope: MS4wfGWx19XwILVjfMnqA7v0iw8Kzt1APITuDSB9n3Ts2A4Uq/U0YbC4CcchZmanBLsw6sPLE7ZHz91vTJKStVOX8ziqnfCqGrqvs8rhUSN6LctsUwdv9DT1 dhW4cxx+9LdyTH3kTLeRrrXruRBSxX6vNf5GohbTUitfF/4rMUmuUUX/75+IOD1ORWSytPwb45EsPFRXEF0ZYGnT72eWWtmmBFrNX01Q/6VUS3yVNVMFQVER w+lt30DsmGnszSpdF+MCDLUc/b+oC+3+TH/lBuUAI2j+d8n5pJLGXuCUhJhj5NTp X-Rspamd-Queue-Id: 2A3A071AE7 X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-5.66 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; TO_DN_SOME(0.00)[]; IP_SCORE(-2.47)[ip: (-6.45), ipnet: 64.59.128.0/20(-3.28), asn: 6327(-2.54), country: CA(-0.09)]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MX_GOOD(-0.01)[cached: spqr.komquats.com]; NEURAL_HAM_SHORT(-0.98)[-0.979,0]; R_SPF_NA(0.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[138.136.59.64.list.dnswl.org : 127.0.5.1]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; RECEIVED_SPAMHAUS_PBL(0.00)[17.125.67.70.zen.spamhaus.org : 127.0.0.11,233.154.66.70.zen.spamhaus.org : 127.0.0.11]; ASN(0.00)[asn:6327, ipnet:64.59.128.0/20, country:CA]; MID_RHS_MATCH_FROM(0.00)[]; FROM_EQ_ENVFROM(0.00)[] 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: Wed, 26 Jun 2019 15:15:38 -0000 On June 26, 2019 7:54:23 AM PDT, Ian Lepore wrote: >On Wed, 2019-06-26 at 05:07 +0000, Poul-Henning Kamp wrote: >> -------- >> In message < >> bf597c3830ebabbef6ac422a5d648e1eed13fac5=2Ecamel@freebsd=2Eorg>, Ian Le >> pore writes: >> > I've posted a review of a small syslogd change which lets you set a >> > limit on the size of syslogd output files in /etc/syslog=2Econf=2E T= he >> > idea is to prevent filling up a filesystem on emmc or sdcard or >> > other >> > small storage device on an embedded system with unexpected logging >> > triggered by some error or failing hardware=2E >>=20 >> You should consider fifolog(1) in such environments=2E >>=20 >>=20 > >fifolog looks pretty cool and I had no idea it existed, so thanks for >the pointer; I may find useful things to do with it=2E > >But for the problem of unexpected syslog spewage it has exactly the >same problem as running newsyslog very frequently: by design it >discards the information you most want preserved (the triggering event >that led to unexpected log spewage) while carefully preserving all the >following noise which is typically more about symptoms rather than >causes of the problem=2E=20 > >-- Ian > >_______________________________________________ >freebsd-hackers@freebsd=2Eorg mailing list >https://lists=2Efreebsd=2Eorg/mailman/listinfo/freebsd-hackers >To unsubscribe, send any mail to >"freebsd-hackers-unsubscribe@freebsd=2Eorg" I suppose another knob to control the flow of syslog is ok but filling /va= r or however a person configures /var with multiple mount points, this is u= ltimately an AO problem=2E A monitor to invoke newsyslog, among other thing= s when a threshold is exceeded, whether %, free GB, or combination or slidi= ng scale, is a better job for an event handler=2E Devd is already an event = handler=2E Teaching devd and the kernel to trigger an % or GB event to subs= equently spawn a script or process to clean up, like calling newsyslog, cle= aning out /var/tmp, spool, cache, or elsewhere, let's say, a holistic appro= ach, might have broader application than a point solution=2E Just a thought=2E --=20 Pardon the typos and autocorrect, small keyboard in use=2E Cheers, Cy Schubert FreeBSD UNIX: Web: http://www=2EFreeBSD=2Eorg The need of the many outweighs the greed of the few=2E From owner-freebsd-hackers@freebsd.org Wed Jun 26 19:49:08 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 2FDE215D0651; Wed, 26 Jun 2019 19:49:08 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 234B18510B; Wed, 26 Jun 2019 19:49:06 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (localhost [127.0.0.1]) by gndrsh.dnsmgr.net (8.13.3/8.13.3) with ESMTP id x5QJn3hT055974; Wed, 26 Jun 2019 12:49:03 -0700 (PDT) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: (from freebsd-rwg@localhost) by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id x5QJn3Po055973; Wed, 26 Jun 2019 12:49:03 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201906261949.x5QJn3Po055973@gndrsh.dnsmgr.net> Subject: Re: Limiting the size of syslogd output files using options in syslog.conf In-Reply-To: To: Ian Lepore Date: Wed, 26 Jun 2019 12:49:03 -0700 (PDT) CC: Michael Sierchio , freebsd-hackers@freebsd.org, freebsd-embedded@freebsd.org X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Rspamd-Queue-Id: 234B18510B X-Spamd-Bar: ++ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [2.41 / 15.00]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; TO_DN_SOME(0.00)[]; NEURAL_SPAM_SHORT(0.87)[0.869,0]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[dnsmgr.net]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(0.19)[0.187,0]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MX_GOOD(-0.01)[cached: gndrsh.dnsmgr.net]; NEURAL_SPAM_LONG(0.42)[0.424,0]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:13868, ipnet:69.59.192.0/19, country:US]; MID_RHS_MATCH_FROM(0.00)[]; IP_SCORE(0.04)[ip: (0.14), ipnet: 69.59.192.0/19(0.07), asn: 13868(0.05), country: US(-0.06)] 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: Wed, 26 Jun 2019 19:49:08 -0000 > On Tue, 2019-06-25 at 16:06 -0700, Michael Sierchio wrote: > > Apologies, but I don't understand the point of this at all. I object > > especially to idea of patching syslogd when EVERYTHING you seek can > > be > > accomplished with appropriate settings in /etc/newsyslog.conf and > > changing > > its entry in /etc/crontab to run more frequently. You can control the > > size > > and number of files there. > > > > You can also do remote syslog. > > > > Do you need to rotate logs more than once per minute? It is not a matter of rapid log rotation it is that your rotate the very data you want out of existance that is the problem. > > Newsyslog handles expected log growth. I guess you've never had a > hardware device or other problem unexpectedly trigger the writing of > hundreds or thousands of lines of output per minute to syslog? It > happens. You write apps that try to strike a sensible balance between > logging important events and not logging so much it leads to problems, > then something unexpected happens and your carefully crafted logging > starts happening at 200hz and actually contributes to the problem. :-) Only 200hz? > We've been using this code at $work since 2003; it appears in dozens of > different products ranging from lab instruments to national timescale > systems. People using the products experiencing such problems just > want the device to keep working as best it can. They don't want > repeated mysterious reboots because of things like /var filling up. > (In the case of products like lab instruments, they don't really > perceive the thing to be a computer running an OS at all.) > > And most of all, when something does go wrong and they get our support > engineers to look into it, they don't want to hear "We can't figure out > what happened originally to cause this problem because all the logging > got rotated out of existence." Newsyslog does exactly the opposite of > what you want in that situation... it purposely destroys the valuable > information about the original problem while carefully preserving the > useless fallout that follows. Yes, and this is not only an issue on embeded, been in exactly that position trying to post diagnose server failures, all the logs had been rotated out and filled with a repeated changing sequence of error message that was a cascade effect of what had originally gone wrong. Syslog does very good with rate limiting and colapsing a single repeated line, but when it is getting 2 or more intertwined lines this no longer works. It may make an interesting project to create a coalescing buffer that holds some N messages for up to some t time and collapse them into a "Foo bar table top (repeated n times in t)" that would be a much smarter rate limiter. You toss anything from the coalesce buffer that is of some age > t if it only occured once. > Over the years we've upstreamed every freebsd customization we've ever > done at $work except this one. The only reason I've been carrying this > one local mod is because it seemed too specialized to be useful to > anyone else. Then yesterday someone working on an embedded-system > product asked me on irc how to solve the problem of unexpected log > spewage, so I offered the solution we've been using. I agree that this is a useful feature for exactly the reasons Ian sites. It is rarely the end of a fifo log that is useful, but rather some point back in time that occured before the cascade effect. This looks to be a simple, but reasonable solution to a long standing problem that is not solved in any other way. The 32k circ buffer size should probably be config file tweakable though. > -- Ian > > On Tue, Jun 25, 2019 at 3:25 PM Ian Lepore wrote: > > > > > I've posted a review of a small syslogd change which lets you set a > > > limit on the size of syslogd output files in /etc/syslog.conf. The > > > idea is to prevent filling up a filesystem on emmc or sdcard or > > > other > > > small storage device on an embedded system with unexpected logging > > > triggered by some error or failing hardware. > > > > > > If you're interested, please see the review at > > > > > > https://reviews.freebsd.org/D20764 > > > > > > -- Ian -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-hackers@freebsd.org Wed Jun 26 21:54:20 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 EB19515D322F for ; Wed, 26 Jun 2019 21:54:19 +0000 (UTC) (envelope-from kudzu@tenebras.com) Received: from mail-qt1-x82b.google.com (mail-qt1-x82b.google.com [IPv6:2607:f8b0:4864:20::82b]) (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 81BDF89906 for ; Wed, 26 Jun 2019 21:54:18 +0000 (UTC) (envelope-from kudzu@tenebras.com) Received: by mail-qt1-x82b.google.com with SMTP id p15so292112qtl.3 for ; Wed, 26 Jun 2019 14:54:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tenebras-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=8aYIJQjVjT7TohBYroHJ56nJZ8HGrQQjSPKvTE3llbc=; b=wL3Tn4JUpPlUK5LF7G1tHwr7ljgZHkZ29SblfenvYDhoZkv7wajZ0GezzlQoIe5h8F DqcDCbvaMxmuSCfvOZgd05XgxFQuQ1TUqqmCuyzzmWDAhu+ZJ8bRaLCo8yFrdf23HvkW R7qTy6HCwazDUQvqhqKHE/TdZieTiTB9WFpw1wBUEOVab5rVdoZPmVfyAQ2gv7l1h+Oz IdXcPJX8k8/H904SinsUmCgg4hPrJcU1aET0/iWQ90NWeq/H++F32BokLKudOCf4uWrs 4f82UIBExrbbfybM/lCt0wSLRN4H7YcFlhROEkvDzvSXUDn4o5yGZFpx2RHYu0eNk9eE zt/A== 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=8aYIJQjVjT7TohBYroHJ56nJZ8HGrQQjSPKvTE3llbc=; b=bCzcMxigvTMct2WBpVVWrmIpZGYRnDzWYBu8fsAdsQIzDTFVqnbh9KtUw7QmnoWhol 0iGeTELh6bKWanp+T5sBiP9j5IzYzBIseaFTzclnw/FVcbN439mu493ivBOnBPI1uMxx fVXb2qJL0vM2KwX8hx5QrXUHGdzUX+fIYmlDlJFky+jaQGAia782oR0Iicz2iaXq+m60 DDJusBayNACQXFcSyalMBHHZuoGYHbnCh76uoNOK6r7xGyjfzKK+6DAUmOS/SoSwJldB /LPFeDkURQzRZOnVpNjE16UXzW7zSrYHFQt0ob0k43xqr5ww1xv1xgqRmwLn+XdCM9Yy Q8Cw== X-Gm-Message-State: APjAAAXbR24CQFja/L+B4RXhfDMevZqotQ91CuyhgS+wnfTo+WxWLH91 mlxkYhPEN6Dj0LnKclIn7oPlP38LjOnsCsKz++V6EA== X-Google-Smtp-Source: APXvYqxbpoSfzou+nCi+NHqdwGRqwB5/QSVM/fPdWljGdeJYOKcXZ/QXstHH9EC5cI/6BQYn/EFUoCxYe3ktYI0H61c= X-Received: by 2002:ac8:3014:: with SMTP id f20mr131815qte.69.1561586057565; Wed, 26 Jun 2019 14:54:17 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Michael Sierchio Date: Wed, 26 Jun 2019 14:53:41 -0700 Message-ID: Subject: Re: Limiting the size of syslogd output files using options in syslog.conf To: Ian Lepore Cc: freebsd-hackers@freebsd.org, freebsd-embedded@freebsd.org X-Rspamd-Queue-Id: 81BDF89906 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; dkim=pass header.d=tenebras-com.20150623.gappssmtp.com header.s=20150623 header.b=wL3Tn4JU X-Spamd-Result: default: False [-6.26 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[tenebras-com.20150623.gappssmtp.com:s=20150623]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; 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)[tenebras.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[tenebras-com.20150623.gappssmtp.com:+]; MX_GOOD(-0.01)[alt1.aspmx.l.google.com,aspmx.l.google.com,aspmx2.googlemail.com,alt2.aspmx.l.google.com,aspmx3.googlemail.com]; RCVD_IN_DNSWL_NONE(0.00)[b.2.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.96)[-0.958,0]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; IP_SCORE(-2.99)[ip: (-9.42), ipnet: 2607:f8b0::/32(-3.14), asn: 15169(-2.34), country: US(-0.06)] X-Mailman-Approved-At: Wed, 26 Jun 2019 23:15:30 +0000 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: Wed, 26 Jun 2019 21:54:20 -0000 You can pipe any syslog facility to a program. My /etc/syslog.conf has auth.*;authpriv.* |/usr/local/bin/authlog because I do some processing, but also rate-limiting and alerting, before writing to /var/log/auth.log You could just as easily write auth.*;authpriv.* | fifolog_writer /var/log/auth.fifolog Again, I object to modifying syslogd to add a feature that already exists in the modular framework of pipes and utilities and specialized tools like fifolog. =E2=80=93 M On Wed, Jun 26, 2019 at 7:50 AM Ian Lepore wrote: > On Tue, 2019-06-25 at 16:06 -0700, Michael Sierchio wrote: > > Apologies, but I don't understand the point of this at all. I object > > especially to idea of patching syslogd when EVERYTHING you seek can > > be > > accomplished with appropriate settings in /etc/newsyslog.conf and > > changing > > its entry in /etc/crontab to run more frequently. You can control the > > size > > and number of files there. > > > > You can also do remote syslog. > > > > Do you need to rotate logs more than once per minute? > > > > > > Newsyslog handles expected log growth. I guess you've never had a > hardware device or other problem unexpectedly trigger the writing of > hundreds or thousands of lines of output per minute to syslog? It > happens. You write apps that try to strike a sensible balance between > logging important events and not logging so much it leads to problems, > then something unexpected happens and your carefully crafted logging > starts happening at 200hz and actually contributes to the problem. > > We've been using this code at $work since 2003; it appears in dozens of > different products ranging from lab instruments to national timescale > systems. People using the products experiencing such problems just > want the device to keep working as best it can. They don't want > repeated mysterious reboots because of things like /var filling up. > (In the case of products like lab instruments, they don't really > perceive the thing to be a computer running an OS at all.) > > And most of all, when something does go wrong and they get our support > engineers to look into it, they don't want to hear "We can't figure out > what happened originally to cause this problem because all the logging > got rotated out of existence." Newsyslog does exactly the opposite of > what you want in that situation... it purposely destroys the valuable > information about the original problem while carefully preserving the > useless fallout that follows. > > Over the years we've upstreamed every freebsd customization we've ever > done at $work except this one. The only reason I've been carrying this > one local mod is because it seemed too specialized to be useful to > anyone else. Then yesterday someone working on an embedded-system > product asked me on irc how to solve the problem of unexpected log > spewage, so I offered the solution we've been using. > > -- Ian > > > > > On Tue, Jun 25, 2019 at 3:25 PM Ian Lepore wrote: > > > > > I've posted a review of a small syslogd change which lets you set a > > > limit on the size of syslogd output files in /etc/syslog.conf. The > > > idea is to prevent filling up a filesystem on emmc or sdcard or > > > other > > > small storage device on an embedded system with unexpected logging > > > triggered by some error or failing hardware. > > > > > > If you're interested, please see the review at > > > > > > https://reviews.freebsd.org/D20764 > > > > > > -- Ian > > > > > > _______________________________________________ > > > freebsd-embedded@freebsd.org mailing list > > > https://lists.freebsd.org/mailman/listinfo/freebsd-embedded > > > To unsubscribe, send any mail to " > > > freebsd-embedded-unsubscribe@freebsd.org > > > " > > > > > > > > > --=20 "Well," Brahm=C4=81 said, "even after ten thousand explanations, a fool is = no wiser, but an intelligent person requires only two thousand five hundred." - The Mah=C4=81bh=C4=81rata From owner-freebsd-hackers@freebsd.org Thu Jun 27 00:45:20 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 96CF715D63B4 for ; Thu, 27 Jun 2019 00:45:20 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-io1-xd33.google.com (mail-io1-xd33.google.com [IPv6:2607:f8b0:4864:20::d33]) (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 A6FB48E5F4; Thu, 27 Jun 2019 00:45:19 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mail-io1-xd33.google.com with SMTP id r185so898986iod.6; Wed, 26 Jun 2019 17:45:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=p0Utk0iWJmN7wGE4iUGfqdM0e+4KevxLcNF6XpECrY4=; b=o4VYQdQL7cDwFgT/+8RhrsKzzVFqJREdf9jHiIJ4OTS8l2yt5xyqDQjEXKt0hBzkYZ chJJ0zbo9/WVT142aed4j46FrOWstjbwpKSOoGE+csMthutjNBKBK5kacvt9jH9smlpH 4H2SrPVU25H0q3lyxDqLF6rJceRZXjddsCweRRsLnqM5lYxhNLEaAyfXGKKHpt2WdyOI shVj2RyBDdAlxe5AwZageIGOCOedRJQ7v3w6OjHiyMID9NruB1QmKEPtK06x4gzpv3/3 e6dsTTto/YtsFVWGDg+zEhGLPz/6oZSkG6mDFO5tpNZOYFCS93uiWsCNETnvVBMcQXFl UkQA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to:user-agent; bh=p0Utk0iWJmN7wGE4iUGfqdM0e+4KevxLcNF6XpECrY4=; b=nB6Sl9Tmk3v5CXPzpvFypc1r+6V7uOwOpGybPX3LDkKH+lDa1rNqpIkAVP4jyyopIR XXeBd2yU2JSp4rbmVTRYzvSzUyKG3FiRQnrZikOrgM7A86dgmLpvang1SjaKrinoR9Cc mIOU2nrGnzDD4B6Nfofg5FmEGI2vUIFQ1NxWWh87GQX/OmNK1t29h9Jzsu2G7tiT8Gde TNO5e6ujsfpvHJJ9wIGWtIbDBP1XCnDgaFqrUyPANcQVot8UoIkU2p50Pe/oSMOQXEqt JBJyj9lpLYRc7Edq1DpJeW+1ufne8XNHy4u4AE99eeEXYgDjGuodtT4RV3krx9HJN0zw HBiQ== X-Gm-Message-State: APjAAAUfvXHZoyph7bHaa2w5j+/+B3yPKKX1VK+9WBuVsAZPLBvfGrIp dQHskmzBP+S6V0o3zXw1CM4RJ7tn X-Google-Smtp-Source: APXvYqyVPNdoxbSG3OzFWoJPxtQz9AwM4IdvDyzeDxHnkKYOZ04XulvUKVNlu1Ji6wHSOx/bRrejSw== X-Received: by 2002:a6b:3b03:: with SMTP id i3mr1288600ioa.302.1561596318465; Wed, 26 Jun 2019 17:45:18 -0700 (PDT) Received: from raichu (toroon0560w-lp140-05-70-29-85-38.dsl.bell.ca. [70.29.85.38]) by smtp.gmail.com with ESMTPSA id v26sm397714iom.88.2019.06.26.17.45.17 (version=TLS1_3 cipher=AEAD-AES256-GCM-SHA384 bits=256/256); Wed, 26 Jun 2019 17:45:17 -0700 (PDT) Sender: Mark Johnston Date: Wed, 26 Jun 2019 20:45:15 -0400 From: Mark Johnston To: freebsd-hackers@freebsd.org Cc: re@freebsd.org Subject: Re: release notes file Message-ID: <20190627004515.GB73130@raichu> References: <20190623191818.GA84365@raichu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190623191818.GA84365@raichu> User-Agent: Mutt/1.12.0 (2019-05-25) X-Rspamd-Queue-Id: A6FB48E5F4 X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=o4VYQdQL; spf=pass (mx1.freebsd.org: domain of markjdb@gmail.com designates 2607:f8b0:4864:20::d33 as permitted sender) smtp.mailfrom=markjdb@gmail.com X-Spamd-Result: default: False [-5.45 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[freebsd.org]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; RCVD_COUNT_THREE(0.00)[3]; RCVD_TLS_LAST(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[3.3.d.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]; MX_GOOD(-0.01)[cached: alt3.gmail-smtp-in.l.google.com]; NEURAL_HAM_SHORT(-0.99)[-0.993,0]; IP_SCORE(-2.74)[ip: (-8.18), ipnet: 2607:f8b0::/32(-3.14), asn: 15169(-2.34), country: US(-0.06)]; FORGED_SENDER(0.30)[markj@freebsd.org,markjdb@gmail.com]; MIME_TRACE(0.00)[0:+]; MID_RHS_NOT_FQDN(0.50)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[markj@freebsd.org,markjdb@gmail.com] 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: Thu, 27 Jun 2019 00:45:20 -0000 On Sun, Jun 23, 2019 at 03:18:18PM -0400, 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. To be clear, my aim here is to help ensure that new features are documented close to when they are committed. Today, release notes are compiled only shortly before a release, which means that re@ has to go through all of the new commits looking for relnotes tags and hope that they didn't miss anything. A RELNOTES file helps prevent things from falling through the cracks and reduces the amount of work required of re@. > 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? To summarize what I think are the important points from the discussion that ensued: - RELNOTES would be useful. In other words, I didn't see any opposition to the idea. - It's not clear when and how RELNOTES should be truncated. Since this is really an re@ policy question, it doesn't block RELNOTES from being added to the tree. So, I will ignore this issue and let them figure it out once we actually come up to the next release and have some experience. - It's not clear how best to handle MFCs of RELNOTES. I will propose that we simply not MFC RELNOTES for now: given head's copy of RELNOTES, one can easily determine whether any of the referenced revisions are in a stable branch. - RELNOTES should be easy to parse. - RELNOTES is not intended to be presented directly to users; it is a log that can be used to generate user-friendlier documentation. So, it will not be installed and entries should be in plain text. - (Not actually discussed, but my own thoughts:) There is some overlap with UPDATING; some things that I would consider release notes are documented there. As I understand it, the goal of UPDATING is to document changes that may trip up users who build from source: KBI changes, renames, removals, and so on. RELNOTES is for users of binary FreeBSD releases. So, there may be some overlap, but in general I think we should avoid using UPDATING to document routine changes like contrib/ updates. I put a proposed initial version here: https://reviews.freebsd.org/D20762 From owner-freebsd-hackers@freebsd.org Thu Jun 27 02:10:21 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 09B6815D7BF6 for ; Thu, 27 Jun 2019 02:10:21 +0000 (UTC) (envelope-from gjb@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [96.47.72.132]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A414169ACC; Thu, 27 Jun 2019 02:10:20 +0000 (UTC) (envelope-from gjb@freebsd.org) Received: from FreeBSD.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by freefall.freebsd.org (Postfix) with ESMTPS id 271FA1154F; Thu, 27 Jun 2019 02:10:20 +0000 (UTC) (envelope-from gjb@freebsd.org) Date: Thu, 27 Jun 2019 02:10:17 +0000 From: Glen Barber To: Mark Johnston Cc: freebsd-hackers@freebsd.org, re@freebsd.org Subject: Re: release notes file Message-ID: <20190627021017.GY13146@FreeBSD.org> References: <20190623191818.GA84365@raichu> <20190627004515.GB73130@raichu> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="M/v0iXgzSsdULkoO" Content-Disposition: inline In-Reply-To: <20190627004515.GB73130@raichu> User-Agent: Mutt/1.11.2 (2019-01-07) X-Rspamd-Queue-Id: A414169ACC X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-2.84 / 15.00]; local_wl_from(0.00)[freebsd.org]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; NEURAL_HAM_SHORT(-0.84)[-0.842,0]; ASN(0.00)[asn:11403, ipnet:96.47.64.0/20, country:US]; NEURAL_HAM_LONG(-1.00)[-1.000,0] 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: Thu, 27 Jun 2019 02:10:21 -0000 --M/v0iXgzSsdULkoO Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jun 26, 2019 at 08:45:15PM -0400, Mark Johnston wrote: > On Sun, Jun 23, 2019 at 03:18:18PM -0400, Mark Johnston wrote: > > Hi, > >=20 > > 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. >=20 > To be clear, my aim here is to help ensure that new features are > documented close to when they are committed. Today, release notes are > compiled only shortly before a release, which means that re@ has to go > through all of the new commits looking for relnotes tags and hope that > they didn't miss anything. A RELNOTES file helps prevent things from > falling through the cracks and reduces the amount of work required of > re@. >=20 > > For example: > >=20 > > Index: RELNOTES > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > --- 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. > >=20 > > What do folks think? >=20 > To summarize what I think are the important points from the discussion > that ensued: >=20 > - RELNOTES would be useful. In other words, I didn't see any > opposition to the idea. I did not see opposition either. > - It's not clear when and how RELNOTES should be truncated. Since this > is really an re@ policy question, it doesn't block RELNOTES from > being added to the tree. So, I will ignore this issue and let them > figure it out once we actually come up to the next release and have > some experience. Here is my view of the world in this regard. Release notes between X.Y-1 and X.Y should be differences between X.Y-1 and X.Y. Major version releases are trickier, because there's the open-ended question of "against what release do we compare the release notes?" To be honest, I still do not have a good metric upon which to base the latter, but just throwing it at the wall to see what sticks. > - It's not clear how best to handle MFCs of RELNOTES. I will propose > that we simply not MFC RELNOTES for now: given head's copy of > RELNOTES, one can easily determine whether any of the referenced > revisions are in a stable branch. For 12.0 and later, release notes files (the XML files) exist in the doc tree. For 11.x and earlier, they exist in src, but since I have been personally involved in release notes for the past 12 or so releases, I have never done an MFC from head to stable for the release/doc directory. It does indeed cause merge conflicts, and more importantly, the revision numbers associated with the commit are wrong unless manually fixed. My $0.02 USD is to commit to the file on head and stable branches directly, and *never* do an MFC to the RELNOTES file. It is, in my experience, just not worth dealing with the conflicts. > - RELNOTES should be easy to parse. This is why I am in preference of a plain-text file, wrapped at 80 characters. I do not necessarily care about nonexistent parsing capabilities in other software at the moment. > - RELNOTES is not intended to be presented directly to users; it is a > log that can be used to generate user-friendlier documentation. So, > it will not be installed and entries should be in plain text. Yes. (See previous comment.) > - (Not actually discussed, but my own thoughts:) There is some overlap > with UPDATING; some things that I would consider release notes are > documented there. As I understand it, the goal of UPDATING is to > document changes that may trip up users who build from source: KBI > changes, renames, removals, and so on. RELNOTES is for users of > binary FreeBSD releases. So, there may be some overlap, but in > general I think we should avoid using UPDATING to document routine > changes like contrib/ updates. >=20 100% agreed. Furthermore, the RELNOTES file can replace things like "rNNNNNN: Updated Clang (and friends) to upstream 7.0.1." easily with "rNNNNNN: Updated Clang (and friends) to upstream 8.0.0." That, in particular, eliminates some of the relnotes.xml reordering (based on revision numbers for ease, no other particular reason) when for example OpenSSL gets bumped mid-cycle. Glen --M/v0iXgzSsdULkoO Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEjRJAPC5sqwhs9k2jAxRYpUeP4pMFAl0UJYkACgkQAxRYpUeP 4pOsUxAAmreejP4UNQFlu7IxoY95r70J056MBGr299u3MR1+eyL5DPE+kLDmNLck 8vwnMZbCXReP4bvzRJ1O9jW3hDphLm1ubHAc5m/Diym6okBc4uaeP7pugWP6q4vL VdpeEBu5edxQ0b77a3/x2ExgoDVaRr024mF7cFNkfBSJDhxSA5zF7HQSgmzF4QPG NWnt1WKpfqNjUzsdk6Cn+eHR4JGmoVNaDIDPf+bPcuW0/D3yvDFscx6frGi64zEk set/L2ruKYGCa4E1ivcABMG6+7VPh1Df+cGb++6hHuaJm9ANE/Tmi6n6ZHAleELN gF6HNgb8yznIWnDke7e7fdPf3shi5BCIk427+Qcx8PB/FlvAkUwV2lc3Ur3kpDRU HHFdOGmE+vm7Z5OYSywnDewgEW2iXYmvZgVPAzmH2slIXvDvvl+s32eCYRXSAWhe MrJY5MVbr4QoG+hWECEE534exydNFv20KA48hQulwRRHgybXZafaNo6TkjZkSihb xkFECtBmEfPaKgTJNRmmn0Y9MO+JJTy9nhS55BXPc4CHiP71+O6rQbCOEGewlouG 9Dr1ZyNv/zaQKWuoojtOB1QlAHailBeCPUzNHWT5pQhqoOiIgJZt3fZHEe1bLVm6 wXEI+XNMRFMTBToZmR7IFuUNbHhj7eJwAn1WP2eKQz5C7nuzOKw= =6Urf -----END PGP SIGNATURE----- --M/v0iXgzSsdULkoO-- From owner-freebsd-hackers@freebsd.org Thu Jun 27 10:37:24 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 06C9C15B43DA; Thu, 27 Jun 2019 10:37:24 +0000 (UTC) (envelope-from shreyankfbsd@gmail.com) Received: from mail-yb1-xb32.google.com (mail-yb1-xb32.google.com [IPv6:2607:f8b0:4864:20::b32]) (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 E9B5977DDF; Thu, 27 Jun 2019 10:37:22 +0000 (UTC) (envelope-from shreyankfbsd@gmail.com) Received: by mail-yb1-xb32.google.com with SMTP id l10so1270946ybj.5; Thu, 27 Jun 2019 03:37:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=q4ZnpNjBXao5Wl/i+kTCXUK2ZIoOlQ3+7DHAqPeq93M=; b=C0K5X1M2TqNX6DJfRcspN8BlQkoAxDOqpasrVz00td3PTCGI9Ym1Fydop4ObCEJ4U/ iGegYyj+/tSLHTOB5q44Iow4eORx/CWOmbzy8zowF8tPHeYL+TejhwLJSoAvyD/oX0Hi OXFAAFX8F0AsAGbzNLNwjPBG15sWHjLoVZPIiRmclAWXzEKLejlxzLE+aQBinGrqYPXD DekocAaZp8Oc0A1d7smpGyVh1R7C3WgZXX5Pk8RoIRZsvF0SThsU0SQTV+I3S3BDQPbg erXMPafT09M6/Fbf+98kqBN4htBpEWIHKOZ0P3dyGU43Ltmfbavg6VYl1SFdfw6XdTM2 NaoQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=q4ZnpNjBXao5Wl/i+kTCXUK2ZIoOlQ3+7DHAqPeq93M=; b=F8vcGlbnD25brmTRg/kIzpb5XatewD4NOGJg9FnCpzsHB3rty4oiXOtzqUh/2eDrqZ M13tXxEMXWQjrYucMN4P/i70+RmzZl5QAYKCOBIQK2NP+kqFI/FuUgPlPPtVBiAmWU2d 7sXJ1ISTjm0N2sUwIDPufI7nz+ZCVp7tIuOWnSzZHhwHmH6aBk5s6yirps+jcseqRI4x j7rqdgtwW9DgQ5Tef1GsoFzo0roJn7KPuI/odYXvLzchnAH/o82ULYCGW8s53zsMWvXI XDHdtqiXn63gDEgopbzI2MCGZh5zxjkPUtZBBGuDp8QCeYVhay3hMTMkoJifgrnqTi5U YavQ== X-Gm-Message-State: APjAAAXqRbkTKjGcSM6CgC7gTEZoOcl4cHTqjND2QCkixJnFR+FWcvhT jfhwbsIjpFDZctnXRBPio/CtEEJg2vPvJCDyc2EtNVU= X-Google-Smtp-Source: APXvYqzI8W88iidDYXUJvtatUBa7iJRIjkWCPrKXZInS3EMKP9lYHrHpdm9+AnAsnf8lETh9xDdPyfChHLspWPxLTrA= X-Received: by 2002:a25:12c4:: with SMTP id 187mr2104310ybs.388.1561631842036; Thu, 27 Jun 2019 03:37:22 -0700 (PDT) MIME-Version: 1.0 From: shreyank amartya Date: Thu, 27 Jun 2019 16:07:10 +0530 Message-ID: Subject: PTP Support FreeBSD To: freebsd-drivers@freebsd.org Cc: freebsd-hackers@freebsd.org X-Rspamd-Queue-Id: E9B5977DDF X-Spamd-Bar: ------- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=C0K5X1M2; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of shreyankfbsd@gmail.com designates 2607:f8b0:4864:20::b32 as permitted sender) smtp.mailfrom=shreyankfbsd@gmail.com X-Spamd-Result: default: False [-7.01 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; TO_DN_NONE(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_TLS_LAST(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; MX_GOOD(-0.01)[cached: alt3.gmail-smtp-in.l.google.com]; RCVD_IN_DNSWL_NONE(0.00)[2.3.b.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.95)[-0.952,0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; IP_SCORE(-3.05)[ip: (-9.71), ipnet: 2607:f8b0::/32(-3.14), asn: 15169(-2.34), country: US(-0.06)]; DWL_DNSWL_NONE(0.00)[gmail.com.dwl.dnswl.org : 127.0.5.0] Content-Type: text/plain; charset="UTF-8" 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: Thu, 27 Jun 2019 10:37:24 -0000 Hi, For amd xGBE driver, I was planning on adding PTP but seems like there is missing support from kernel after reading this thread from sometime ago: https://lists.freebsd.org/pipermail/freebsd-net/2015-February/041279.html After going over the linux PTP driver, seems to me there is a missing posix clock/timer interface in FreeBSD, which the Linux ptp river utilizes. Is that all whats needed to make ptp work on FreeBSD? I'm trying to estimate the work here and would like to try and and add support for PTP. Thanks Shreyank Amartya From owner-freebsd-hackers@freebsd.org Thu Jun 27 18:03:02 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 02D4915C8FE1 for ; Thu, 27 Jun 2019 18:03:01 +0000 (UTC) (envelope-from luthramihir708@gmail.com) Received: from mail-ua1-x934.google.com (mail-ua1-x934.google.com [IPv6:2607:f8b0:4864:20::934]) (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 0B22868304 for ; Thu, 27 Jun 2019 18:03:01 +0000 (UTC) (envelope-from luthramihir708@gmail.com) Received: by mail-ua1-x934.google.com with SMTP id f20so1198060ual.0 for ; Thu, 27 Jun 2019 11:03:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=9q/7JQEmc0+UWl8A0sTJRzzCLP7VgIuzUzM75q7ukxg=; b=e4Z6hEs1AB+BpmR3OwGJrX+jThjuBdb5/KCVp0+LlTpXKzf+K6Tj+Q6gFgz1OUXlJj vGPRfG6a9xuT2HfFgAKdf/y614/4upIK63sR3TTo8uYaiF2Y3BdMjL/6TjASjZGjFe8U 9Fw+r4LyRyhtOmKZVkI4jM55qIs6MYGpHPS2wkxMghQohxETROuGtwQaaDyLdpcNlp1d OhueNebnZtGIhpq7BkSPLdxFXQphDJFjmBvIxSqkpMFxlYJPzZATA3zeSh8fluSSK4x4 q1picvFlIhwgPMUJ4p5lX748n0fUOjFKBm/aJ4uoSJM5A5+m/dzH9hpVAroAeWJt44wh a1UQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=9q/7JQEmc0+UWl8A0sTJRzzCLP7VgIuzUzM75q7ukxg=; b=oW24sWxzspQWR3cTUIRzYLVhbLA0FnSxoY6QH0O6Vtxn5Gkm5JRiGXQh0zRn1wYKqE c6WQJPfEYCpNqNswK0oPCKGrowoVnJB3Ma3l3SOVwAdBvZ4RqQVwZtQe2fS5K65lni/6 mjdI9ZGAcfxDnzJIG8o4IJYR+isRJwNh8pZuf9I//iRC/GzOJzo2J5d41RETUQe5MYu2 m2AEeNNWcppb+2K+Lvztp4wcI8tSxUpml9TfNq/OXPcCABGIXnsuNGnrAhDN4FT5+oA9 7m3ux1yqO4TIkvHl/Mew+Q327rwGlaD6t9kYqk60LjCPnaZ2elE6svWNzWMUUn2DONyb mCug== X-Gm-Message-State: APjAAAUqMw79RLAt1Ifn77vVKZUSa19345Nc0hIyArBL8n5+BhdQdPZN eaUj+aUpsZVpnSGo5Rg71yEi+d9C7PMkXZzU9++kBgrZFKQ= X-Google-Smtp-Source: APXvYqwY/INktOg9QAca1madruN17jN47USjpqjEJkMSAuuE39l6fo/7zG2u74vrb9uLBg7bdh6jSvj7oPcgEZnQYd0= X-Received: by 2002:ab0:2bc6:: with SMTP id s6mr3214671uar.86.1561658579922; Thu, 27 Jun 2019 11:02:59 -0700 (PDT) MIME-Version: 1.0 From: Mihir Luthra Date: Thu, 27 Jun 2019 23:32:48 +0530 Message-ID: Subject: interested in contributing to FreeBSD projects To: freebsd-hackers@freebsd.org X-Rspamd-Queue-Id: 0B22868304 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=e4Z6hEs1; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of luthramihir708@gmail.com designates 2607:f8b0:4864:20::934 as permitted sender) smtp.mailfrom=luthramihir708@gmail.com X-Spamd-Result: default: False [-4.93 / 15.00]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; FREEMAIL_FROM(0.00)[gmail.com]; TO_DN_NONE(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; MX_GOOD(-0.01)[cached: alt3.gmail-smtp-in.l.google.com]; NEURAL_HAM_SHORT(-0.91)[-0.914,0]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+,1:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; DWL_DNSWL_NONE(0.00)[gmail.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(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]; RCPT_COUNT_ONE(0.00)[1]; INTRODUCTION(2.00)[]; RCVD_IN_DNSWL_NONE(0.00)[4.3.9.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]; IP_SCORE(-3.00)[ip: (-9.48), ipnet: 2607:f8b0::/32(-3.14), asn: 15169(-2.34), country: US(-0.06)]; RCVD_COUNT_TWO(0.00)[2] Content-Type: text/plain; charset="UTF-8" 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: Thu, 27 Jun 2019 18:03:02 -0000 Hi everyone, My name is Mihir. I am an engineering student, currently in my 5th semester. It has been my wish to be a part of an open source community. Surfing through the net, I was attracted to this community. Further I went through some GSoC projects [1] that were on the site. I am interested in pursuing one of them. Will it be okay if I work on some project that has not been taken? If yes, can someone suggest me one? I am skilled mainly in C and somewhat in shells too. [1] https://wiki.freebsd.org/SummerOfCodeIdeas Thanks, Mihir From owner-freebsd-hackers@freebsd.org Thu Jun 27 18:34:55 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 345DE15C9A74 for ; Thu, 27 Jun 2019 18:34:55 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-lj1-f179.google.com (mail-lj1-f179.google.com [209.85.208.179]) (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 45D256A9EF for ; Thu, 27 Jun 2019 18:34:52 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-lj1-f179.google.com with SMTP id m23so3354296lje.12 for ; Thu, 27 Jun 2019 11:34:52 -0700 (PDT) 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=yxmA/9u3Pk9OfPrz2Lru0IQYDbCJHYSLh+n3Tf2sazI=; b=rUn6xvGAaxvPBjrsJP20K7DO8jU8YVzE13XDoNbgtJZfVi2Be+xb5h5hFpAp6cAX76 arT8jAldIIyTGDIJVCldn8Uj6N0m/aNbw/aDXOlNXA6uRfpWqN/XZT1CT+juCWKz5w8p eDgD4OO5xd0+BpX1KKzbhA7Yu19R+kZxAaQuMtJ1swOSD3ccqHSpsgaKjRw0i8y3z/g8 c/fcueijhCgBsmYJDdDYC2vajX6YdGGv0J2G3rGtzFBSMbgquePK7x6tHVW5+Lh/Ziul zNZexxoseDq1iTpa9KnhvqvwooZi0/Zxy9tcsAW8OLviQhiZmxLWYjTzUghP8L6s1KyO hj+g== X-Gm-Message-State: APjAAAWV7BdlLXoFlDnlSCsnBpJwLqEibInSwmCAXZKjuZs3reG9q7lj oXng/YWrJAhI+YfKuj40fh9fBYWttTz9m2ID2zlQe09V X-Google-Smtp-Source: APXvYqziAwPDRq9eT6OnhCCB9bBWUwzkwGXJlu7097+ZyPf5fg2t2mJEB6vANbsC64rznupL+SkbWZcZhzOQVuc/isw= X-Received: by 2002:a2e:6e0c:: with SMTP id j12mr3460740ljc.123.1561659034856; Thu, 27 Jun 2019 11:10:34 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Alan Somers Date: Thu, 27 Jun 2019 12:10:23 -0600 Message-ID: Subject: Re: interested in contributing to FreeBSD projects To: Mihir Luthra Cc: "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 45D256A9EF X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; spf=pass (mx1.freebsd.org: domain of asomers@gmail.com designates 209.85.208.179 as permitted sender) smtp.mailfrom=asomers@gmail.com X-Spamd-Result: default: False [-2.21 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; IP_SCORE(-1.28)[ip: (-0.58), ipnet: 209.85.128.0/17(-3.44), asn: 15169(-2.33), country: US(-0.06)]; MX_GOOD(-0.01)[cached: alt3.gmail-smtp-in.l.google.com]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-0.95)[-0.951,0]; FORGED_SENDER(0.30)[asomers@freebsd.org,asomers@gmail.com]; FREEMAIL_TO(0.00)[gmail.com]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FROM_NEQ_ENVFROM(0.00)[asomers@freebsd.org,asomers@gmail.com]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.97)[-0.970,0]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-0.997,0]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DMARC_NA(0.00)[freebsd.org]; MIME_TRACE(0.00)[0:+]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[179.208.85.209.list.dnswl.org : 127.0.5.0]; RCVD_TLS_LAST(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; INTRODUCTION(2.00)[] 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: Thu, 27 Jun 2019 18:34:55 -0000 On Thu, Jun 27, 2019 at 12:03 PM Mihir Luthra wrote: > > Hi everyone, > > My name is Mihir. I am an engineering student, currently in my 5th > semester. It has been my wish to be a part of an open source community. > Surfing through the net, I was attracted to this community. Further I went > through some GSoC projects [1] that were on the site. I am interested in > pursuing one of them. Will it be okay if I work on some project that has > not been taken? If yes, can someone suggest me one? I am skilled mainly in > C and somewhat in shells too. > > [1] https://wiki.freebsd.org/SummerOfCodeIdeas > > Thanks, > Mihir Welcome, Mihir! Unfortunately, it's too late to officially apply for a GSoC scholarship this year. However, you're always welcome to hack around on your own time. Feel free to peruse that list, and check https://wiki.freebsd.org/SummerOfCode2019Projects to see what's taken. This list is a good place to ask for help. -Alan From owner-freebsd-hackers@freebsd.org Thu Jun 27 19:49:03 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 DA19815CB7CE for ; Thu, 27 Jun 2019 19:49:02 +0000 (UTC) (envelope-from luthramihir708@gmail.com) Received: from mail-vs1-xe2b.google.com (mail-vs1-xe2b.google.com [IPv6:2607:f8b0:4864:20::e2b]) (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 F01CA6D139; Thu, 27 Jun 2019 19:49:01 +0000 (UTC) (envelope-from luthramihir708@gmail.com) Received: by mail-vs1-xe2b.google.com with SMTP id 2so2444847vso.8; Thu, 27 Jun 2019 12:49:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=kr28n6Zer/fQ/usCjKReU00w6qDOOQkPBE5Db66BUb4=; b=KlRL0VnLequq67tu/+xhHC02/RDeZAaNa7r5FDNsqQBisqqvfp1m7GyxmOZjBunosc TMk3GBfYWvHgYTOGP1it+OoQoqG97ujjeJpl4K80B7hXrTuj8qZo34xQxmCC604xy4GN 45f9zKpDDSb32Dw43XQD7YS6R7+rDvygV/mJJ/iYpc+MLXbUh5ojfCHcpnhYTUOE2tzJ btXdLuijZ/DtM7ymUhx87emNTw7TkL+O9wmJRxACW1SjmxQrT2W71x0r/KmHn7UySYY9 SI6eDOz8eoiXh1VMGJ7Z+wyO401cF7OHifl8DJtN6dMoWaYlKk06NWnWkqsFUu8BHBKA mWCQ== 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=kr28n6Zer/fQ/usCjKReU00w6qDOOQkPBE5Db66BUb4=; b=NM9Xv/CkjoyZPuM22+5tMmItsH6sqI7blOLnr+grf8978L4aD4tHreEzUswNUmudqo M/mp3J/iPJJOS6UWC2SNeZpiRYu3T/ytNmFcFgYJXHfe4YT01bosKWmeo/QnHfnCuuJd cmK2abkdVxTTgZfWpk9p56hOlE7N/UAypqm1g7kUqBBAMtb6bSuN+QdaLmeZnGBmllZl YWIEPBPyTCM2AEo+o91c51g5Z1NwSC2Pzmwt2oPIdbXFwZYIwQAWEmw4HUIldgq/Gnnf 2S/CZjO7syNEjga3w+zih2VQQxj2ivTplpwiV/Cd/Sx0++GtLcnhxvR2+U/QS2EeIOte B1Xw== X-Gm-Message-State: APjAAAWZ38oWHZUTruWQwD4biK2DUS2bnvpZBVrZNKmVHqhaiysfMBIE IlNPuW1ezvIIyyinqbUTMLQhwvO0ueBl/geBwiLfdxplt0U= X-Google-Smtp-Source: APXvYqyellAjhDvcvaYjto5r8PE0el2FR2Nuiis86SgNc7583qXswRin3MIkqEYM8g8/BdrqdofFAIZ9Qd0ItblnGEY= X-Received: by 2002:a67:f713:: with SMTP id m19mr3639934vso.183.1561664941087; Thu, 27 Jun 2019 12:49:01 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Mihir Luthra Date: Fri, 28 Jun 2019 01:18:50 +0530 Message-ID: Subject: Re: interested in contributing to FreeBSD projects To: Alan Somers Cc: "freebsd-hackers@freebsd.org" X-Rspamd-Queue-Id: F01CA6D139 X-Spamd-Bar: ------- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=KlRL0VnL; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of luthramihir708@gmail.com designates 2607:f8b0:4864:20::e2b as permitted sender) smtp.mailfrom=luthramihir708@gmail.com X-Spamd-Result: default: False [-7.03 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; RCVD_TLS_LAST(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; MX_GOOD(-0.01)[cached: alt3.gmail-smtp-in.l.google.com]; RCVD_IN_DNSWL_NONE(0.00)[b.2.e.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.96)[-0.960,0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; IP_SCORE(-3.06)[ip: (-9.78), ipnet: 2607:f8b0::/32(-3.13), asn: 15169(-2.33), country: US(-0.06)]; DWL_DNSWL_NONE(0.00)[gmail.com.dwl.dnswl.org : 127.0.5.0] 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: Thu, 27 Jun 2019 19:49:03 -0000 Thanks for welcoming me. > Unfortunately, it's too late to officially apply for a GSoC > scholarship this year. However, you're always welcome to hack around > on your own time. Feel free to peruse that list, and check > https://wiki.freebsd.org/SummerOfCode2019Projects to see what's taken. > This list is a good place to ask for help. > > That=E2=80=99s fine by me, I will try it through GSoC next year. For now = I just wanted to do one as a matter of interest. I cross checked the projects that have been taken. Going through the remaining ones, *IPv6 userland cleanup* seems interesting and doable to me. Can I work on that? If yes, by any chance is there some source where I could find more information about the project? Mihir From owner-freebsd-hackers@freebsd.org Thu Jun 27 20:06:19 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 0A5FF15CC62F for ; Thu, 27 Jun 2019 20:06:19 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-lj1-x22a.google.com (mail-lj1-x22a.google.com [IPv6:2a00:1450:4864:20::22a]) (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 AF3076EE0B for ; Thu, 27 Jun 2019 20:06:17 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-lj1-x22a.google.com with SMTP id x25so3659896ljh.2 for ; Thu, 27 Jun 2019 13:06:17 -0700 (PDT) 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:content-transfer-encoding; bh=xKAnHxNwH9YKlY3Jo5/vUyY2igvNCYbok8wt94WDbDk=; b=NI6CxoTB/CTvzFU/91dxt57gsWLKc60MEAyn1kMGoisuDzah+/edI6GoyoVvAxu1ag UxOy/BjvDo7ciOutU8kV4O57afEzpcy/jaNsJ0dTCjMPjbSaCzRDo4cbvx7EFNqmvYGF u+VD0vNzSDI3ClPOd8yTnSHpr4zTl5VzlHO+tps6MlQnNLFQzTgpoNBfZbv5hKHWNX8i 6WwRHwARuYs2y58flJkoRenevNCTen4TGs0UXIYHbsZv9URQMNvv5g3A/TPWpV5zbKaB xUS9FEj9Bqhrau0Y9Q/t+prfHdFz9fzFjIm0ZN4DlqJQH0wYwEhxy0P8OzVFv9Xt/ICp KpqQ== X-Gm-Message-State: APjAAAVEiGOZguy8Vl2bsLVG6R+p1H2yGrGk0n2VVQ1yTLY6ZpC74GzB SyZlLllT3/CPO6rqoXy2DpB7uQ9QjfCdeh5/PehKlQ== X-Google-Smtp-Source: APXvYqyS2c2oZtLd0JIEtsA1JPl2KFBpQ9XUzlq3V/kKFteG+x5/xHoSe5WwWhY+mXVZirxSiMhWMHftnUH5KtQ4ZW8= X-Received: by 2002:a2e:6e0c:: with SMTP id j12mr3750778ljc.123.1561665944192; Thu, 27 Jun 2019 13:05:44 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Alan Somers Date: Thu, 27 Jun 2019 14:05:32 -0600 Message-ID: Subject: Re: interested in contributing to FreeBSD projects To: Mihir Luthra Cc: "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: AF3076EE0B X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; spf=pass (mx1.freebsd.org: domain of asomers@gmail.com designates 2a00:1450:4864:20::22a as permitted sender) smtp.mailfrom=asomers@gmail.com X-Spamd-Result: default: False [-5.79 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DMARC_NA(0.00)[freebsd.org]; MIME_TRACE(0.00)[0:+]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MX_GOOD(-0.01)[cached: alt3.gmail-smtp-in.l.google.com]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[a.2.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.5.4.1.0.0.a.2.list.dnswl.org : 127.0.5.0]; NEURAL_HAM_SHORT(-0.96)[-0.961,0]; RCVD_TLS_LAST(0.00)[]; FORGED_SENDER(0.30)[asomers@freebsd.org,asomers@gmail.com]; FREEMAIL_TO(0.00)[gmail.com]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[asomers@freebsd.org,asomers@gmail.com]; IP_SCORE(-2.82)[ip: (-9.10), ipnet: 2a00:1450::/32(-2.59), asn: 15169(-2.33), country: US(-0.06)]; RCVD_COUNT_TWO(0.00)[2] 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: Thu, 27 Jun 2019 20:06:19 -0000 On Thu, Jun 27, 2019 at 1:49 PM Mihir Luthra wro= te: > > Thanks for welcoming me. > >> >> Unfortunately, it's too late to officially apply for a GSoC >> scholarship this year. However, you're always welcome to hack around >> on your own time. Feel free to peruse that list, and check >> https://wiki.freebsd.org/SummerOfCode2019Projects to see what's taken. >> This list is a good place to ask for help. >> > That=E2=80=99s fine by me, I will try it through GSoC next year. For now = I just wanted to do one as a matter of interest. > I cross checked the projects that have been taken. Going through the rema= ining ones, > *IPv6 userland cleanup* seems interesting and doable to me. Can I work on= that? If yes, by any chance is there some source where I could find more i= nformation about the project? > > Mihir That sounds like a great project for you. It should have a low threshold before you start making genuine progress. To learn more, I suggest starting a new thread on freebsd-net@FreeBSD.org, and CC gavin.atkinson@gmail.com . -Alan From owner-freebsd-hackers@freebsd.org Fri Jun 28 13:39:21 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 473A915C1915 for ; Fri, 28 Jun 2019 13:39:21 +0000 (UTC) (envelope-from marcdraco@protonmail.com) Received: from mail-40136.protonmail.ch (mail-40136.protonmail.ch [185.70.40.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.protonmail.ch", Issuer "SwissSign Server Silver CA 2014 - G22" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 336FE720C3 for ; Fri, 28 Jun 2019 13:39:19 +0000 (UTC) (envelope-from marcdraco@protonmail.com) Date: Fri, 28 Jun 2019 13:39:08 +0000 To: "freebsd-hackers@freebsd.org" From: Marc Draco Reply-To: Marc Draco Subject: Idea: Blockchain CAPTCHA Message-ID: Feedback-ID: TVAtyvzPgrZjDX92EFiEq2ju3ruDPj3hMOqgxFujxTmwlS8C0Uvt_X5pZBiCMOgQ_qQW-vlhc6PsIzvRAArI7w==:Ext:ProtonMail MIME-Version: 1.0 X-Spam-Status: No, score=-1.2 required=7.0 tests=ALL_TRUSTED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,HTML_MESSAGE autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on mail.protonmail.ch X-Rspamd-Queue-Id: 336FE720C3 X-Spamd-Bar: ------- X-Spamd-Result: default: False [-7.74 / 15.00]; HAS_REPLYTO(0.00)[marcdraco@protonmail.com]; R_SPF_ALLOW(-0.20)[+ip4:185.70.40.0/24]; FREEMAIL_FROM(0.00)[protonmail.com]; DKIM_TRACE(0.00)[protonmail.com:+]; MIME_BASE64_TEXT(0.10)[]; DMARC_POLICY_ALLOW(-0.50)[protonmail.com,quarantine]; MX_GOOD(-0.01)[mailsec.protonmail.ch,mail.protonmail.ch]; NEURAL_HAM_SHORT(-0.99)[-0.993,0]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+]; FREEMAIL_ENVFROM(0.00)[protonmail.com]; ASN(0.00)[asn:19905, ipnet:185.70.40.0/24, country:US]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[136.40.70.185.list.dnswl.org : 127.0.5.1]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[protonmail.com:s=default]; REPLYTO_EQ_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; FREEMAIL_REPLYTO(0.00)[protonmail.com]; HAS_PHPMAILER_SIG(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; IP_SCORE(-3.73)[ip: (-9.80), ipnet: 185.70.40.0/24(-4.89), asn: 19905(-3.91), country: US(-0.06)]; TO_DN_EQ_ADDR_ALL(0.00)[]; RCVD_TLS_ALL(0.00)[] Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 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: Fri, 28 Jun 2019 13:39:21 -0000 QXBvbG9naWVzIGlmIHRoaXMgaXMgdGhlIHdyb25nIGxpc3QsIGJ1dCB5b3Ugc2VlbSB0aGUgbW9z dCBsaWtlbHkgY2FuZGlkYXRlcyB0byBrbm93IGhvdyBwb3NzaWJsZS9wcmFjdGljYWwgdGhpcyBp cy4KCkkgaGF0ZSBjYXB0Y2hhcyBhcyBtdWNoIGFzIHRoZSBuZXh0IGd1eSBhbmQgcHJvYmFibHkg bW9yZSB0aGFuIGEgbG90IG9mIHBlb3BsZSBiZWNhdXNlIG15IHNpZ2h0IGlzbid0IHdoYXQgaXQg dXNlZCB0byBiZS4gSG93ZXZlciwgcHJpdmFjeSBpcyBtb3JlIG9mIGEgY29uY2VybiBhbmQgSSBo YXZlIGEgaGF0ZS1oYXRlIHJlbGF0aW9uc2hpcCB3aXRoIEdvb2dsZSB0aGF0IGdldHMgZGVlcGVy IHdpdGggZXZlcnkgcGllY2Ugb2Ygd2ViIGl0IHN0ZWFscy9idXlzLgoKU2luY2UgaXQgYm91Z2h0 IFJlQ2FwdGNoYSBJJ3ZlIGZvdW5kIG15c2VsZiBpbmNyZWFzaW5nbHkgaW4gYSBwb3NpdGlvbiB3 aGVyZSBJIGNhbid0IGF2b2lkIEdvb2dsZSBhcyBpdCdzIHByZXZlbnRpbmcgYWNjZXNzIHRvIHNp dGVzIEkgbmVlZCB0byBhY2Nlc3MgKGluY2x1ZGluZyBzb21lIGdvdmVybm1lbnQgb25lcykuCgpI ZW5jZSBpdCBzZWVtcyB3ZSBuZWVkIGEgbW9yZSBvcGVuIGFuZCBwcml2YWN5IHJlc3BlY3Rpbmcg c29sdXRpb24gZm9yICJlc3NlbnRpYWwiIHNlcnZpY2VzLiBJIGRvbid0IHVuZGVyc3RhbmQgZW5v dWdoIG9mIGJsb2NrY2hhaW4gdG8gIGtub3cgaG93IHByYWN0aWNhdCB0aGlzIGlzIGJ1dCBpdCBk b2VzIGFwcGVhciB0byBvZmZlciBhIHBvdGVudGlhbCBzb2x1dGlvbiB0byB0aGUgcHJvYmxlbSBv ZiBhbm9ueW1vdXMgKGFub255bWlzaW5nKSAgVHVyaW5nIHRlc3RzLgoKSSBob3BlIHdlIGNhbiBn ZXQgc29tZSBwb3NpdGl2ZSBpZGVhcyBoZXJlIC0gaWYgaXQncyBub3QgcG9zc2libGUgb3IgcHJh Y3RpY2FsLCB0aGVuIHRoYXQncyBncmVhdCBidXQgSSd2ZSBiZWVuIHVwZnJvbnQgYWJvdXQgaG93 IEkgZmVlbCBhYm91dCBHb29nbGUgKGFuZCBvdGhlcnMpIGFuZCBJIGZlZWwgc3Ryb25nbHkgdGhh dCB3ZSBuZWVkIHRvIHRha2UgYmFjayB0aGUgd2ViIGEgbGl0dGxlIGJpdCBhdCBhIHRpbWU6IHRo ZSB3YXkgdGhhdCBUaW0gQi1MIGludGVuZGVkLgoKU2VudCB3aXRoIFtQcm90b25NYWlsXShodHRw czovL3Byb3Rvbm1haWwuY29tKSBTZWN1cmUgRW1haWwu From owner-freebsd-hackers@freebsd.org Sat Jun 29 20:16:17 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 713D815B89B6 for ; Sat, 29 Jun 2019 20:16:17 +0000 (UTC) (envelope-from farhan@farhan.codes) Received: from mail.farhan.codes (mail.farhan.codes [155.138.165.43]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6B14C89373 for ; Sat, 29 Jun 2019 20:16:16 +0000 (UTC) (envelope-from farhan@farhan.codes) Received: from pc.farhan.codes (pool-100-36-37-117.washdc.fios.verizon.net [100.36.37.117]) by mail.farhan.codes (Postfix) with ESMTPSA id 686BE105B6 for ; Sat, 29 Jun 2019 16:16:06 -0400 (EDT) Date: Sat, 29 Jun 2019 16:16:05 -0400 From: Farhan Khan To: freebsd-hackers@freebsd.org Subject: src committer to push through approved patch: D18908 Message-ID: <20190629201604.GA16938@pc.farhan.codes> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.9.4 (2018-02-28) X-Rspamd-Queue-Id: 6B14C89373 X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.92 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; TO_DN_NONE(0.00)[]; DKIM_TRACE(0.00)[farhan.codes:+]; DMARC_POLICY_ALLOW(-0.50)[farhan.codes,reject]; MX_GOOD(-0.01)[mail.farhan.codes]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; IP_SCORE(-0.02)[asn: 20473(-0.03), country: US(-0.06)]; ASN(0.00)[asn:20473, ipnet:155.138.160.0/20, country:US]; RECEIVED_SPAMHAUS_PBL(0.00)[117.37.36.100.zen.spamhaus.org : 127.0.0.10]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[farhan.codes:s=mail]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_SPAM_SHORT(0.10)[0.104,0]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] 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: Sat, 29 Jun 2019 20:16:17 -0000 Hi all, What is the process to have an approved patch merged into the src tree? I have D18908 listed as "Accepted", but the reviewer informed me that he does not have the ability to merge to the src tree. Please let me know what I need to do next. Pardon my lack of knowledge of the process. Thanks, --- Farhan Khan PGP Fingerprint: 1312 89CE 663E 1EB2 179C 1C83 C41D 2281 F8DA C0DE From owner-freebsd-hackers@freebsd.org Sat Jun 29 20:59:10 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 B4F1115C12A5 for ; Sat, 29 Jun 2019 20:59:10 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qt1-x829.google.com (mail-qt1-x829.google.com [IPv6:2607:f8b0:4864:20::829]) (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 B58D58B564 for ; Sat, 29 Jun 2019 20:59:07 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qt1-x829.google.com with SMTP id s15so10332859qtk.9 for ; Sat, 29 Jun 2019 13:59:07 -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=VIlRWbXvxV+xVyOcAHAGRfcSFuNjF7LVvAtiqhfp7q8=; b=PQvEbScaFrSXgkzkwFZTlJk2I7fyKe+KiKwhqJVejZZoy1FesEXsAIVE6u8zzbxnUn djFDhqBXazQaqf26FK9IeJOW6MtCNgDayGYRiRNM/Y/4n2FvIPmy2mjBmKRQdmRYXiTi Tv0z4C/u6ZTYuh2GjN/LmAKYGWmn9fRX8hnRo2OLo6q8UuxNXtihPTLnGld/x6vULk37 6B4nRpUMQFxmSQh+S+yJeT4DM52UvJj5XPsNymT6mzhVlNWu8pwgjr4LR1ipUi1l2eql ILPjS/ZAwfbHeQ6+oc0oliVUkxM8xcxYXosEGg+pKaoLcVwvJyQBzkmDomcS0cItV669 8TZQ== 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=VIlRWbXvxV+xVyOcAHAGRfcSFuNjF7LVvAtiqhfp7q8=; b=qDjhQ/Zkk0ZXgJz0U6OF0+k0uBtbIoAEoZS6O6TgXdj9ack03IhX81jfSGl3iZK6Gl ovQffDpk+fFe29VQjk74PUn1OXTl1ouMYFbVVMz3JWBnE7sCi0EzCcbQ/9pScNNiIVV7 eEFQkz1sIjyI6XN0/XgaoyDJF73wH4S4BZRoO9lbqdCxRkCyG1f6TsLG96JDAcG8FuO6 Td7ObYXPXyUwJYfrWGMglM747MYcOLcHHPI80qPN15CtH9sHb7TraP98/dStXTpfeW9X 0Q+yEA3RYUAdNBKKkimxmFRb8pOUZwNd60I/PrqSrOVi8jmOhRBd/BE3wZkNGqRmfVAc 1DQw== X-Gm-Message-State: APjAAAUJTM3w1A2w+iWbWa1RCwZ3RnqK3VHUHTHQpvedYfV4iWMjNR0P 4SvoxMdCNmF8xyLWIMpWep13jSXfr0agzibxr1SKCw== X-Google-Smtp-Source: APXvYqxjkAidv0XfEN+WrnlumDv4LLP7eNV+ny50/00lYUIeW5Z3GbZJCjeVtiJbzSK/kbDU8b7w/wF9pYIs5xtxmyo= X-Received: by 2002:a0c:b66f:: with SMTP id q47mr14356375qvf.102.1561841946147; Sat, 29 Jun 2019 13:59:06 -0700 (PDT) MIME-Version: 1.0 References: <20190629201604.GA16938@pc.farhan.codes> In-Reply-To: <20190629201604.GA16938@pc.farhan.codes> From: Warner Losh Date: Sat, 29 Jun 2019 14:58:55 -0600 Message-ID: Subject: Re: src committer to push through approved patch: D18908 To: Farhan Khan Cc: "freebsd-hackers@freebsd.org" X-Rspamd-Queue-Id: B58D58B564 X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20150623.gappssmtp.com header.s=20150623 header.b=PQvEbSca X-Spamd-Result: default: False [-5.96 / 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_SHORT(-0.96)[-0.958,0]; 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]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20150623.gappssmtp.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[9.2.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]; MX_GOOD(-0.01)[ALT1.aspmx.l.google.com,aspmx.l.google.com,ALT2.aspmx.l.google.com]; 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(-2.99)[ip: (-9.41), ipnet: 2607:f8b0::/32(-3.13), asn: 15169(-2.34), country: US(-0.06)]; RCVD_COUNT_TWO(0.00)[2] Content-Type: text/plain; charset="UTF-8" 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: Sat, 29 Jun 2019 20:59:11 -0000 On Sat, Jun 29, 2019 at 2:19 PM Farhan Khan via freebsd-hackers < freebsd-hackers@freebsd.org> wrote: > Hi all, > > What is the process to have an approved patch merged into the src tree? > I have D18908 listed as "Accepted", but the reviewer informed me that he > does not have the ability to merge to the src tree. Please let me know what > I need to do next. > I'd feel a lot better if des@ were to approve this, since it touches his code. IIRC, he's not a big fan of phabricator. You might want to try sending the current patch to him. Warner > Pardon my lack of knowledge of the process. > > Thanks, > --- > Farhan Khan > PGP Fingerprint: 1312 89CE 663E 1EB2 179C 1C83 C41D 2281 F8DA C0DE > _______________________________________________ > 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" >