On Sunday, 11 January 2004 at 0:12:57 +0100, Poul-Henning Kamp wrote: > In message <40007D14.6090205_at_freebsd.org>, Scott Long writes: >> All, >> >> I started RAIDframe three years ago with the hope of bringing a proven >> and extensible RAID stack to FreeBSD. Unfortunately, while it was made >> to work pretty well on 4.x, it has never been viable on 5.x; it never >> survived the introduction of GEOM and removal of the old disk layer. >> [...] >> I have a Work-In-Progress for converting and integrating it into GEOM >> on my home Perforce server. It hasn't been touched in several months >> and I really don't see myself being able to finish alone it in the near >> future. Since it's been hanging over my head for so long, I'm very, >> very close to just removing it and moving on. > > I can't help thinking about how small the central group of developers > in FreeBSD is, and considering that you also carry the armoured > release-engineer hat, I am fully able to understand why you have > not been able to pull RF along in addition to all the other stuff. > > As much as I would hate to see RF and Vinum disappar from our > source tree, maybe what we need to do is to kick them both into > "training-camp" in p4 while you and Greg look the other way. Hmm. I can't see why they have to disappear from the source tree, and I don't see why Scott or I should have to look the other way. I don't know about RAIDFrame, but Vinum still works for the most part: apart from a couple of recently reported bugs, as well as a number of long-standing ways to shoot yourself in the foot, the only problem I know is that swap on Vinum no longer works. I had hoped to get something done about that, but it requires changing the interfaces to disk(9), and I don't have the time. > In the p4 tree, we can easier add new talent to our developer force > and I am pretty sure that some sort of merry band of developers > would form around both RF and vinum there. OK, I'm not a fan of p4, but I suspect that's not the issue. This sounds like a way of suggesting "Let's do VinumNG and RFNG and get a whole lot of people involved". I couldn't agree more. > I am not convinced that they may be able to pull off the task, but > the fact that somebody at least tries should give us better chances > than having RF stuck in your TODO queue, and vinum stuck in Gregs, > while everybody else waits more or less paitiently. Mainly less :-) I've been trying to encourage people to look at Vinum for some time. It's a relatively complicated piece of code, and something about it seems to scare people away. That's unfortunate, because the complex parts are also those that work the best. The crap around the outside, like configuration management, was slated for replacement about 4 years ago, but it never happened, though it's relatively simple code. It's gradually getting more stable, but it's a long way from being good. > Because we might as well be honest and face it: Neither you nor Greg > has much chance of finding the significant amount of time that you > need. At least from my point of view, that's absolutely correct. > I know this can be seen as you and Greg throwing in the towel, Not to me. > but I urge you to try to see it like saw my Junior Kernel Hacker > list: Throwing a good meaty bone to pick which I myself couldn't eat > anyway. Yes, that's the way I've seen it for some time. Any ideas how to excite people? Do you want to say something? Something like "If phk and grog agree, it must be right"? :-) > I'd say lets kick them both into perforce and let whoever wants > their hands have a go at them. For some definition of perforce, I'm all for it. Note that there's also an OS-independent mailing list (see http://www.auug.org.au/mailman/listinfo/vinum-devel for joining instructions). Greg -- See complete headers for address and phone numbers.
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:37 UTC