Chris 'Xenon' Hanson wrote:
While I'm very opposed to the "nasty merge" part, I don't have any need to force any sort of branches or releases myself. I'm simply trying to look out for the continued maintenance of the entire trunk.
I, too, would like to see some increased bandwidth in handling trunk submissions, but I don't think inexperience community members are the answer.
With the advent of interesting new OpenGL flavors, and the desire (or even client-funded requirement) to port to them, balancing the traditional types of submissions with major redesign and porting efforts is going to be tricky. Core OSG must naturally increase in complexity in order to support new OpenGL flavors, which means that Robert's central gateway for change review is needed more than ever before. He even pointed out, in a post on this thread, the benefits he's able to provide when reviewing even a trivial submission, due to his extensive knowledge of the code.
The alternative would be to make OSG less complex, so that it's easier to maintain. This has been my recommendation in the face of GL3: That we should use GL3 as an opportunity to clean up and simplify OSG so that it is tuned for GL3. The resulting code base would be smaller, less complex, and easier to maintain. Of course I'm aware that this has the downside of very painful application ports to the newer/cleaner OSG API, and it would preclude supporting other OpenGL flavors. In order for OSG to remain a single API that supports multiple OpenGL flavors, Robert has made the only viable choice with his present approach. This means we have an increased dependency on Robert and his experience to review code changes made against an increasingly complex OSG code base.
Paul Martz Skew Matrix Software LLC _http://www.skew-matrix.com_ <http://www.skew-matrix.com/> +1 303 859 9466 _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
