Future of RAIDFrame and Vinum (was: Future of RAIDFrame)

[Poul-Henning Kamp]

In message <20040112142528.GA15906 at zibbi.icomtek.csir.co.za>, John Hay writes:

>> >But, in the real world of software engineering, He Who Breaketh It,
>> >Must Fixeth It.
>...
>> In a free software project, you can take any rule like that an put
>> it anywhere you like, in any font, size and color of your choice
>> and it still wont work.
>
>I don't think it is totally true. If a free software project have
>enough power to give and revoke commit bits and to make rules...

N% of the work in FreeBSD is done by 100-N% of the committers, for
some value of N.

This fraction of people and new people inducted into that elite
statistic are obviously rather crucial to the future of FreeBSD.

If you insist on putting a rule down which make it impossible to
work on any sort of infrastructure in the FreeBSD kernel without
inheriting every single lump of code anybody ever managed to check
into our CVS, then I think most people in this caliber can find
better things to use their spare time on.

Isolated features with a small user-communities, things like vinum,
raidframe, appletalk, bluetooth, MAC and similar, needs to come
with developer resources for its own maintenance, and vinum currently
comes up short in this respect.

_THAT_ is the problem we need solved, we don't need more arm-chair
inspired pseudo-management rules for monkey-throwing.

As you can hear, I am getting pretty sick and tired of the "Vinum
is important to me and/or the project so _you_ have to fix it"
refrain.

I can tell you with 100% certainty, that no matter what I do, I
will not be fixing vinum in my own spare time.  If somebody wants
to pay me to do it, then it is a different thing, I'll do anything
for money (well... almost anything): contact me, my rates are very
reasonable.

And I will say it one last time:  If you want vinum to have a future,
you should rally behind whatever Greg organizes for the purpose of
getting vinum into shape and contribute to that.  That is the only
way it will happen.

In the mean time, FreeBSD needs to move forward with the SMPng work,
even if that means breaking vinum further until Gregs team catches
up.

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.