Hi Chris, On Mon, Feb 22, 2010 at 10:03 PM, Chris 'Xenon' Hanson <[email protected] > wrote:
> I have said before that I think it would be nice if code submissions could > be made via > SVN somehow, maybe to a 'scratch' or 'working' tree, and from there, > migrated to the real > codebase by approval, or reverted. I don't know if SVN really facilitates > this, or if > something else might, but (despite the existence of the osg-submissions > list, which you > may recall, was one of my suggestions) I think the submissions process > could be improved a > lot AND make your life easier. Really. No more diffs, weird e-mail > attachment problems, > etc. Changes would have to be against current versions of the source. > Subversion is really poor at this. I tried with Cedric Pinson having his osgAnimation branch and me merging in changes, and him trying to keep track of other changes. It was far more work trying to keep subversion in check and avoid screwing up. The best solution ended up discarding this branch and having Cedric work directly on svn/trunk. > I know you don't like issues trackers/queues, but I think you're in the > minority there. > Many people I know would like to be able to record bugs for which fixes > aren't currently > available, or requests that can't be currently satisfied. As well, being > able to follow > the lifespan of an issue is nice, and having all submissions in one place > along with their > respective problems and supporting data is also effective. Virtually every > large project I > work on uses this process pretty successfully and would fall apart without > it. It also > gives non-core people an idea of what they might be able to work on to > contribute. > > GDAL seems to have a pretty good process on a lot of these techniques. > > Perhaps another role, that of issue maintainer(s) could help this out. > Some system really do make a big difference with productivity, some work against it, and some the cost/benefit ratio is pretty close to breaking even. The ticketing/bug tracking isn't something that will make a big difference, at best the cost/benefit ratio will be close to breaking even if we get it right, if we get it wrong then the cost will exceed the benefit. In terms of the overall OpenSceneGraph ecosystem the cost/benefits aren't evenly distributed. If there are elements that are overloaded then these are the areas where we need to minimize the costs and maximize the benefits, while parts that aren't overloaded we can accommodate a little increase in cost w.r.t benefit and not have the overall system start to struggle. If there is any doubt that the "new" system is going increase me load on me than I'm not going to volunteer to go down this route, it's not good for me personally, and it wouldn't be good for the wider project as we can't suddenly throw a switch and not rely on me so much. Perhaps in a point in the future when I'm able to safely scale down my workload to a point that I spend time learning new systems and helping maintain them, but right now any new systems has to have a very clear improvement to the benefits and low cost associated it. Robert.
_______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
