In message <[EMAIL PROTECTED]>, "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@ 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 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. _______________________________________________ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"