From owner-svn-src-stable@freebsd.org Tue Apr 10 13:16:01 2018 Return-Path: Delivered-To: svn-src-stable@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 619CBF9C066; Tue, 10 Apr 2018 13:16:01 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 07D99692D8; Tue, 10 Apr 2018 13:16:01 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from mail-lf0-f44.google.com (mail-lf0-f44.google.com [209.85.215.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) (Authenticated sender: kevans) by smtp.freebsd.org (Postfix) with ESMTPSA id B25CA10D4A; Tue, 10 Apr 2018 13:16:00 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: by mail-lf0-f44.google.com with SMTP id q9-v6so11608092lfk.9; Tue, 10 Apr 2018 06:16:00 -0700 (PDT) X-Gm-Message-State: ALQs6tDI14rFqQ+j90mGb/az+p/q1Ps7KAgOYRpYrg3AZGlNZ438OCks VGIsqEIYoBQ/8FC/jtky4GGECU5aGXPAV3HIqNE= X-Google-Smtp-Source: AIpwx4+GnyrOvqJoMF866D+SCGoD2fdS85Jc04L9qYQ3Tir9ITaUdZG53zg45lSWvGiaEjS3AcHIVJUOvZXeA42xne8= X-Received: by 2002:a19:d911:: with SMTP id q17-v6mr194455lfg.99.1523366159330; Tue, 10 Apr 2018 06:15:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.129.90 with HTTP; Tue, 10 Apr 2018 06:15:38 -0700 (PDT) In-Reply-To: <201804100422.w3A4M7VO021574@pdx.rh.CN85.dnsmgr.net> References: <201804100422.w3A4M7VO021574@pdx.rh.CN85.dnsmgr.net> From: Kyle Evans Date: Tue, 10 Apr 2018 08:15:38 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: svn commit: r331880 - stable/11/etc To: "Rodney W. Grimes" Cc: Niclas Zeising , svn-src-stable@freebsd.org, svn-src-all@freebsd.org, src-committers , svn-src-stable-11@freebsd.org Content-Type: text/plain; charset="UTF-8" X-BeenThere: svn-src-stable@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: SVN commit messages for all the -stable branches of the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2018 13:16:01 -0000 On Mon, Apr 9, 2018 at 11:22 PM, Rodney W. Grimes wrote: > [ Charset UTF-8 unsupported, converting... ] >> On Mon, Apr 9, 2018 at 11:59 AM, Warner Losh wrote: >> > >> > >> > On Mon, Apr 9, 2018 at 10:09 AM, Kyle Evans wrote: >> >> >> >> Right- so, back out this MFC (and the subsequent FreeBSD_version bump) >> >> and fix the ports to do the right thing for 12.x while that's still >> >> not a technically supported branch? >> > >> > >> > Don't back out the version bump. Other things may be riding along on it 'for >> > free'. Better to bump it again when you unMFC (if it's been more than a few >> > days since we've had one), and then yet-again when a fixed MFC happens. >> > Unless there's something you can ride along on for free :) >> > >> > Otherwise, that's a great plan. >> >> Ok, I think the result of this thread and discussion with 0mp is the >> following set of actions: >> >> 1.) One (1) commit to stable/11 to revert the MFC and bump >> FreeBSD_Version again for the removal >> 2.) One (1) commit to doc to document the new FreeBSD_Version >> 3.) Fixing ports to use the "new" behavior on 12, both the >> yet-to-be-patched ports and the ports that had already been patched >> under the assumption that it would still land first in 11.1-stable >> 4.) Documenting the original commit? >> >> The hard part of point #3 has already been done by 0mp, who has >> submitted patches for all of the ports using this behavior. His >> patches will just need a bump of the version they're testing to the >> 12.x FreeBSD_Version and a fix-up on the patches that already landed. >> >> For point #4, this seems like the type of breakage we should be >> documenting in release notes or something for the eventual upgrading >> of systems to 12.0. All usage of _limits stuff in custom rc scripts >> need to be audited, and all rc.conf(5)'s need to be scrubbed for >> ${name}_limits usage that doesn't make sense with the new context. I'm >> not sure what the most appropriate action here is, or what we should >> do this far ahead of time for such a thing. > > We do need a way to stack little notes that need to make it into > the release notes, even if there is no single commit they are related > to, or in this case we find out later that a change had wider > impacts and needs to have a note added. Maybe gjb@ has a place we > can just commit to that gets collected for the release? > >> If this sounds like a good path forward, I'll execute #1 and #2 in the >> morning (CST, so ~11 hours from this e-mail being sent). > > I am on board with this much of this plan. > > > What about cy@ changes to the ddb and other startup scripts? > Right- I was mostly concerned with fixing the fallout from this particular commit. I think that merits its own discussion in a separate thread or in the early referenced PR, but I'm tempted to go ahead and commit Cy's ddb patch to start while we assess the other damage.