Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 10 Apr 2018 08:15:38 -0500
From:      Kyle Evans <kevans@freebsd.org>
To:        "Rodney W. Grimes" <rgrimes@freebsd.org>
Cc:        Niclas Zeising <zeising+freebsd@daemonic.se>, svn-src-stable@freebsd.org,  svn-src-all@freebsd.org, src-committers <src-committers@freebsd.org>,  svn-src-stable-11@freebsd.org
Subject:   Re: svn commit: r331880 - stable/11/etc
Message-ID:  <CACNAnaHcdCp8S4Hs4NvCN5Phog02_8VxOd%2Bpp3ieqW2aoNbOYw@mail.gmail.com>
In-Reply-To: <201804100422.w3A4M7VO021574@pdx.rh.CN85.dnsmgr.net>
References:  <CACNAnaHSVL0O_PZg0-KKEAc1rZtNjEL9WvqcPsx3WZs7-y_Y4Q@mail.gmail.com> <201804100422.w3A4M7VO021574@pdx.rh.CN85.dnsmgr.net>

index | next in thread | previous in thread | raw e-mail

On Mon, Apr 9, 2018 at 11:22 PM, Rodney W. Grimes
<freebsd@pdx.rh.cn85.dnsmgr.net> wrote:
> [ Charset UTF-8 unsupported, converting... ]
>> On Mon, Apr 9, 2018 at 11:59 AM, Warner Losh <imp@bsdimp.com> wrote:
>> >
>> >
>> > On Mon, Apr 9, 2018 at 10:09 AM, Kyle Evans <kevans@freebsd.org> 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.


home | help

Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CACNAnaHcdCp8S4Hs4NvCN5Phog02_8VxOd%2Bpp3ieqW2aoNbOYw>