Re: requesting vinum help

In message <447049543.1069836265_at_[192.168.1.20]>, "Joel M. Baldwin" writes:

>I was trying to use some restraint and not rant and rave in public like
>I wanted to do.  I'm rather miffed that nothing appeared in UPDATING.
>Rather than an unproductive public RANT I thought I'd ask for private assistance.
>I can post a summary afterwards if you like, or even better write a better
>FAQ/tutorial on vinum.

Joel,

The problem is that vinum is hot political potato in the project.

In the eyes of a fair number of competent people, vinum has never
quite "made it".  I think most of them have given it a shot and
lost data to it.  Some of them, after looking in the code to "fix
the problem", said "never again!" and now hate vinum of a good
heart.

Greg has disclaimed maintainership of vinum some time ago for reasons
of politics, and he now is of the opinion that it is everybodys
(elses) task to maintain vinum.  Everybody else disagree and belive
that "vinum is very much Gregs own problem".

With Greg being a core_at_ member, and well known for his ability to
talk an acturan megadonkey into taking a stroll after first having
talked its legs off about procedural issues, "Doing something about
vinum" is permanently on the "we should really..." list and everybody
hopes somebody else will "deal with it".  Of course, in the end
nobody does.

As matters stand, we are doing our users a disservice by continuing
to pretend everything is OK when in fact it is not at all.

Personally, I think vinum(8) should not be in our 5-STABLE featureset
if it is not brought up to current standards and actively maintained.

But at the very least we should have the release notes reflect that
vinum is unmaintained and belived to unreliable and have vinum(8)
issue a very stern warning to people along those lines.

I'm sure that a major bikeshed will now ensue and people will argue
that there is a lot more to this dispute than what I've said above.

They're right of course, this is a very short summary :-)

Poul-Henning

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk_at_FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.