From owner-svn-src-head@freebsd.org Tue Jun 25 15:26:16 2019 Return-Path: Delivered-To: svn-src-head@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C82DC15CF652 for ; Tue, 25 Jun 2019 15:26:16 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qk1-x72b.google.com (mail-qk1-x72b.google.com [IPv6:2607:f8b0:4864:20::72b]) (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 1ED488F7D9 for ; Tue, 25 Jun 2019 15:26:16 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qk1-x72b.google.com with SMTP id r6so12948674qkc.0 for ; Tue, 25 Jun 2019 08:26:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=9HRCJqY2mStZ5GjEdLdZl7Yrp9Lzk58XZJbUlSLiSyA=; b=VgG2kez46pK6qnDKqR5fID8Z7DfPv+BtZrH6F8S70VPSshzGwkpS8fEJ5dw79B24hH 2V2eBwwks/drpmeN6L/U11Rz4C3IEse0+0pSUeGYXqGAX3VlQKW9xIiVZxeM2gFoCdub NsBA0bM1WBJYQGoAo2H/eMH0kLpz+JGQaYhQXktS039sdZohh9ZzncqQxJMEQd/TNtld CVT10eQIC4iRdmU+CHgVYGSa1FXYWiHiuB+hxKuo/qX/HqRBuPDQ2gdesEnjJ1jymQxU TZl33Z0wPCnPJs1RuWk1XsYS4GxBVOMc3XqXw+hR3Dc3TnUWyjYRMAMz3Nv2zj8eJQvK VqlA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=9HRCJqY2mStZ5GjEdLdZl7Yrp9Lzk58XZJbUlSLiSyA=; b=AhfMJkAHcOhdffsHFSdHM/QfUBgNcZS5MV10tEq0Xm3GADpfEsh3/1YSJGjFEE9Sdo PUKrZUEoPXTztW+wMAHgbwA1y5Y24MA+NRLpxg1o3LAvQKdT0xiODPpKBEz7FV7R595m zXiZCgkOn0qeRnjAx+bPY/XEX5eZ0yX+rxjmBmUG8wjxC9t4mPqF+5u+SWinBXVJZzdg 407hwGIgYQoFxwh5/HXRWBJx4BdqcHDp907hMs9Th/dRVAlCPQ0zy91wV/gqlPWP1l/Q wvh1O6bBwmB0NYeHYdRPzSHzqOljZd4tMUqQZsg1KM0sN+bH8ZfpuaPOz5yNDyts1xod qW8A== X-Gm-Message-State: APjAAAXGk3oM16Lw0rilwrQGF243Qcn0T+J5Xm+o6zSCnbMBNdGd5q54 467eSWqjbkhCjD8aZv2c7fZ6MtAlyhcti+6t24TDAg== X-Google-Smtp-Source: APXvYqzSmWQiOCj8WUApuBqftHqgds2noP9+5BtY6f2XeDX2eaS/tizSP98pcUOJBuLTJt8ArU7bvvfA2xnlBQ3nv4M= X-Received: by 2002:a37:6652:: with SMTP id a79mr40003322qkc.60.1561476375133; Tue, 25 Jun 2019 08:26:15 -0700 (PDT) MIME-Version: 1.0 References: <201906251324.x5PDONUQ049600@gndrsh.dnsmgr.net> In-Reply-To: <201906251324.x5PDONUQ049600@gndrsh.dnsmgr.net> From: Warner Losh Date: Tue, 25 Jun 2019 09:26:03 -0600 Message-ID: Subject: Re: svn commit: r349352 - in head: etc/mtree include lib lib/libnandfs sbin sbin/camcontrol sbin/nandfs sbin/newfs_nandfs share/man/man4 share/man/man5 share/mk stand stand/arm/uboot stand/common stand... To: "Rodney W. Grimes" Cc: Warner Losh , src-committers , svn-src-all , svn-src-head X-Rspamd-Queue-Id: 1ED488F7D9 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.96 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.96)[-0.964,0]; REPLY(-4.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2019 15:26:17 -0000 On Tue, Jun 25, 2019 at 7:24 AM Rodney W. Grimes wrote: > > This commit accidentally reverted r349333, r349334, r349335, r349336, > > r349339, r349340, r349341 and r349342. I rebased after one of the make > > universes I did to proof this set and something must have gone wrong and > I > > lost these changes. I noticed while committing, but didn't hit ^C fast > > enough to prevent the damage it seems. > > > > I've reapplied those changes rather than revert this commit for two > > reasons: first, reverting commits that delete things has caused me > trouble > > in the past. Second, I judge that to be less repo-churn than doing the > > revert, then redoing the nand* removal. > > > > Time was of the essence, so I hope my snap-judgement was sound. My > > apologies both for the 'oops' and for any other fallout. > > Though this may of reduced repo churn it also broke any MFC > that may of been marked in those sets. I am not even sure > how one would untwist that maze. > > MFC original commit is going to leave your second commit as > wrongly avaliable commit, so that needs dealt with. > > MFC your reapply commit, which they have to get by noting these > commits as the new merge number. Again, leaving a danglying > merge avaliable commit > > MFC the original commit, your mangle commit, but only the > part that applies to there original commit, and the reapply > commit. This marks the mangle as merged, but does infact > leave the merge avail list for head correct. > > None of that is very pretty. There are some other options... > > > Anyway my main reason for writting is somehow we need to get out > of this "repo churn is expensive I must not revert!" mode of > operations. Reverts are almost always the correct way to clean > up a mistake, and it almost always leeds to other issues to > not revert and instead try to do some magic like what was > done here. > > It is also often a mistake to not exactly revert the original > commit, commit that, then commit any additional fix. Reverting > and making other changes in the same commit leads to problems > more often than it solves them. I do understand the tree might > not be in a buildable or correct state for a commit or two. > I think that you over-state the issue here. Wouldn't the issue be fixed for MFCs of the replayed commits by MFCing them twice? The first time the first commit with svn merge, and then the second commit with a svn merge --record-only? We could do the same --record-only trick with the NAND removal commit, since it will never be MFC'd. Since the number of commits is small, and the people that would be MFCing them are super experienced with svn, I think that wouldn't be an issue. Then for others, it won't show up as a possible merge candidate (though honestly, with the files affected, that bit of svn is rarely used, also mitigating the data anomaly). I made a conscious decision to minimize time to get the repo repaired from the damage of the one commit. Warner Regards, > Rod > > > Warner > > > > On Mon, Jun 24, 2019 at 10:50 PM Warner Losh wrote: > > > > > Author: imp > > > Date: Tue Jun 25 04:50:09 2019 > > > New Revision: 349352 > > > URL: https://svnweb.freebsd.org/changeset/base/349352 > > > > > > Log: > > > Remove NAND and NANDFS support > > > > > > NANDFS has been broken for years. Remove it. The NAND drivers that > > > remain are for ancient parts that are no longer relevant. They are > > > polled, have terrible performance and just for ancient arm > > > hardware. NAND parts have evolved significantly from this early work > > > and little to none of it would be relevant should someone need to > > > update to support raw nand. This code has been off by default for > > > years and has violated the vnode protocol leading to panics since it > > > was committed. > > > > > > Numerous posts to arch@ and other locations have found no actual > users > > > for this software. > > > > > > Relnotes: Yes > > > No Objection From: arch@ > > > Differential Revision: https://reviews.freebsd.org/D20745 > > > ... > > -- > Rod Grimes > rgrimes@freebsd.org >