Hi Robert and all, This is a really interesting topic. I haven't read all the posts yet, so please forgive me if my thoughts were already suggested.
2010/2/25 Robert Osfield <[email protected]>: > o No ones added there name to list of volunteers yet: I'd like to take care of the serialization parts and the osgt/osgb plugins. But it seems I don't have the permission to edit the volunteers page. Should I obtain an ID from Jose first? > o We are proposing an influx of contributors with commit access to various > parts of the OSG and > they don't yet have experience of doing this w.r.t the OSG, it probably > is quite risky way for them to > cut their teeth. The risk is born by us all, and any teething problems > could cost much more time > in short term. Given I'd like to get a stable release in the not too > distant future this clearly ups > the risk on getting this out promptly. > > I there think it would probably be best to having a stagging > area/experimental branch for those > becoming maintainers. But... to have this we have to have a better > system for merging from the > branches. A considerable portion of submissions are examples and plugins, and modifications on them. And at present we already have 145 examples and 74 plugins in the svn/trunk, and the number is sure to continue growing, which leads to a heavy burden upon maintainers. I would suggest divide the whole source code into 3 projects: OpenSceneGraph-Core, OpenSceneGraph-Examples and OpenSceneGraph-Plugins. A few important and stable examples and plugins will still be placed in the core project directory, for instance, the osg, ive, curl, bmp, png, jpeg and freetype plugins. And the latter two projects include unstable and experimental ones, for more contributors to submit or import their code directly. Core developers don't need to care much of them, and just add a CMake option BUILD_UNSTABLE to help developers select examples and plugins they are interested in. This will reduce the code and dependencies checking time of core OSG directory and give more flexible decisions for building executions and libraries. Of course it won't solve the problem of handling submissions from everywhere, but will at least reduce the complexity, in my opinion. And I'll suggest split up the examples into catagories, again, which is mentioned before. We could divide the examples directory into multiple subdirectories, each representing a kind of demonstrations, like "animations", "viewers", "widgets", "effects" and so on. Regards, Wang Rui _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
