At this point, we could have stably released 1.2 and been well on our way
to putting 1.3 together; instead we're still sitting here running 1.2B which
isn't likely to change by the time the next -current gets underway.

Why don't we just punt at this point, call it 1.2 and unlock the tree so we
can get going?  It's certainly stable enough to do so.

On another note, I'm not sure, but I think the patches I submitted for
umount, dump and fsck_ffs have been dropped again (my NetBSD machine is
inactive until mid-October); as I don't have the old source to look at
and I'm not running, could someone please confirm that:

	dump, when given a fstab entry referencing a null mount,
		does not attempt to dump the directory referenced by
		the null mount, but with a 'r' appended after "/dev/"...
		(i.e. don't dump non_ffs filesystems)

	fsck(_ffs) accepts a mount point as a filesystem to check...

	umount references the in-core mount table instead of /etc/fstab...

Given that I submitted these in what I would now consider a timely manner,
seeing as 1.2 is STILL not out or, apparently, even close to a release,
I think I'm well within my rights to expect that these patches would be
committed, especially since I have received acknowledgment from Bug Central
that the associated PRs have been closed.  Unless, of course, the fixes
were deemed improper and the bug closed as a nuisance, which I don't believe
to be the case.

Curiously, why is there an "fsck_ffs"?  Do we plan on fsck'ing any other
kinds of filesystems?  Do we currently support "fsck_msdos"?  "fsck_xdos"?
"fsck_ntfs"?  For obvious reasons we don't "fsck_nfs" or "fsck_null"...
what's that leave us?

				--*greywolf;