From owner-svn-src-all@freebsd.org Fri Feb 22 03:12:57 2019 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 70E6314FCEF4; Fri, 22 Feb 2019 03:12:57 +0000 (UTC) (envelope-from kevans@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 13FAD7678F; Fri, 22 Feb 2019 03:12:57 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from mail-lj1-f177.google.com (mail-lj1-f177.google.com [209.85.208.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) (Authenticated sender: kevans) by smtp.freebsd.org (Postfix) with ESMTPSA id B165110573; Fri, 22 Feb 2019 03:12:56 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: by mail-lj1-f177.google.com with SMTP id v16so476978ljg.13; Thu, 21 Feb 2019 19:12:56 -0800 (PST) X-Gm-Message-State: AHQUAubytw5M5Ow6x1UjstU4sg+Jys+UGTQNN6YHj2DtoSte7jxy5l/j cBFnYZMbVzkTsRGoWGttQdCyZAinXxhcetwfysw= X-Google-Smtp-Source: AHgI3IZwtrnZzQbgSQYfXchTs72p0GmGUIa5LVFSfQ9tdSSAet4vksG8Q//cUy0Gq/FpZfL9Fe5GaYfZ63bL/vmXNgw= X-Received: by 2002:a2e:8006:: with SMTP id j6-v6mr929890ljg.186.1550805175226; Thu, 21 Feb 2019 19:12:55 -0800 (PST) MIME-Version: 1.0 References: <6A8C488C-05F4-4607-8F40-F301AF91E7EA@gmail.com> <201902211640.x1LGetma021290@pdx.rh.CN85.dnsmgr.net> In-Reply-To: <201902211640.x1LGetma021290@pdx.rh.CN85.dnsmgr.net> From: Kyle Evans Date: Thu, 21 Feb 2019 21:12:43 -0600 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: svn commit: r344414 - stable/11 To: "Rodney W. Grimes" Cc: Enji Cooper , src-committers , svn-src-all@freebsd.org, svn-src-stable@freebsd.org, svn-src-stable-11@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 13FAD7678F X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.94 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.94)[-0.938,0]; REPLY(-4.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0] X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.29 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: Fri, 22 Feb 2019 03:12:57 -0000 On Thu, Feb 21, 2019 at 10:41 AM Rodney W. Grimes wrote: > > > > On Feb 21, 2019, at 04:43, Kyle Evans wrote: > > > > > > On Thu, Feb 21, 2019 at 12:16 AM Rodney W. Grimes > > > wrote: > > >> > > >>> Author: kevans > > >>> Date: Thu Feb 21 03:22:20 2019 > > >>> New Revision: 344414 > > >>> URL: https://svnweb.freebsd.org/changeset/base/344414 > > >>> > > >>> Log: > > >>> MFC (RECORD ONLY) r338050: Loader default interpreter flip > > >>> > > >>> The default interpreter for stable/11 is 4th; this will never and can never > > >>> change. Record MFC of r338050 to proactively prevent any accidents in future > > >>> batching of MFCs. > > >>> > > >>> Modified: > > >>> Directory Properties: > > >>> stable/11/ (props changed) > > >> > > >> Does it make sense to do a direct commit to stable/11 > > >> marking the line that does this flip with a > > >> "Do not change this in the stable/11 branch" > > >> so that someone does not try to manually merge > > >> the change if they happen to notice the code > > >> is different? > > > > > > I'll chew on it for a little bit. It's fairly clear what the > > > ramifications of swapping those lines around are, even from diff > > > review, and I'd like to assume no one would willfully do it if they > > > put a couple seconds thought into what they were about to commit. > > > > Kyle, > > I think what you did makes sense. I?ve done this and I?ve > > seen others do similar in the past. > I concur, what he did do makes perfect since. > > > As someone who?s merged code in from others, I appreciate > > measures like this, which would prevent me from breaking a > > stable branch by accident. > > I am just wondering about a second safety belt, > as the current one just makes a svn merge -c338050 a silent nop, > but in no way stops someone from manually applying the diff. > > We have people that are very good with svn and would know how > to investigate the nop, and we have people who can barely > manage to do a merge with proper mergeinfo. > After mulling it over, I went ahead and committed the result in r344455. I still don't necessarily think it'll be a problem, but I certainly don't object to more safety belts and peace of mind -- especially since it's a subtle change to flip the ordering that might not be easy to catch at a glance without the ugly warning nearby.