Re: [osg-users] SVN commit bottleneck

[J.P. Delport]

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_ 
+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

[Robert Osfield]

Hi Paul,

On Fri, Oct 23, 2009 at 4:10 PM, Paul Martz  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

[Paul Martz]

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

[Robert Osfield]

Hi Paul el. al,

On Thu, Oct 22, 2009 at 5:13 PM, Paul Martz  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

[Paul Martz]

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_ 
+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

[Chris 'Xenon' Hanson]

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_ 
> +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

[Paul Martz]

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_ 
+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

[Robert Osfield]

Hi Chris,

On Mon, Oct 12, 2009 at 6:49 PM, Chris 'Xenon' Hanson
 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

[Chris 'Xenon' Hanson]

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

[Robert Osfield]

Hi Chris,

On Sat, Oct 10, 2009 at 4:26 PM, Chris 'Xenon' Hanson
 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]

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

[Robert Osfield]

Hi Chris,

On Fri, Oct 9, 2009 at 7:45 PM, 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?

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
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] SVN commit bottleneck

[Jean-Sébastien Guay]

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

[Chris 'Xenon' Hanson]

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

[Chris 'Xenon' Hanson]

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