[Opensim-dev] what are the core region modules? which are not?

[Melanie]

Currently, each module comes with a patch for prebuild.xml.

The extras directory won't fly because different modules need 
different references and even external stuff. I have a Linux build 
script I use that will combine selected modules with my tree. I can 
donate that.

Melanie


Stefan Andersson wrote:
> Some ideas and suggestions on <subject>
>  
> Instead of a one-off sweep, can't we just have this as some kind of regular scrutiny of what merits to be 'core' modules? Start with the obvious abandonware, then do sweeps every two version ups.
>  
> I'm actually very much for us concentrating more of our efforts into getting the 'basics' tightened up, so I'm very much for cleaning out unused or poorly implemented concepts.
>  
> That said, I would also suggest we set up a forge build server - something that would synthesize, build and runt tests on an 'extended' build file - containing all non-core, but 'approved extended modules'.
>  
> If there is a build error, there should be some kind of notification going out to that forge dev project group, and if nobody remedies the build error, that module is put up for removal from the 'approved' list (maybe simply by exclusion from the build server script) 
> Now, if an 'extension' module stops _functioning_ I believe that situation is exactly as it would be if it was included in core - the only thing having a module in core guarantees is that it's built, not that it is tested by the committer - so that would mean the module users would have to mantis a failure.
>  
> It would probably be a good thing if the module sub-projects would keep track of some kind of 'last known good' revision.
>  
> And, lastly, I believe that by grouping several modules into one or a small number of 'packages' the impact of core deviation would lessen, as more devs would have to configure less to have it installed.
>  
> By the way, I was thinking that we could have a in-place bogus project in Prebuild.xml called OpenSim.Modules.External residictng in /OpenSim/Modules/External, which prebuild would include /*.cs recursively.
>  
> That would mean that you could just check out a set of forge module sources into that directory - which prebuild would then just bundle together into one big fat glorious module dll, custom to your environment.
> Best regards,Stefan AnderssonTribal Media AB
> 
> 
> 
> Date: Mon, 9 Feb 2009 11:42:31 -0800From: cfk at pacbell.netTo: opensim-dev at lists.berlios.deSubject: Re: [Opensim-dev] what are the core region modules? which are not?
> 
> 
> 
> 
> SDague has a good point. And it gets a bit more interesting when one considers the OSSearch module, which did become non-functional a few days ago and folks have been scrambling and struggling to get their regions back in operation.It could be argued that bringing that active module, which is one small C# file into SVN might be to our advantage for the same reasons we are discussing here.Charles
> 
> 
> From: Sean Dague <sdague at gmail.com>To: opensim-dev at lists.berlios.deSent: Monday, February 9, 2009 11:30:59 AMSubject: Re: [Opensim-dev] what are the core region modules? which are not?Dahlia Trimble wrote:> When a module moves out of core and to forge, what process would be in place> to make sure these modules remain compatible when possibly breaking changes> are made to core? I use the IRC module in some of my regions and I wouldn't> want to see it broken, and I like to stay close to head in all of my regions> so I can be more aware of how development progresses. As such I would> potentially vote -1 on taking IRC out of core until there is some way to> maintain functionality as core evolves.I'm personally all for moving thinks to an Optional space, but we haveto be honest with ourselves, moving a module to the forge means thatthere is a better than 50% chance it's unusable in 2 weeks time.  Ithink for things we've considered "dead" that's fine, but I'd bereluctant to push 
bits out that people do regularly use (like the ircbridge).  At least until we have:1. an easy way to build an out of core module build tree2. network repository support for modules (ala what's in mono addins)3. some type of versioning on module interfaces, so we can know if aplugin thinks it can work with the current buildOtherwise we are more or less jetisoning a lot of features and reducingthe number of users that we can serve out of the box.  The same logicthat would leave these modules in the tree is the same logic that keepsall the extra stuff in bin/, to make it easy for the new user to getstarted.This shouldn't stop this current level of reorganization, which I thinkis very useful.  But is just a warning on next steps of removing thingsfrom the tree.    -Sean-- Sean Dague / Neas Badesdague at gmail.comhttp://dague.net
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev