From owner-freebsd-arch@freebsd.org Sat Feb 15 21:46:34 2020 Return-Path: Delivered-To: freebsd-arch@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id D9916249F87 for ; Sat, 15 Feb 2020 21:46:34 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (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 48KkNB5Hl9z4S9h for ; Sat, 15 Feb 2020 21:46:34 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from mail-qt1-f174.google.com (mail-qt1-f174.google.com [209.85.160.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) (Authenticated sender: kevans) by smtp.freebsd.org (Postfix) with ESMTPSA id 922A41B1F3 for ; Sat, 15 Feb 2020 21:46:34 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: by mail-qt1-f174.google.com with SMTP id t13so9529314qto.3 for ; Sat, 15 Feb 2020 13:46:34 -0800 (PST) X-Gm-Message-State: APjAAAVCzCtx3dbTDD1Gv+VL5elJaNHC6PURrV1GG/p5cU185HWOEods okeFRXCXqkKRv0SDvaSweixT03M5yBW2q+iwbdk= X-Google-Smtp-Source: APXvYqwMWYj704CVBqH8csnRBHdrFaVa9NDTpa2sWwvvjx3phsA79KMCnAaQRyPdmrz8Fq5HgrroQeFHRYAfFOh8ZAQ= X-Received: by 2002:ac8:740f:: with SMTP id p15mr7486496qtq.211.1581803194042; Sat, 15 Feb 2020 13:46:34 -0800 (PST) MIME-Version: 1.0 References: <202002152113.01FLD4aX049216@gndrsh.dnsmgr.net> In-Reply-To: From: Kyle Evans Date: Sat, 15 Feb 2020 15:46:19 -0600 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Return of config files to ^/etc To: Oliver Pinter Cc: "Rodney W. Grimes" , "freebsd-arch@freebsd.org" , Shawn Webb Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Feb 2020 21:46:34 -0000 On Sat, Feb 15, 2020 at 3:34 PM Oliver Pinter wrote: > On Saturday, February 15, 2020, Rodney W. Grimes wrote: >> >> > On Sat, Feb 15, 2020 at 1:36 PM Rodney W. Grimes >> > wrote: >> > > >> > > > On Sat, Feb 15, 2020 at 9:13 AM Shawn Webb 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