On Tue, Dec 07, 2004 at 10:06:22AM +0800, Ender wrote: > As far as all this goes, I have a few suggestions. > > First, no offence to Luke-Jr, but I've ran into a lot of compilation > glitches with GammaMoo and its code-quality isn't all that great. I'd > suggest either starting from the current Lambda CVS and merging > third-party patches for a 2.0 release or taking Foo (which has always > compiled on everything I tried it on, at least :).
Well, that's good to know. It compiles on everything I can find to test it on, although it can get a little wonky on Alpha (but no more or less wonky than the "official" LambdaMOO 1.8.1) > Whether this is accomplished by taking control of the current SF > project, or creating a second one is the first decision that needs to be > made. Well, as for taking control, the thing is... nobody in that project is anything approaching active. We'd have to ask them now, and come back in 4 years to read their response. > The current SF project would have worked quite well, if patches in the > patch tracker were ever actually looked at. That said, since I see a lot > of the initial work to be simply gathering patches and improvements into > the one central codebase the first couple of developers really just need > to be decent coders who have enough time to actually look at the > patches. Agreed. > Initially I'd suggest: > * Two project admins for sanity (I elect hpa and dive) I would be more than willing - having to try and keep track of all the "neat" features I want from various server codebases and merge them without making lambda+foo an unrunnable PITA is more work than coordinating an effort in this direction, IMHO. > * Two or three developers to vet and commit patches and diffs. Sounds good, although I would up that to perhaps four or five, and add something like "and test the living **** out of the patches to make sure they're stable enough" > * Someone coming up with a moo-code core to regression-test the server That shouldn't be difficult. > * People making diffs Very good thing to have, that :) > Most of the development should initially be recommendations/diffs of > code to merge. As long as quality-of-code is maintained and nobody runs > out of time to merge or make patches, CVS should get up to scratch > pretty quickly. And if the regression-core is ready, then all is good. > > Furthermore, I'd suggest that 2.0 have a 'plugin' system, for > registering builtins by loading shared objects listed in a config file > (Eg, LoadModule FUP). I'm hoping that everyone has posix dlopen() > support or a wrapper by now? :) I should hope they do. And I agree with that suggestion. -Sean -- /~\ The ASCII \ / Ribbon Campaign Sean Davis X Against HTML aka dive / \ Email! ############################################################# This message is sent to you because you are subscribed to the mailing list <[EMAIL PROTECTED]>. To unsubscribe, E-mail to: <[EMAIL PROTECTED]> To switch to the DIGEST mode, E-mail to <[EMAIL PROTECTED]> To switch to the INDEX mode, E-mail to <[EMAIL PROTECTED]> Send administrative queries to <[EMAIL PROTECTED]>
