From owner-freebsd-arch@freebsd.org Sat Feb 15 21:34:56 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 872E02495E3 for ; Sat, 15 Feb 2020 21:34:56 +0000 (UTC) (envelope-from oliver.pntr@gmail.com) Received: from mail-yw1-xc2c.google.com (mail-yw1-xc2c.google.com [IPv6:2607:f8b0:4864:20::c2c]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 48Kk6l2Jtjz4M8W; Sat, 15 Feb 2020 21:34:55 +0000 (UTC) (envelope-from oliver.pntr@gmail.com) Received: by mail-yw1-xc2c.google.com with SMTP id l22so6055669ywc.8; Sat, 15 Feb 2020 13:34:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=DnsfANCPavFV29HaVP6H12kqveRhx4MUhswcafQ/Bjg=; b=GNw2tFYQfRkGPMVMDazdmjJm19e8rwZWJ97lglKA7PUbpebjejwh2gueUoDCtElXuX sF/MevyXXTcgzIlLgKi0j6YRxNwI+gSV+lnSEP7a1twT+eV7jozstY2VAdWPCdBYQ7b/ Ac8Bs72ldWeFM+AIJa1i/0Md7IZB+H4PsEG5NeiVbUwPB75wuwMYk6ILbECBGZ83K+6m NL/MZU4QDy+qOhSAcTuAesHb0b8/iFt/ZkjrAcLmDkXBODNGIFh/ZcOAiXUXlPf55zdg sslZjywOMFvZ+vZTRW8ZMTRqNcFXDyiLPMyEybEb9JcVM9TypVzcxltTH8OCafHmH+1K DsiA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=DnsfANCPavFV29HaVP6H12kqveRhx4MUhswcafQ/Bjg=; b=W8GwQeNFFRJrmJeldH2o28ARV46LFrb+KDfu+z89ISuA40v6JEovhKTc1dEF+eOFeN THuDWyyCWrxQ4mJsaIPAh6fHhDxZun2Uj9AWDsmsGJ3xXNoAkzVA89Y9KqsU1dBSrds7 eoIkpkOmzDJlLvHzz1XogMia9s2nIHcp/zZAwGJa7hgGRQJsI1/3Txdx6+lsRzV0OlXB I9kLPc+SsARFCiz3uwmkH23cgRk8DCzwcvsUyINmlB74xmFw2siY3umx5Ou/8Qcr/u3v mAGyma1qj3LWY92nWyhayekIth6nakssoVbifrLtpyyuYPX0ICW7XFxdpK0ylPzgG/0n /RFw== X-Gm-Message-State: APjAAAX5iwFxaCNpNShE4yDkxQkUHc09JEuQhL+Dw25G9GGyq+eQtFKL GGDlRYKA4z3PPrl5eGZVTiLDcYoy5RZ1gO7h/98AvQ== X-Google-Smtp-Source: APXvYqz6W1M8mmrwyaSha1SnMb7VsRLyhPVpLr2EBt7jNtJHejou0aGJglNLO1/0vnrDs3I1g8VgZ4SlxpL68vyXPIE= X-Received: by 2002:a81:6e09:: with SMTP id j9mr7099223ywc.25.1581802494357; Sat, 15 Feb 2020 13:34:54 -0800 (PST) MIME-Version: 1.0 Received: by 2002:a25:8542:0:0:0:0:0 with HTTP; Sat, 15 Feb 2020 13:34:53 -0800 (PST) In-Reply-To: <202002152113.01FLD4aX049216@gndrsh.dnsmgr.net> References: <202002152113.01FLD4aX049216@gndrsh.dnsmgr.net> From: Oliver Pinter Date: Sat, 15 Feb 2020 22:34:53 +0100 Message-ID: Subject: Re: Return of config files to ^/etc To: "Rodney W. Grimes" Cc: Kyle Evans , "freebsd-arch@freebsd.org" , Shawn Webb X-Rspamd-Queue-Id: 48Kk6l2Jtjz4M8W X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=GNw2tFYQ; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of oliverpntr@gmail.com designates 2607:f8b0:4864:20::c2c as permitted sender) smtp.mailfrom=oliverpntr@gmail.com X-Spamd-Result: default: False [-2.00 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; FREEMAIL_FROM(0.00)[gmail.com]; URI_COUNT_ODD(1.00)[5]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; FROM_EQ_ENVFROM(0.00)[]; IP_SCORE(0.00)[ip: (-9.27), ipnet: 2607:f8b0::/32(-1.90), asn: 15169(-1.68), country: US(-0.05)]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; TAGGED_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; IP_SCORE_FREEMAIL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[c.2.c.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 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:34:56 -0000 On Saturday, February 15, 2020, Rodney W. Grimes < freebsd-rwg@gndrsh.dnsmgr.net> 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 < > shawn.webb@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. > > Procedure above may be a bit wrong. Revert in ^head, then to take > that back to a branch it existed in at time it was branch just revert > that same commit from the branch. That should end with the "change" > removed from both head and stable/12. > > But still some testing needs to be done. Last time I did major > surgery the biggest issues I ran into on a branch was improperly > recorded merge history that I had to fix first, then things more > or less just worked as expected. Hint: record only merge history > that is not with the diff that merged it is evil nasty crap! So > is merge history recorded with another commit that is not the > actual merge diff. And yes, I ran into both cases in the FreeBSD > repository. > > > > > The more I think about it, the more I suspect that most folks that > > want this would also want it to be MFC'd to eliminate the friction, so > > I'll do some inspection up-front to see if we'd really run into > > problems here. Fortunately, there's only one branch that we need to > > worry about this for that's only about one year old. I suspect we > > could get away with MFC'ing any stragglers up-front, as I don't recall > > any major groundbreaking stuff happening in etc/ since 12 > > branched...but my memory kinda sucks. > > I agree with the suspecion of wanting the MFC'd. > > > > > Thanks, > > > > Kyle Evans > > > > -- > Rod Grimes > rgrimes@freebsd.org > _______________________________________________ > freebsd-arch@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" >