I feel that we should view trunk as our best effort at a functional code base with no guarantee. The most important thing is that it should compile. Beyond that, new checkins that add new features should be explained to the early adopters and testers that are wringing out the details and finding the bugs. Hence my plea for *something* written *sometime*.
Our early adopters and testers are our partners in this endeavour. They provide the feedback to the developers and the rest of the community about confidence on Windows/Linux variations, existing inventories, standalone versus grid deployments and regression. This means that in order to have the best efficiency at OpenSim development, a few clues in the form of blogs, wiki paragraphs or even single FAQ entries helps immensely and cuts down on the time the developer has to spend supporting his or her creation. It is entirely reasonable for a developer to enlist help from a member of the community to write those blog, wiki or FAQ entries, and I would urge us all to do so. Charles ________________________________ From: Melanie <mela...@t-data.com> To: mike.dick...@hp.com; opensim-dev@lists.berlios.de Sent: Tuesday, May 19, 2009 9:47:19 AM Subject: Re: [Opensim-dev] breaking OpenSim.ini changes MW pretty much reached the conclusion never to use a branch again. It was stated that trunk is a developers' WORK area. It is not meant to be usable all the time. The only requirement is that it compiles. People who want stable should use stable. I think demands that trunk remain usable sets a bad precedent. Melanie Mike Dickson wrote: > On Tue, 2009-05-19 at 16:32 +0000, Melanie wrote: >> So you say I should spend hours on documentation which I already >> KNOW it will be obsolete within days? >> >> That _is_ just what big corps do. 20% dev time, 80% doc time. >> >> Melanie > > If you're so sure you're going to see that much churn in what you're > doing maybe it should be done in a branch as MW was trying to do so you > spare the rest of the community while you figure it out. Then you can > properly document it when its stabilized and roll it into HEAD when its > ready. > > BTW, the refactoring is *really good work*. OpenSim is a great project > with lots of potential. Just wish it had more discipline (which doesn't > have to translate to only 20% coding time). > > Mike > > > > _______________________________________________ > Opensim-dev mailing list > Opensim-dev@lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > > _______________________________________________ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
_______________________________________________ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
