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

Mon Feb 9 23:42:15 UTC 2009

Stefan Andersson wrote:

> 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'.
>   
(...)
> 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

well if there are indeed tests for that functionality, they ought to be 
run by committers (and are run and reported by the server too), so that 
breaking things without knowing would not happen.

i figure running tests of the non-core but living modules might work 
well if it can be setup somehow. one neat feature in svn is external 
repos that let you combine many repos into one so that you get them all 
with one update command.

Melanie wrote:
> 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 
>   

i wonder if you could help keeping such modules functioning by writing 
tests for the parts of the api that they depend on .. perhaps you can 
test what they assume from opensim without having the external stuff.

versioning sounded like a good idea too, but don't know whether it's the 
time for that and would it be practical really.

this is an issue for modrex too, where already the guys had to do some 
refactor now due to changes in the core. hopefully the situation can be 
helped with tests there for the future.

> Melanie
>   

~Toni

>> 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
>>     
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>   