Hi all, Quite agreed what was said. I just want to emphasize on what Adrian and Art said: a hierarchy of maintainers would be a nice idea; and BTW, noone can say Robert will be there forever to maintain OSG (I just hope you'll do it for long though, Robert! :) ).
Maybe a kind of "intermediate" or "secondaray" maintanier could also exist: someone that is not 100% aware of all OSG considerations, but that has enough experience to help "primary" maintainers. I say this because for now I'm simply unable to be an OSG "primary" maintainer :) ... Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ Le Sat, 24 Jan 2009 11:44:46 +0100, Adrian Egli OpenSceneGraph (3D) <[email protected]> a écrit: > Hi all > > It's really great to see how the community or the numbers of users > grows each day, and it's also great to know that the openscenegraph is > used many times in academic, commercial ,.. tools. And we all know > that the work load for robert gets each day bigger and we have to > discuss the near future of the project. Of course there are different > nodekits, hundert of features and finally do we really want just a > scenegraph? The problem is where starts a scene graph and where ends > the scene graph. My opinion is that we should follow the current > concept to include as many nodekits as possible in the osg scene > graph, and the concept of the osgLIB isn't as bas as it sounds. Of > course we should think about splitting the review and responsabiliy of > the whole code into parts, and we should think to decide who can > support robert, i don't like to start splitting the whole project into > "physical"/ hard parts. once i like to get OpenSceneGraph then i like > to get the core (scenegraph), close core (threading & osgViewer (was > once producer, we all remember) ) , ... then basic features like > osgShadow, osgText, osgGA , ... ,... , ... and so on. You understand > me, what is a nodekit what not. I am sure out there are some guys > saying, only osg.lib is a scene graph, so we need only osg.lib the > others lib we should better call nodekit. i think we should NOT decide > to re-create the current concept, we should better to re-write some > code (translate to shaders, ... , ... ) and we should think how we can > support robert, and we should think how we can avoid a worst case > "community crash". I don't really like to mention that, but since i > got an accident, i get how fast the world can change, and how fast we > can get off of work. So what happends, when robert has the unhappy > case and gets froced for a longer break, who would be able to do the > SO IMPORTANT review of the sub-mitted code. We should start as soon as > possible to discuss how we can insure that the OpenSceneGraph project > would continue in all possible cases the life play. > > In my opinion we have to think about a core group of people who have > the understanding of maintaining the project and can support robert > without losing the open mind/concept of robert and this would be the > biggest challange in the near future. The OpenSceneGraph's coding > standard, quality , ... is really good and the only raison is that > robert has decidie to check in or not, and had thought often a long > time about the concept. i would split the osg core, event not in osg > 10.0, i would let grow the lib as much as it make sense, but i would > work with more people involved in mainting the code. reviews, and so on. > > /adrian > > > On 24/01/2009, Mario Valle <[email protected]> wrote: >> For my job currently I'm using the statistics package R and writing >> things using LaTeX. >> Both have a very structured method to manage and document addons. >> Look at http://stat.ethz.ch/CRAN/ (very good) and at: >> http://www.ctan.org/tex-archive/ (less clear). >> These could be an inspiration for the future NodeKits structure and >> management, I think. >> Just my 0.05 CHF >> mario >> >> Robert Osfield wrote: >>> Hi Art, >>> >>> I understand the issues you talk about. External NodeKit can be >>> neglected by potential users because they aren't visible enough, and >>> there are also issue of compatibility and maintenance of these >>> external NodeKits. It's not just an issue of NodeKits, it applies to >>> plugins or applications that live around the core OSG project. I >>> don't think the solution need be a pure software management issue, >>> it's strongly related to management of website resources. >>> >>> We've had various different initiatives over the years to try and >>> address this issue - the wiki is one avenue, another was the formation >>> of osgforge.org and hosting of several ancilery projects like VPB, >>> Present3D, osgLua and osgPython. My hope was osgforge would become a >>> incubator for projects that could make it into the core, or become >>> part of the close nit family of NodeKits. Such initiatives haven't >>> thrived as perhaps they could have, partly because the various >>> contributors haven't pushed things forward, and partly that >>> wiki/website management takes time and dedicated manpower. I'm open to >>> suggestions on how better to streamline and manage this side of >>> things. The bottom line is a key missing ingredient has been >>> engineers who put the time into keep websites up to date. >>> >>> As for re-factoring handling of NodeKits in 3.0, I'm open to this. It >>> might even make the most sense to build 3.0 incrementally, starting >>> with a re-factored core scene graph and then bit by bit re-introduce >>> the NodeKits as they get ported across. Quite a few of the older >>> NodeKits would be best rewritten using shaders, or to be incorporated >>> into other NodeKits. Having some scheme where 3rd party NodeKits can >>> be pulled in by end users may well help facilitate a move over to a >>> 3.0. >>> >>> One thing I have thought about in the past of have an "Open Graphics >>> Suite" that is collection of related libraries/applications, with a >>> scene graph one element of the suite, then you'd have extra libraries, >>> exporters, applications all populate this suite. The suite would >>> contain optional components that could be selected from to provide the >>> tools required for different apps. Modern linux packaging >>> repositories provide this model and the scale of 10's of thousands of >>> compatible libraries and applications. >>> >>> >>> Robert. >>> >>> On Fri, Jan 23, 2009 at 5:34 PM, Art Tevs <[email protected]> wrote: >>> >>>> Hi folks, >>>> >>>> The community becames bigger and bigger and there are more and more >>>> projects/nodekits which offers additional features to osg. And therefor I >>>> think OSG 3.0 is the best time to refactor the whole nodekit maintaining >>>> structure. Hence here are couple of ideas, how to do so. >>>> >>>> >>>> In my opinion, nodeKits/plugins which were not lucky to be included into >>>> osg main core wouldn't survive, because the people would just forget >>>> about them. Making everyday advertisment, that this and this nodekit does >>>> provide the functionality you are looking for is also not the solution. >>>> New users are not used to read wiki pages or search in google, they do >>>> not even read ReadMes which are essential for proper work. They just >>>> download and compile the osg and want to have either an example showing >>>> how to do it or try to reinvent the wheel everytime again and again. >>>> Nodekits which are then not included in the main core (or better say: >>>> main download) are not noticed by users. >>>> >>>> >>>> What I propose is to rearrange/refactor/cleanup osg main core to basic >>>> functionality of a scene graph, so to remove everything which has nothing >>>> to do with a scene graph on its own. Then provide something like official >>>> category of nodekits, where all previuosuly filtered nodekits would be >>>> moved. Robert will became main maintainer, who is responsible for the >>>> whole code and for bringing the category maintainers together. A category >>>> maintainer is responsible for his category and maintainers of each >>>> individaul projects which are covered by his category. The individual >>>> maintainer is responsible only for its own project. This would create >>>> some kind of hierarchy of nodekits and its maintainers, which would make >>>> the further development of OpenSceneGraph more flexible, I think. >>>> >>>> >>>> All the maintainers of the nodekits should get their own svn permissions >>>> to being able to commit to the svn, however only to their own projects. >>>> Maintainers of a category would get responsible to bring all the projects >>>> into one NodeKit-Pack/Category-Pack and make sure, that the pack is >>>> compileable and compatible with current osg version. This will free up >>>> Robert, who is spending maybe his whole time to the project, and will >>>> also make the decision about new features more democratic :) >>>> >>>> >>>> What I imagine is that when you download osg you get just the basic >>>> functionality and nothing more. Then you decide to have gui >>>> functionality, hence you download the GUI-NodeKit and you get the osgGA, >>>> osgWidget, osgText and other nodekits which are still marked as official >>>> OSG GUI nodekits. All that nodekits/nodekit categories provided on the >>>> main webpage are officialy validated. Projects which are like to became >>>> officialy validated, would have to be investigated by the main maintainer >>>> (Robert) and by the submaintainer, responsible for the nodekit group >>>> where the new project like to be included in. >>>> >>>> >>>> Release of osg 3.0 will be a good point to do so, because the backward >>>> compaitibility has no to be fully supported as it was done during the 2.x >>>> development. And my personal opinion is, that this kind of project >>>> development will make it more flexible and will let evaluate the >>>> OpenSceneGraph faster, which more or less became a game engine rather >>>> than a scene graph ;) >>>> >>>> >>>> Best regards, >>>> art >>>> >>>> ------------------ >>>> Read this topic online here: >>>> http://osgforum.tevs.eu/viewtopic.php?p=5006#5006 >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> osg-users mailing list >>>> [email protected] >>>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org >>>> >>>> >>> _______________________________________________ >>> osg-users mailing list >>> [email protected] >>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org >>> >> >> >> -- >> Ing. Mario Valle >> Data Analysis Group | >> http://www.cscs.ch/~mvalle >> Swiss National Supercomputing Centre (CSCS) | Tel: +41 (91) 610.82.60 >> v. Cantonale Galleria 2, 6928 Manno, Switzerland | Fax: +41 (91) 610.82.82 >> >> _______________________________________________ >> osg-users mailing list >> [email protected] >> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
