Hi, Just a follow-up on http://github.com . PragProgs have a nice screencast that shows github in action : http://pragprog.com/screencasts/v-scgithub/insider-guide-to-github
The first five minutes are a showcase of the fancy stuff but then it explains how to realliy use it. Nice to watch. The first episode is free... -- Mathieu O< ascii ribbon campaign - stop html mail - www.asciiribbon.org On 23 February 2010 09:37, Mathieu Marache <mathieu.mara...@gmail.com> wrote: > Hi Robert and al, > > [...] >> >> Spreading tasks and responsibility >> >> OK, how do we put all this discussion of submissions/knowledge and >> avoiding too much multi-tasking together in a form of solutions? We'll I >> believe that specializing Knowledge and Responsibility go hand in hand with >> making more efficient use of each maintainer. I am over stretched - I'm >> responsible for just too much code, and if I'm struggling then we can't >> expect anyone else to cope with trying to responsible with such a wide code >> base. So ideally we want to let me concentrate my time and knowledge on a >> smaller set of the OSG code base, and if we are to expect others to step in >> it should be for them to take over responsibility for small sets of the OSG >> code base. >> >> Taking on small sets of the OSG base will help nurture the knowledge about >> that code and help them remain efficient - to avoid the maintainer from >> becoming overcome with the various tasks associated with it - user support, >> bug charaterisation and fixing, merging submissions, ongoing development. >> The type of sets of OSG code that a maintainer would be responsible for >> should be something that have a itch to scratch - something that is >> essential for their work, something they wrote or have been a major >> contributor to. >> >> For myself what parts of the OSG would it be easy for me to pass over >> without undue risk to project? Well the OpenSceneGraph/examples would be >> one area. OpenSceneGraph/applictions another. >> OpenSceneGraph/src/osgWrappers, OpenSceneGraph/src/osgPlugins/ - or small >> groups of the plugins, The NodeKits. Utility libraries like >> osgIntrospection would also be a good candidate, and possibly even moved out >> of the OSG core into a separate project completely. >> >> The only parts of the OSG that I would feel really uncomfortable about >> passing over would be the core libraries, osg, osgUtil, osgDB, osgViewer. >> OpenThreads is also core, but it's decoupled enough that it might be a >> reasonable candidate for others taking responsibility for. >> >> Full Responsibility is Full Responsibility, Half measures might as well be >> empty measures. >> >> Ideally for me I could just hand over complete responsibility for >> components of the OSG and then be able cast all responsibility for it myself >> away. If I can do this I have one less thing to worry about and I can >> concentrate on those parts that need my expertise the most. However, if I >> still need to retain knowledge and keep involved in ongoing maintenance then >> I'm still stuck with being spread too thing - still undermined too much by >> multi-tasking. >> >> The responsibility also extends to be around and active in the community >> for a good deal of the time, one has to take responsibility for answering >> questions on the mailing list/forum, doing testing, handling submissions, >> helping with getting dev and stable releases out. >> >> We are already some way there... >> >> Giving over responsibility to maintaining, merging submissions and doing >> ongoing support for components of the OSG already happens in a modest way. >> Cedric Pinson has svn write access to osgAnimation, and Paul Martz (and I >> think possibly Brede Johanson) has write access to >> src/osgPlugins/OpenFlight. There has to be an occassional bit of coordinate >> between but so far I believe it has worked pretty well. I'm certainly >> relieved not to have to worry about these components. >> >> Michael Platings was also granted write permission to the new FBX plugin, >> but alas hasn't yet been able to successfully check anything in which has >> certainly held back maintenance of this new component. Sorting this out is >> beyond my skill set. Perhaps Michael and Jose Luis can explain what they've >> tried so far. >> >> There is also write permission granted to Paul Martz, and I believe a >> couple of engineers to the svn/osg/branches portion of the OSG svn. This >> enables others to maintain branches and make releases without my >> intervention. As far as I'm aware Paul has been the only one to take up on >> doing maintenance on the branches, but even here most of the work on the >> branches and make minor point releases has been tackled by me. >> >> Is another version control system the way to go for more distributed >> development? >> >> This topic has been raised a couple of times over the last couple of years >> - version control systems like git and mercial are better set up of >> maintaining and merging separate branches. I've tried merging branches >> using subversion and it's possible to make a real mess of it rather quickly >> if you aren't really careful about how you do things. I'm certainly open to >> moving to another version control system, this will however, requiring us >> all to learn it, and for members of community to step forward and set it up >> and maintain it. >> >> I do think that the type of version control system is secondary to the >> importance to having individual or small groups of developers taking >> responsibility for specific parts of OSG code base. We could possible break >> up into small working groups, with each group taking responsibility for a >> family of components of the OSG - such as a plugin working group, an >> examples working group, a serializers working group etc. These working >> groups might have individuals within them concentrate on particular >> components such as the OpenFlight or 3DS plugin etc. >> >> I hope this help inspire some of you worthy developers to step forward :-) >> Robert. >> > > Choosing the correct tool is secondary to people steping-up to take > responsibilities but some tools propose schemes that would help organise > respnosibilities. If I take my favorite vcs (git), it's creation was to > handle the same kind of responsibilities. In a linux kernel world, Linus has > what is referred as the master branch, he inspects/merges in submissions > only from "caporals", men he trusts, who themselves organise these > submissions from the submitters. > One of the main problems is creating this pyramid of trust, but that has > already begun with the granted svn access. > The other main problem was the tool, letting other people see (pull) your > changes, needed either you to mail them (patch) or you to provid a direct > access to your git server... Online repositories have emerged from this > technical barrier like http://github.com. > > A tool like this makes it easy to fork from the master and provides > graphical tools (network) to observe connections between different branches. > It is also a source browser, a Wiki and has download areas... for free > > Today graphical (point and clic) tools like TortoiseSVN are available on > most platforms like windows, mac and linux that leverages the 'learning > curve'. > > I could step up in explaining and helping migrating to a different vcs. > > Mathieu > > _______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
