On Mon, Apr 9, 2018 at 11:22 PM, Rodney W. Grimes
<free...@pdx.rh.cn85.dnsmgr.net> wrote:
> [ Charset UTF-8 unsupported, converting... ]
>> On Mon, Apr 9, 2018 at 11:59 AM, Warner Losh <i...@bsdimp.com> wrote:
>> >
>> >
>> > On Mon, Apr 9, 2018 at 10:09 AM, Kyle Evans <kev...@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.
_______________________________________________
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
