Return of config files to ^/etc

[Rodney W. Grimes]

> 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.

> > > Many people were concerned about the mass exodus of etc/, and many
> > > have expressed a desire (privately or otherwise) for these files to
> > > return- some of these folks represent downstreams or consumer projects
> > > that went through the painful move the first time and would happily go
> > > through the pain again to restore the status quo.
> > >
> > > This does mean that we'd end up with a structure that's not compatible
> > > with stable/12, but is compatible with every branch before it.
> > >
> > > If you have an opinion for or against. please speak up now. I'd like
> > > to make sure we're moving in the correct direction as a developer
> > > community.

I spoke up rather loudly in public when this first started to happen,
so of cource I am in support of reverting to prior design.

> >
> > I'm curious how long downstream projects would need to support both
> > paradigms.
> >
> 
> The answer for both downstreams and us is "however long stable/12 is
> supported" for that particular project.

As of now downstreams that support stable/11 are already
in the position of having to support both.
Further if this change does get back to stable/12 that life cycle
whould greatly be reduced as the EOL of 12.1 would be fairly short
after 12.2 was released, 3 months iirc.


> 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.

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.

> Thanks,
> Kyle Evans
-- 
Rod Grimes                                                 rgrimes at freebsd.org