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

From: Poul-Henning Kamp (phk_at_phk.freebsd.dk)
Date: 01/12/04

  • Next message: Daan Vreeken [PA4DAN]: "Release USB WLAN driver version 0.2 - testers wanted"
    To: John Hay <jhay@icomtek.csir.co.za>
    Date: Mon, 12 Jan 2004 16:04:01 +0100
    
    

    In message <20040112142528.GA15906@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@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.
    _______________________________________________
    freebsd-hackers@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
    To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"
    

  • Next message: Daan Vreeken [PA4DAN]: "Release USB WLAN driver version 0.2 - testers wanted"

    Relevant Pages

    • Re: vinum related panic in 5.1-BETA2 (long backtrace)
      ... > I got this panic while running a cvs checkout of a part of the FreeBSD ... > source tree. ... Debug kernel and coredump is available if you need more info. ... If you need to contact me because of problems with Vinum, ...
      (freebsd-current)
    • Re: Large filesystems help/ideas
      ... vinum should not be used on 6.x and above, ... I understand that I could have up to 8 slices of 2 Tb, ... I've tried to install FreeBSD 7 with no success, ... Université Libre de Bruxelles (ULB) ...
      (freebsd-questions)
    • Re: The true meaning of / or root partition??
      ... > commercial UNIX systems have had these features for a while, ... in the form of vinum. ... FreeBSD is more on less in par with Linux in this domain featurewise. ...
      (comp.unix.bsd.freebsd.misc)
    • Re: Future of RAIDFrame
      ... >and extensible RAID stack to FreeBSD. ... I can't help thinking about how small the central group of developers ... As much as I would hate to see RF and Vinum disappar from our ... Greg has much chance of finding the significant amount of time ...
      (freebsd-current)
    • Re: Future of RAIDFrame
      ... >and extensible RAID stack to FreeBSD. ... I can't help thinking about how small the central group of developers ... As much as I would hate to see RF and Vinum disappar from our ... Greg has much chance of finding the significant amount of time ...
      (freebsd-hackers)