From owner-svn-src-all@freebsd.org Tue Apr 10 02:28:25 2018 Return-Path: Delivered-To: svn-src-all@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 C799AF9465E; Tue, 10 Apr 2018 02:28:24 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from smtp.freebsd.org (unknown [IPv6:2610:1c1:1:606c::24b:4]) (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 72A3373B0A; Tue, 10 Apr 2018 02:28:24 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from mail-lf0-f53.google.com (mail-lf0-f53.google.com [209.85.215.53]) (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 1EFB8CDC5; Tue, 10 Apr 2018 02:28:24 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: by mail-lf0-f53.google.com with SMTP id x70-v6so9389808lfa.0; Mon, 09 Apr 2018 19:28:24 -0700 (PDT) X-Gm-Message-State: ALQs6tA36P8k/Vw7v8wivFxe0owhYN1to/P67lDtX2Z4/It0QCIHcGHw qTbFK7o+BHOjHljnpDoyHVnYURB68V8yLZEUPUY= X-Google-Smtp-Source: AIpwx48gFoO7n1Xrrt1uQ0pQ5oaFFU9+SqtBJsn3cO9gdkCmhAhEoKL6TEzkS1tGvUO7JtT/6wXOOIHpWBQH6q2p/rI= X-Received: by 10.46.29.1 with SMTP id d1mr23874733ljd.22.1523327302552; Mon, 09 Apr 2018 19:28:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.129.90 with HTTP; Mon, 9 Apr 2018 19:28:01 -0700 (PDT) In-Reply-To: References: <201804091552.w39Fqv2S019416@pdx.rh.CN85.dnsmgr.net> From: Kyle Evans Date: Mon, 9 Apr 2018 21:28:01 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: svn commit: r331880 - stable/11/etc To: Warner Losh Cc: "Rodney W. Grimes" , 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-all@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2018 02:28:25 -0000 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. 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).