I dont know if refactoring in a branch is necessary or is all that easy to do with our current SVN system. I think the communication channels we have now (IRC, this mailing list) generally work fairly well. There have been a few times where I wanted to work on a certain area of the code, i.e. physics, and I need to work off of trunk otherwise I may not be able to commit my changes as they would be incompatible. If breaking changes are coming down the pipe then I can work around them if the communication channels are working. So far the longest I've had to wait before attempting any changes has been maybe 8 hours and I've been able to do something else in the meantime so it was not wasted time. I don't know if other open source projects have any better ways of managing these types of issues.. perhaps this could be the subject of another thread.
Anyway, +1 on the changes and if it breaks anything, please offer an update about when things return to normal (whatever normal means). On Thu, Apr 30, 2009 at 10:10 AM, <[email protected]> wrote: > Around now, or last week, would probably be a good time to tag something > stable :-) > > I don't mind at all moving this refactoring to a branch, but since we have > never done that I wouldn't even know what to do. I don't expect this to be > bad. The transition to RESTComms was done without almost anyone noticing it, > except the brave explorers in OSGrid who have to deal with having neighbors > on all sorts of different versions. But except for the version mismatches, > which are really impossible to manage from a development perspective, most > people only noticed when suddenly OpenSim.ini didn't have the remoting port > anymore. And RESTComms actually involved a complete replacement of the > underlying protocol from Remoting to http+REST, which is not the case here > -- the protocol won't change, at least not now. > > Charles Krinke wrote: > > It is always a balance between keeping functionality in an evolving > project and refactoring and experimenting. > > I will support and encourage refactoring and experimentation with one > proviso. That proviso is a few paragraphs on the wiki giving clues to allow > those deploying OpenSim what is going on and how to work around trunk during > a period of refactoring and experimentation. > > Charles > > ------------------------------ > *From:* Mike Dickson <[email protected]> <[email protected]> > *To:* "[email protected]" <[email protected]> > <[email protected]> <[email protected]> > *Sent:* Thursday, April 30, 2009 8:57:24 AM > *Subject:* Re: [Opensim-dev] moving away from grid vs. standalone > > I'll echo a sentiment I've tried to express before. This sort of > aggressive refactoring and experimentation is really important to the > growth of OpenSim. The "release" process has been focused on trying to > figure out a stable point and snapshot-ing that. That places a burden on > the "release coordinator" to poll folks for what that stable "snapshot" > is. IMO, ideally the heavy refactoring would happen on a branch or > separate tree and then pushed to HEAD when it stabilizes. > > Again, I'm completely for the heavy research and refactoring focus. > But IMO if for a shared project you want to do that you need to adopt a > development approach that gracefully allows that to happen. > > Mike > > > On Thu, 2009-04-30 at 15:37 +0000, Dahlia Trimble wrote: > > We need to be careful about how things are broken and make repairs > > expeditiously as we also hinder other developers if they are unable to > > use their regions for development and testing. > > > > On Wed, Apr 29, 2009 at 3:01 PM, Melanie <[email protected]> wrote: > > Maybe these things need to be broken. We are almost locked > > into a > > rigid schema, now we still have a chance to go to true > > modularity > > and we should take it. After all, trunk is meant to be > > broken :) > > > > > > Melanie > > > > _______________________________________________ > Opensim-dev mailing list > [email protected] > https://lists.berlios.de/mailman/listinfo/opensim-dev > > ------------------------------ > _______________________________________________ > Opensim-dev mailing > [email protected]https://lists.berlios.de/mailman/listinfo/opensim-dev > > > > _______________________________________________ > Opensim-dev mailing list > [email protected] > https://lists.berlios.de/mailman/listinfo/opensim-dev > >
_______________________________________________ Opensim-dev mailing list [email protected] https://lists.berlios.de/mailman/listinfo/opensim-dev
