Well, I think it could result in an explosion of publicly available prototypes, since anyone would be able to work on his own public repo without having to request commit access to svn, and able to say hey, if you wanna try my module, just pull from this url. And you can as easily branch out your repo, pull from it, try it out, and propose it to become part of the mainstream if it's good.
Of course on my initial message "community modules being obsolete" was too much an overstatement. I wanted to mean something more like the above. That said it's not like I really want to push hard on that idea nor get into philosophical wars. I consider myself a newbie to git collaboration but so far I like it very much and hence the enthusiasm. Cheers, Gabriel On Tue, 2011-05-17 at 09:51 +0800, Ben Caradoc-Davies wrote: > Another benefit of keeping community modules in a central repo is that > it keeps them open for public scrutiny, comment, and involvement, even > when they are a work-in-progress. In my view, this increases openness > and transparency. Even prototype modules can have unexpected new users > come out of the woodwork. I think these benefits would be reduced if > works-in-progress were moved to other repos. > > On 16/05/11 10:35, Ben Caradoc-Davies wrote: > > One key advantage of keeping community modules in subversion is > > continuous integration coverage. The -PallExtensions profile raises > > quality by forcing community modules to build or be kicked. This makes > > it a true incubator. Furthermore, it alerts core developers to community > > modules broken by core changes. These benefits are orthogonal to > > svn-vs-git debates. > -- Gabriel Roldan [email protected] Expert service straight from the developers ------------------------------------------------------------------------------ Achieve unprecedented app performance and reliability What every C/C++ and Fortran developer should know. Learn how Intel has extended the reach of its next-generation tools to help boost performance applications - inlcuding clusters. http://p.sf.net/sfu/intel-dev2devmay _______________________________________________ Geoserver-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geoserver-devel
