Re: [osg-users] SVN commit bottleneck
Hi all, sorry for coming late... just some thoughts, I don't claim to have all the answers... Chris 'Xenon' Hanson wrote: Paul Martz wrote: I am booked 100% with client work, and if my clients are content on the current release, and there are no pending new features that the clients need, then I have no funding or availability to support a new stable release. And that's totally reasonable. I also don't have time to admin releases, but would gladly test a trunk+patches tree and provide feedback if one existed and I could easily get hold of it. Ultimately, Chris, if you have a need for a stable release, or even a need to get your changes into a branch that will eventually lead to a stable release, then you have just volunteered. :-) Actually, while I _am_ volunteering, it's not because I need a new release. Anybody I'm working with right now can build from source with patches I send. But, I dislike seeing the trunk get stale and fragmented, so I want to ensure that we hold together a community release protocol. We are also running trunk with manual patches and I don't like it. If many people do this, it also means we are duplicating a lot of work and testing. If I'm not mistaken, we can branch the trunk either right now, or just prior to the start of Robert's GL ES2 work, and Chris could add his changes to the branch, and that branch could eventually lead to a 2.10 stable release. Robert's trunk work could eventually lead to a 2.12 release. The downside of this is there might be a potentially nasty merge in there somewhere. Robert, Chris: Thoughts? 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 see two approaches with releases: 1) branch trunk, add patches to branch, make release from branch 2) branch trunk, add patches to branch, merge changes to trunk, make release from trunk. I like 2 more, which means the trunk gets up to date when Robert has time to merge patches from the branch (this is almost like the staging or -mm trees in the linux kernel) and Robert knows what has been merged. The only change from the current way of working is that users have some way to test patches without applying it themselves. So instead of saying try the trunk version ... one can say try the staging version and report if it fixes your problem. If feedback is received on patches working, and this info is visible in some way [*], Robert could more easily merge these back to trunk (we will need some way to cherry pick patches). [*] This relates to issue tracking in some way. Currently the only way to know if a patch has been applied is to read osg-submissions or browse code. I think Robert tracks patches (Robert, correct me if I'm wrong) by just using his inbox, but this does not scale to more than one person applying fixes. regards jp Paul Martz Skew Matrix Software LLC _http://www.skew-matrix.com_ http://www.skew-matrix.com/ +1 303 859 9466 -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. MailScanner thanks Transtec Computers for their support. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] SVN commit bottleneck
Hi Paul el. al, On Thu, Oct 22, 2009 at 5:13 PM, Paul Martz pma...@skew-matrix.com wrote: If I'm not mistaken, we can branch the trunk either right now, or just prior to the start of Robert's GL ES2 work, and Chris could add his changes to the branch, and that branch could eventually lead to a 2.10 stable release. Robert's trunk work could eventually lead to a 2.12 release. The downside of this is there might be a potentially nasty merge in there somewhere. Robert, Chris: Thoughts? Just for clarification, I'm not a significant way through the OpenGL ES 2.0 port, and all my changes have been done against svn/trunk, and save for a few more changes that I made yesterday afternoon all my work is already in svn/trunk. Originally I was planning to make a branch of the OSG to do the OpenGL ES 2.0 port, then merge back in the changes, but as I got into port I found ways of minimizing the code differences between the various targets, and managing the differences in ways that well encapsulated - the upshot of this was I have been able to undertake the port with far less intrusive changes to the API and the implementation. In fact the public API itself is hardly changing at all and we may even be able to have an ABI compatible OSG across the range of OpenGL targets. If my current progress on the port keeps up we could well see the bulk of the port done and checked in by the end of this month. The door will be opened to supporting OpenGL ES 1.x, and OpenGL 3.x with relative ease, and see no reason why both of these wouldn't achievable in November and be rolled into a stable release before Christmas. To do the OpenGL ES 1.x and OpenGL 3.x ports I'll need assistance from the community, but once I've got the framework for supporting multiple OpenGL targets in the OSG it should far easier for others to dive in and help out. During next month I also plan to catch up with submissions get the OSG svn/trunk in a shape primed for a stable release. Should this stable release be 2.10, or... 3.0, we'll if we get OpenGL ES 1.x, 2.0 and OpenGL 3.x support working then I am beginning to think that it's a big enough step forward to call it OpenSceneGraph-3.0. Curiously the API for the next release will actually be pretty close to that of 2.8, and the rest of the 2.x series for that fact, so porting to 3.0 would probably be easier than that of OSG-1.x to OSG-2.x. Such an decision on a 3.0 would mean that we'd leave out the major API refinements for doing shader composition etc. for later rev's of the OSG, but perhaps even these might be doable without major changes to the public API, as the OSG API has already turned out to be far more resilient to accommodating new functionality than I had ever expected. I guess evolution rather than revolution for software development is often the most practical and productive way forward. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] SVN commit bottleneck
Hi Robert -- Robert Osfield wrote: Just for clarification, I'm not a significant way through the OpenGL ES 2.0 port, I think you're intending to say that you're almost done with the port. Ahead of schedule, right? If my current progress on the port keeps up we could well see the bulk of the port done and checked in by the end of this month. The door will be opened to supporting OpenGL ES 1.x, and OpenGL 3.x with relative ease, and see no reason why both of these wouldn't achievable in November and be rolled into a stable release before Christmas. To do the OpenGL ES 1.x and OpenGL 3.x ports I'll need assistance from the community, but once I've got the framework for supporting multiple OpenGL targets in the OSG it should far easier for others to dive in and help out. I'm on board for doing/helping with the GL 3 port, I have funding for that work. My schedule called for this to commence early next year, but if you've already got GL ES 2 done by start of November, then I'll try to set aside a week to catch up with your changes and work on this task. -Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] SVN commit bottleneck
Hi Paul, On Fri, Oct 23, 2009 at 4:10 PM, Paul Martz pma...@skew-matrix.com wrote: Robert Osfield wrote: Just for clarification, I'm not a significant way through the OpenGL ES 2.0 port, I think you're intending to say that you're almost done with the port. Ahead of schedule, right? Oh my, another one of my classic typo's that totally changes the meaning of a sentence... not should have been now. 't' isn't even that close to 'w', so I can only guess that my brain and fingers got disconnected somewhere along the line. I'm on board for doing/helping with the GL 3 port, I have funding for that work. My schedule called for this to commence early next year, but if you've already got GL ES 2 done by start of November, then I'll try to set aside a week to catch up with your changes and work on this task. I'm actually expecting the basic GL3 port to be little more than providing the support for OpenGL 3.0 graphics context, as pretty well everything else required for GL3 is also require for GLES2 - they both have to use vertex attribute arrays and application provided uniforms for projection and modelview matrices, and have to have the fixed function pipeline disabled. I already have in place the support for mapping standard vertex arrays to vertex attrib arrays and the modelview and projection uniforms. In stead of gl_Vertex and gl_Color you automatically have osg_Vertex and osg_Color etc, and instead of gl_ModelViewMatrix and gl_ProjectionMatrix you get osg_ModelViewMatrix and osg_ProjectionMatrix etc. There is also support in svn/trunk for automatically converting gl_Vertex/gl_ProjectionMatrix/ftransform() shader usage into osg_ equivalents so you can directly reuse many shaders that work from GL 2.0 in GLES 2 and GL3. The new osgvertexattributes example has been the test bed that I've used for this work. Going beyond the basic GLES2 and GL3 support will require us to look at how to neatly map the existing fixed function pipeline classes like osg::Material/osg::Light etc. to osg_ uniforms and associated shaders and how to map the fixed function pipeline modes to uniforms. I have a few ideas in this direction but expect them to be fleshed out once we have the basic GLES2 and GL3 compatibility. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] SVN commit bottleneck
Sorry to chime in late on this. Chris 'Xenon' Hanson wrote: It seems like we don't have any capacity in this regard right now. I'll shorten the question -- other than Robert, who does have SVN commit access? I am booked 100% with client work, and if my clients are content on the current release, and there are no pending new features that the clients need, then I have no funding or availability to support a new stable release. Most recently (yesterday), I branched 2.8.2 to put in a single fix to enable MSFBO on OS X for a client. But that was hardly what I'd call a release. Just a quick fix to help make 2.8.2 usable for them, without incurring the cost of a full blown 2.10 and all the associated testing and verification. Ultimately, Chris, if you have a need for a stable release, or even a need to get your changes into a branch that will eventually lead to a stable release, then you have just volunteered. :-) If I'm not mistaken, we can branch the trunk either right now, or just prior to the start of Robert's GL ES2 work, and Chris could add his changes to the branch, and that branch could eventually lead to a 2.10 stable release. Robert's trunk work could eventually lead to a 2.12 release. The downside of this is there might be a potentially nasty merge in there somewhere. Robert, Chris: Thoughts? Paul Martz Skew Matrix Software LLC _http://www.skew-matrix.com_ http://www.skew-matrix.com/ +1 303 859 9466 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] SVN commit bottleneck
Paul Martz wrote: I am booked 100% with client work, and if my clients are content on the current release, and there are no pending new features that the clients need, then I have no funding or availability to support a new stable release. And that's totally reasonable. Ultimately, Chris, if you have a need for a stable release, or even a need to get your changes into a branch that will eventually lead to a stable release, then you have just volunteered. :-) Actually, while I _am_ volunteering, it's not because I need a new release. Anybody I'm working with right now can build from source with patches I send. But, I dislike seeing the trunk get stale and fragmented, so I want to ensure that we hold together a community release protocol. If I'm not mistaken, we can branch the trunk either right now, or just prior to the start of Robert's GL ES2 work, and Chris could add his changes to the branch, and that branch could eventually lead to a 2.10 stable release. Robert's trunk work could eventually lead to a 2.12 release. The downside of this is there might be a potentially nasty merge in there somewhere. Robert, Chris: Thoughts? 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. Paul Martz Skew Matrix Software LLC _http://www.skew-matrix.com_ http://www.skew-matrix.com/ +1 303 859 9466 -- Chris 'Xenon' Hanson, omo sanza lettere Xenon AlphaPixel.com PixelSense Landsat processing now available! http://www.alphapixel.com/demos/ There is no Truth. There is only Perception. To Perceive is to Exist. - Xen ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] SVN commit bottleneck
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 osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] SVN commit bottleneck
Hi Chris, On Mon, Oct 12, 2009 at 6:49 PM, Chris 'Xenon' Hanson xe...@alphapixel.com wrote: Ok. I can understand that. Are there any aspects of submission review that could be outsourced? I've already outsourced aspects of the submission review that are the easy and most productive areas. osgAnimation and the Xcode projects are maintaining themselves quite well. The branches are rather less active though, with plenty of engineers with write access but all but me and very occasionally Paul Martz active. 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. I think this is a good plan. I'm not sure I can volunteer to be the sole driving force behind a release (in fact, I know I can't) but it's possible we could assemble a few people that together could do so. We'll without volunteers pushing it forward then it'll just fall back to myself to do when available. Is there anyone reading this who could help get the next release out as part of a group? I'm been away for almost a week and no other engineers and jumping in so I guess not at this time. Do we have a release procedure document? Not yet. Cmake actually now does most of the hard work for us. It's just a case of make tag-test Then when you're happy with what it's going to do with the subversion branch: make tag-run Then it's a case of updating the website with source archives and binaries. But the real task is not the actual release but the effort in coordinating everyone, doing testing and reviewing and merging submissions. It's a community process that is out there in the open. As a general note, we don't even have people coming forward volunteering to drive releases, so writing detailed docs would rather go to waste... The thing to do is find volunteers and let them be assisted by myself and others on the first few minor point releases they do and document/evolve things to make them more streamlined as you go along. 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. I can understand that. As I mentioned above, perhaps it's worth pursuing refactoring off any duties short of the actual SVN commit. Are there other things you think could be done by the community? Um pre testing of submissions is about all we can do, this is already done on occasional submissions that are of interest to others that can't wait for me to get to it, this certainly helps, but it's very occasional. Everyone has there own projects to work on though, so I really don't expect that others will happily devote time to just routine pre-review of submissions. The bottom line is that people have to have an itch to scratch. Personally I wouldn't say review of submissions is a significant bottleneck for the project. It's an occasional bottleneck that will affect different engineers at different times. In terms of workload submissions isn't the biggest problem I face in a managing the project - it's keeping up with general support and driving releases. It's this big stuff that I've been able to partly take a back seat on - general support is handled pretty well in my absence, but driving releases has been close to a void. Even when Don was around it was still me driving almost all releases of OpenThreads, Producer and OpenSceneGraph. The door is open for others to dive in a help, but if members of the community are too busy writing great software then so be it, I'm happy to keep chugging along, but the pace will have to fit in with my own professional and personal constraints. Cheers, Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] SVN commit bottleneck
Robert Osfield wrote: 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. Ok. I can understand that. Are there any aspects of submission review that could be outsourced? 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. I think this is a good plan. I'm not sure I can volunteer to be the sole driving force behind a release (in fact, I know I can't) but it's possible we could assemble a few people that together could do so. Is there anyone reading this who could help get the next release out as part of a group? Do we have a release procedure document? 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. I can understand that. As I mentioned above, perhaps it's worth pursuing refactoring off any duties short of the actual SVN commit. Are there other things you think could be done by the community? Cheers, Robert. -- Chris 'Xenon' Hanson, omo sanza lettere Xenon AlphaPixel.com PixelSense Landsat processing now available! http://www.alphapixel.com/demos/ There is no Truth. There is only Perception. To Perceive is to Exist. - Xen ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] SVN commit bottleneck
Hi Chris, On Fri, Oct 9, 2009 at 7:45 PM, Chris 'Xenon' Hanson xe...@alphapixel.com wrote: It seems like we don't have any capacity in this regard right now. I'll shorten the question -- other than Robert, who does have SVN commit access? As J.S. mentions a number of engineers have commit rights on the branches to help out with convergance towards and maintenance of release branches. However, only Paul Martz has really contributed significantly in that area, with Paul managing all the work required for the 2.6.1 stable release. I haven't had any assistance on the other stable releases though, so while others have commit access, it's a pretty dormant right. In the end I'm still the one pushing stable releases and doing the bulk their maintenance, if I wasn't doing it it does look like it would rarely get done. For svn/trunk I have stuck to a policy of retaining overall control, but have granted write access to specific areas where I have little expertise - Cedric Pinson is developing/maintaining osgAnimation include and src directories and Stephan Huber is maintaining the XCode directory. I think Brede Johansan and Paul Martz has write access to the OpenFlight plugin too. Historically, one of my roles in the OSG community has been to point out the emperor has no clothes moments when we finally acknowledge we're again putting too much responsibility onto Robert, and call for new ways to shave some non-critical roles off his shoulders. I've done cry for helps and got it in the past. Moving out responsibility for rolling out releases and maintaining them to the community is something we tried, with the hope that I would be able to concentrate more on svn/trunk management and less on releases. However, as I said above it's only been partially successful, I've done all the releases save for one point release. I'm wondering if Robert's request for outside assistance here is the time for some of the community to step up to the plate and contribute more effort to the administration of the project's source. I think the last three months has been a rather unusual hiatus in the normal flow of merging submissions and making of dev releases. Normally I attempt to keep on top of submissions and keep the dev and stable release pumping out regularly. I've been particular busy with client work over the the last two years (almost all open sourced :-) but even with this I've put in the extra hours to keep ontop of everything. What I have found is that trying to juggle all these tasks has made me less efficient - multi-tasking isn't good for once intellectual abilities and code development/project management requires the application of ones intellect and isn't forgiving of off days. So if you're less efficient then you have to put more hours in, and the hours you do put in are more stressed because you live under the knowledge that you got so much other work to juggle. A good recipe for burn out, and since the summer rather than keep juggling I've just taken my foot off the peddle and looked to concentrate on a smaller number of tasks at any one time. I'm certainly more productive on these tasks and despite still working hard on the tasks am all around fresher and sharper ;-) The problem with me choosing less to multi-tasks and let some tasks slip till later is that period of patience required from the community has to have gone up - with no choice of their own. This isn't healthy for the community or the software. I'm keenly aware of this, and having been looking for windows between client tasks to get on tackle the submissions backlog and back to making dev releases and stable releases. Unfortunately in the last few month the client tasks have just come in right after other with space in between, it's just been one of those periods. Normally I'd get a couple of weeks of less intensity between bigger tasks, but just haven't got them. Another difference is that rather than try to make the difference by putting in 12 hour days, I've just put in my 8 hours and taken it easy. However, there is light at the end of the tunnel, it does look like I'll finally have a reprieve in Novemeber once OpenGL ES 2.0 support is done. Business wise I'll have hit my targets in November for the financial year that ends in March 2010, and plan to take it easier w.r.t client work. There is lots I need to do in terms of catching up with submissions, getting stable releases of OSG and VPB out the door, and also investing some time into the source code base to tackle various issues that I haven't had the opportunity to address over the years. It's quite a long time since I've been able to spend some real quality time just hacking on general code and being really forward looking, so I'm rather looking forward to it ;-) Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org
Re: [osg-users] SVN commit bottleneck
Robert Osfield 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. As J.S. mentions a number of engineers have commit rights on the branches to help out with convergance towards and maintenance of release branches. However, only Paul Martz has really contributed significantly in that area, with Paul managing all the work required for the 2.6.1 stable release. I haven't had any assistance on the other stable releases though, so while others have commit access, it's a pretty dormant right. In the end I'm still the one pushing stable releases and doing the bulk their maintenance, if I wasn't doing it it does look like it would rarely get done. 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? -- Chris 'Xenon' Hanson, omo sanza lettere Xenon AlphaPixel.com PixelSense Landsat processing now available! http://www.alphapixel.com/demos/ There is no Truth. There is only Perception. To Perceive is to Exist. - Xen ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] SVN commit bottleneck
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
Re: [osg-users] SVN commit bottleneck
Chris 'Xenon' Hanson wrote: I don't think I'm qualified to nominate myself for this right now. However, I'm wondering who does have SVN commit access, and if one of these people is willing to accept interim changes? I have several finished changes ready to check in, and I worry about them getting stale. With concurrent development, other people could potentially get conflicted with my changes and make more messy work for down the road than inf they had my changes to start from. Likewise, I dislike submitting more than one change at a time -- for example, I revised Vec3d for a particular purpose. I would like to get that in with the purpose/explanation before I make any new changes to Vec3d for a different purpose -- that way the SVN commit chain of evidence is clear that this one checking serves on single purpose. Is anyone else willing to accept, screen and integrate SVN changes right now? It seems like we don't have any capacity in this regard right now. I'll shorten the question -- other than Robert, who does have SVN commit access? Historically, one of my roles in the OSG community has been to point out the emperor has no clothes moments when we finally acknowledge we're again putting too much responsibility onto Robert, and call for new ways to shave some non-critical roles off his shoulders. Previously this has been the impetus for the separate submissions list, the Wiki, the Spelling Bee, and some others. I'm wondering if Robert's request for outside assistance here is the time for some of the community to step up to the plate and contribute more effort to the administration of the project's source. Are there others out here who have successfully been involved in the source repository or other significant FOSS projects? Maybe with experience with code review? -- Chris 'Xenon' Hanson, omo sanza lettere Xenon AlphaPixel.com PixelSense Landsat processing now available! http://www.alphapixel.com/demos/ There is no Truth. There is only Perception. To Perceive is to Exist. - Xen ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] SVN commit bottleneck
Hi Chris, It seems like we don't have any capacity in this regard right now. I'll shorten the question -- other than Robert, who does have SVN commit access? Well, I think you've been with us for a while now, so you must have some idea about this. It seems to me that whenever commit rights are given to others, it's been for specialist duties. For example: - Maintenance of update branches (for example maintenance of the 2.6.x branch after 2.6.0 was done by Robert) - Development and maintenance of specific branches and parts of OSG (for example, the osgAnimation branch, the XCode projects, etc.) But no one has had commit access to the SVN repo as a whole except Robert. On one hand I can understand a certain desire to keep the core under control, but I think a good part of commits (maybe upwards of 80%) could be done by other people, since they're either easily verifiable bug fixes or changes to non-critical parts of OSG (i.e. anything other than the rendering backend). I'm wondering if Robert's request for outside assistance here is the time for some of the community to step up to the plate and contribute more effort to the administration of the project's source. I agree that, on one hand, people could volunteer, but historically Robert has been reluctant to give commit rights, preferring to review submissions himself. Instead, he told them to focus on other things like improving documentation, the wiki, answering more questions on the mailing list, etc. So it's understandable that if, in the past, people volunteered only to be told that it wouldn't happen, they're reluctant to volunteer now. I don't want to speak for him of course, just replying from what I remember since he hasn't done so himself yet. I would gladly volunteer but I have little time to devote to the task. I wouldn't want to say I'll help with submissions only to hold them up myself... Perhaps in the future I'll be able to, but right now I can't. Anyways, I agree with your point that the management of submissions needs to be decentralized. The bus factor on OSG (at least on commits to SVN) is too low... J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] SVN commit bottleneck
Robert Osfield wrote: have had to start this round of work immediately after completing other client work so haven't had a window opportunity to catch up with submissions and go for making 2.10 as I had originally hoped. If community members are keen to see a 2.10 release sooner rather than later then we'll need to rely upon other members of the community to take charge of a 2.10 branch and push it all the way to release without me at the helm. I don't think I'm qualified to nominate myself for this right now. However, I'm wondering who does have SVN commit access, and if one of these people is willing to accept interim changes? I have several finished changes ready to check in, and I worry about them getting stale. With concurrent development, other people could potentially get conflicted with my changes and make more messy work for down the road than inf they had my changes to start from. Likewise, I dislike submitting more than one change at a time -- for example, I revised Vec3d for a particular purpose. I would like to get that in with the purpose/explanation before I make any new changes to Vec3d for a different purpose -- that way the SVN commit chain of evidence is clear that this one checking serves on single purpose. Is anyone else willing to accept, screen and integrate SVN changes right now? -- Chris 'Xenon' Hanson, omo sanza lettere Xenon AlphaPixel.com PixelSense Landsat processing now available! http://www.alphapixel.com/demos/ There is no Truth. There is only Perception. To Perceive is to Exist. - Xen ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
