Hi Chris, On Sat, Oct 10, 2009 at 4:26 PM, Chris 'Xenon' Hanson <xe...@alphapixel.com> wrote: > I feel for your situation. I'm not very fond of getting torn between coding > and the > other side of business. I'd much rather code.
Curiously I'm torn between coding and coding, just that one side is client focused and the other is community focused. I'm lucky to be in the job/role that I do that both sides I'm working on open source code that we all get to benefit from ;-) > Well, the question still stands -- do you want to pursue a more distributed > code > submission review, acceptance and commit process, even if you are aiming to > reduce your > own work overcommit? Reviewing submissions is a double edge sword, as without keeping tabs on what is happening with the code I'm in poorer position to do support and fix bugs. Reviewing submissions is actually it's not the most burdensome side of my work as project lead. Driving releases forward and ongoing maintenance is a burden that takes big blocks of my time, and is not something I can do on a drop feed basis like I can with general submissions. The idea of have a range of engineers to have write access to branches and with the ability to taken the driving seat with making stable releases is something we discussed and put into place around a year ago. Alas apart from Paul Mart'z 2.6.1 release there hasn't been any impetus from the community to drive this forward. The key point is that I was trying to step back from having to be the impetus behind releases and to allow others to take the reigns. You are welcome to step up to the plate and help out with driving releases, we can get you write permission to the branches section of the wiki - we just need Jose Luis to add permission for you. In terms of write access to svn/trunk this is only I think is most appropriate for specific areas of the code base that become a particular or group of persons responsibility and take ownership of. For a release it's a bit different as the person driving is taking responsibility for the whole release. Whereas just granting general svn/trunk write access means that we'll have multiple people dabbling all over the code base with no one single person taking responsibility for it. Knowing that you are directly responsible for something makes you think twice about what you do and makes you strive harder to fix it when it breaks. I am also concerned about the evolution of the code base, if you have multiple people with write access it can potentially start drifting apart in different ways, and holding a cohesive whole could become more difficult. Even highly experienced and talented engineers will disagree on stuff, will take different routes to solve the same problem. I often make decisions on submissions that have a whole history of the life the OSG and where I see it going next. I might have vocalised my thoughts on the wiki or on email discussions on the list, but is such a disparate collection of threads and influences that it's impossible to track things in a way that you'll know what to do to be in keeping with what I do in the same case. Even what seems to be a benign submissions can trigger me to go refactor a part of the OSG due to an wider issue it raises, or spot a bug or a potential cross platform issue. Others engineers will spot different bugs from me too, but typically it'll be much more focused in scope to the code in hand as they won't have the some OSG code base perspective that I do, doing sweeping refactors like I do from time to time isn't that I would expect others to do or wish to do - even when it'd be the most appropriate thing to do. For these reasons I'm more inclined to believe that having a single gate keeper of the source is far more of an asset that it is a bottleneck. Cheers, Robert. Robert. _______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
