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

[Rodney W. Grimes]

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

Regards,
Rod

> Warner
> 
> On Mon, Jun 24, 2019 at 10:50 PM Warner Losh <imp at freebsd.org> 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 at freebsd.org