svn commit: r344414 - stable/11

[Kyle Evans]

On Thu, Feb 21, 2019 at 10:41 AM Rodney W. Grimes
<freebsd at pdx.rh.cn85.dnsmgr.net> wrote:
>
> > > On Feb 21, 2019, at 04:43, Kyle Evans <kevans at freebsd.org> wrote:
> > >
> > > On Thu, Feb 21, 2019 at 12:16 AM Rodney W. Grimes
> > > <freebsd at pdx.rh.cn85.dnsmgr.net> 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.