Return of config files to ^/etc

[Kyle Evans]

On Sat, Feb 15, 2020 at 3:34 PM Oliver Pinter <oliver.pntr at gmail.com> wrote:
> On Saturday, February 15, 2020, Rodney W. Grimes <freebsd-rwg at gndrsh.dnsmgr.net> wrote:
>>
>> > On Sat, Feb 15, 2020 at 1:36 PM Rodney W. Grimes
>> > <freebsd-rwg at gndrsh.dnsmgr.net> wrote:
>> > >
>> > > > On Sat, Feb 15, 2020 at 9:13 AM Shawn Webb <shawn.webb at hardenedbsd.org> wrote:
>> > > > >
>> > > > > Hey Kyle,
>> > > > >
>> > > > > On Fri, Feb 14, 2020 at 04:42:15PM -0600, Kyle Evans wrote:
>> > > > > > Hello,
>> > > > > >
>> > > > > > I've organized a review[0] to return most config files back to etc/.
>> > >
>> > > I read the review, I have issues I need to post in it, but at the
>> > > moment dont have write access to reviews.freebsd.org due to broken
>> > > https mangling by a captive portal.
>> > >
>> >
>> > I will certainly be waiting on plenty of feedback for this one.
>>
>> It is actually minor feedback, but more about methods than content.
>>
>> > > > Something that I've intentionally not pitched yet (to avoid conflating
>> > > > major issues) is the possibility of MFC'ing the move back to
>> > > > stable/12. It's feasible, but requires more care and attention than it
>> > > > does in head/. IIRC, when you attempt to merge an svn mv/cp to another
>> > > > branch, svn will stage it as a copy from the version in head/ that
>> > > > lives at the destination. So, when you try to MFC a mv/cp, you're
>> > > > effectively MFC'ing all changes before it unless you take care to
>> > > > assess and, as needed, revert those in the final diff.
>> > > >
>> > > > I will volunteer to do this work if the move back happens, but I will
>> > > > raise that as a follow-up issue. I suspect that it will be desired if
>> > > > we do the move in head, to ease the pain of merging back to our most
>> > > > recent branch.
>> > >
>> > > I'll volunteer to help you do that work if that move should need
>> > > to happen.
>> > >
>> >
>> > Thanks- I appreciate that! =-)
>>
>> Did you just stick a pitch fork in my hay bail?   :-)
>>
>> > > You may actually simplify the process if you use reverts to undo the
>> > > change in ^head and merge the reverts back, I think that *might*
>> > > just do the right things, but I would need to run some test cases.
>> > >
>> >
>> > I have a fear (completely unfounded- I make no claims that this is
>> > correct or has ever happened) that svn would do the completely wrong
>> > thing and try to restore the old version.
>>
>> Well isnt the "old version" what we want to get back to actually?
>
>
> Not et all. There will be possible changes in the files in the newer place too. Like eliminating an architecture or improving defaults. For getting clue about what has been moved from svn is fine, but reverting - as I think - is not.
>

Sorry, I missed this part of the chain- indeed, we don't want the old
version, just the old location with appropriate changes. Considering
this sequence of events:

1. ^/etc/defaults/devfs.rules moves to sbin/devfs/devfs.rules
2. rgrimes commits new hotness that's compatible with older branches
to devfs.rules
3. jhb comes through and makes some change for a 13.0-only feature
4. rgrimes MFC's bits described in #2
5. kevans moves sbin/devfs/devfs.rules back

To be explicit: #2 may be MFC'd to stable/12, but #3 may not

My experience is that trying to MFC the move back (step #4) will pull
in changes #2 *and* #3 implicitly (unless you're paying attention,
then it's pretty explicit). Ideally, what we want is a version in
stable/12 with #1 reverted but #2 still applied, and #3 *not*.

This is the level of hell with MFC'ing sys/boot -> stand back to
stable/11, except some changes after the sys/boot -> stand move had
already been MFC'd, so I had to re-apply those changes manually or
work out some other way to reconcile because it kept trying to pull a
stale version back.

Thanks,

Kyle Evans