On Thu, Feb 19, 2009 at 1:44 AM, Gerrit Voss <[email protected]> wrote: > > Hi Allen,, > > sorry for the delay I was slightly distracted by other things. > > On Mon, 2009-02-16 at 08:00 -0600, Allen Bierbaum wrote: >> Hello all: >> >> I am writing to ask what the roadmap to 2.0 release looks like. >> >> We create a stable branch of OpenSG in June of 2007 to use temporarily >> while OpenSG 2.0 was ironed out. This branch has worked *very* well >> for us which I think speaks volumes to the OpenSG 2.0 code. >> Unfortunately, we planned to use this for 3-4 months, but have been >> using it for much longer. We would like to get back to using the head >> since it has a number of performance improvements and 1.5 years of >> development, but I must make sure we can count on a stable >> release/branch for code that we deploy. We can help out with pushing >> 2.0 out the door, but I don't know what the current plan is. >> >> For example: >> >> - How close are we to 2.0? > > actually I'm already in the middle of what I thought would go into > 2.1, e.g. I'm about to restructure the materials, the way materials > are stored, and chunks so that they can change according to the > requirements/properties of the current segment of the render traversal.
That sounds promising. If you are working on 2.1 then 2.0 is probably ready for a stable release branch. :) >> - What features/capabilities are left to implement? > > The biggest issue I see is documentation. I can walk through 1.x > and open tickets for missing pieces. > >> - What will the release process look like (RC's, betas, etc)? > > I left that one a little bit to Dirk ;-) (yes, I know it's not nice ;-)) > I'm fine to go into release mode and walk thought the track tickets. As > we have a tutorial at IEEE VR coming up we have to look into this > anyway, so hopefully we at least a beta out of it ;-) My suggestion would be that we create a 2.0 release branch targetting an IEEE VR release. If that existing, I think we could move our development over to it and help out with stress testing the system. Then everyone could work through the ticket backlog and make sure fixes, documentation etc are ready. That said, I would not let documentation be the hold up. I know we need it, but we all need working code even more. We have some engineers here that would be willing to contribute (and if needed help coordinate) this process. Just let me know what you need. > I'm not sure how much would we have to merge back from your branch, > IIRC Carsten looked into a some time ago. I was talking to Aron and Patrick about this yesterday. Once we know we are going to switch branches, we can go through and merge anything we think is needed. We will make the commits self-contained though so everyone can review them and we can all back out individual pieces if anything is objectionable. -Allen > > > Other opinions ?? > > > kind regards, > gerrit > > > > ------------------------------------------------------------------------------ > Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA > -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise > -Strategies to boost innovation and cut costs with open source participation > -Receive a $600 discount off the registration fee with the source code: SFAD > http://p.sf.net/sfu/XcvMzF8H > _______________________________________________ > Opensg-core mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/opensg-core > ------------------------------------------------------------------------------ Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H _______________________________________________ Opensg-core mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/opensg-core
