<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
</style>
</head>
<body class='hmmessage'>
Some ideas and suggestions on <subject><BR>
<BR>
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.<BR>
<BR>
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.<BR>
<BR>
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'.<BR>
<BR>
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) <BR><BR>
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.<BR>
<BR>
It would probably be a good thing if the module sub-projects would keep track of some kind of 'last known good' revision.<BR>
<BR>
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.<BR>
<BR>
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.<BR>
<BR>
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.<BR>
<BR>Best regards,<BR>Stefan Andersson<BR>Tribal Media AB<BR><BR><BR>
<HR id=stopSpelling>
<BR>
Date: Mon, 9 Feb 2009 11:42:31 -0800<BR>From: cfk@pacbell.net<BR>To: opensim-dev@lists.berlios.de<BR>Subject: Re: [Opensim-dev] what are the core region modules? which are not?<BR><BR><BR>
<STYLE>
.ExternalClass DIV
{;}
</STYLE>
<DIV style="FONT-SIZE: 12pt; FONT-FAMILY: arial,helvetica,sans-serif">
<DIV><BR></DIV>
<DIV style="FONT-SIZE: 12pt; FONT-FAMILY: arial,helvetica,sans-serif">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.<BR><BR>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.<BR><BR>Charles<BR><BR>
<DIV style="FONT-SIZE: 13px; FONT-FAMILY: arial,helvetica,sans-serif"><FONT face=Tahoma size=2>
<HR SIZE=1>
<B><SPAN style="FONT-WEIGHT: bold">From:</SPAN></B> Sean Dague <sdague@gmail.com><BR><B><SPAN style="FONT-WEIGHT: bold">To:</SPAN></B> opensim-dev@lists.berlios.de<BR><B><SPAN style="FONT-WEIGHT: bold">Sent:</SPAN></B> Monday, February 9, 2009 11:30:59 AM<BR><B><SPAN style="FONT-WEIGHT: bold">Subject:</SPAN></B> Re: [Opensim-dev] what are the core region modules? which are not?<BR></FONT><BR>Dahlia Trimble wrote:<BR>> When a module moves out of core and to forge, what process would be in place<BR>> to make sure these modules remain compatible when possibly breaking changes<BR>> are made to core? I use the IRC module in some of my regions and I wouldn't<BR>> want to see it broken, and I like to stay close to head in all of my regions<BR>> so I can be more aware of how development progresses. As such I would<BR>> potentially vote -1 on taking IRC out of core until there is some way to<BR>> maintain functionality as core evolves.<BR><BR>I'm personally all for moving thinks to an Optional space, but we have<BR>to be honest with ourselves, moving a module to the forge means that<BR>there is a better than 50% chance it's unusable in 2 weeks time. I<BR>think for things we've considered "dead" that's fine, but I'd be<BR>reluctant to push bits out that people do regularly use (like the irc<BR>bridge). At least until we have:<BR><BR>1. an easy way to build an out of core module build tree<BR>2. network repository support for modules (ala what's in mono addins)<BR>3. some type of versioning on module interfaces, so we can know if a<BR>plugin thinks it can work with the current build<BR><BR>Otherwise we are more or less jetisoning a lot of features and reducing<BR>the number of users that we can serve out of the box. The same logic<BR>that would leave these modules in the tree is the same logic that keeps<BR>all the extra stuff in bin/, to make it easy for the new user to get<BR>started.<BR><BR>This shouldn't stop this current level of reorganization, which I think<BR>is very useful. But is just a warning on next steps of removing things<BR>from the tree.<BR><BR> -Sean<BR><BR>-- <BR>Sean Dague / Neas Bade<BR><A href="mailto:sdague@gmail.com">sdague@gmail.com</A><BR><A href="http://dague.net/">http://dague.net</A><BR><BR><BR></DIV></DIV></DIV></body>
</html>