Rene Rivera wrote:
Nevin Liber wrote:
On 24 February 2010 11:10, Michael Fawcett <michael.fawcett@gmail.com>wrote:
Setting up the web backends for all of this sounds like a lot of work,
Given that we don't have enough volunteers to be review managers, where exactly are you going to find the volunteers to do all this setting up and maintaining web backends?
True.. But it's not a terrible amount of work with modern web tech, like Drupal. Along those lines I recently mentioned to Harmut how nice it would be to have each Boost library have their own sub-site (ex. spirit.boost.org). As it would promote the model that Boost is a set of independent libraries under one umbrella.
I was about to respond to Nevin's post with similar comment. As a brand new member of Boost developers community (thanks to Boost Geometry approval), I have got an impression that once a library accepted, it's unclear what would be a next step and how its development cycle would look like in terms of infrastructure support. Given the Boost Geometry, we have had quite a long brainstorm and discussion with Barend and Bruno about how to organize the project as a part of Boost collection. Number of questions raised and I personally admit we have not found any ideal solution. A few of the issues: 1) Where Boost Geometry website should go? SourceForge, OSGeo Foundation (where it is now hosted, ), should we buy hosting as Spirit or perhaps arrange everything at boost.org. Where to put a regular website? Where to put a project specific Wiki or FAQ? 2) Where bug tracker goes? Should we ask Boost Geometry users to submit reports to Boost Trac exclusively, or should we maintain it on our own. We have actually not decided what to do as neither of choices seem best options. Adding hundreds of reports to the general population at Boost Trac may make things difficult to maintain and searching for existing bugs may become a complex task (i.e. to confirm if a problem has been submitted before reporting new bug, etc.) 3) Where mailing lists go? The boost and boost-users seem a natural choice for Boost Geometry users, however plenty if not most of discussions would be boring to general audience of Boost developers/users. Geometry is one of wide variety of subjects Boost addresses. We likely need our own mailing list server, but where? lists.boost.org or somewhere else? How to avoid confusions in users so they know where to post their questions about Boost Geometry. ATM, we host it at lists.osgeo.org In general, there is no problem with finding virtual home for a project. The problem is that if it is outside Boost project, which in fact a library is a part of, then it will likely cause confusions and impression of disintegration. The big question is how to avoid schizophrenic way of maintaining project infrastructure and a little split of personality as I observe in for instance with Boost/Adobe GIL. It is quite important to keep things well integrated, otherwise it may prevent wide adoption of a piece of software by users (it's well explained by Karl Vogel in http://producingoss.com/) I have experience with self-organised community of OSGeo Foundation (http://osgeo.org, http://wiki.osgeo.org) which could be compared to Boost as domain-specific (GIS/RS/geo*) community. OSGeo accepts projects by conducting incubation process similar to Boost reviews. Shortly, there is a bunch of projects projects living under the umbrella of OSGeo. Each project gets its own instance of: - overview website at project.osgeo.org or it is a subdomain which points to project own website. - Trac/Wiki at trac.osgeo.org/project/ - SVN: at svn.osgeo.org/project/ - mailing lists at lists.osgeo.org Some projects get other services like buildbot (http://buildbot.osgeo.org), FTP at download.osgeo.org, etc. Everything works on volunteer basis, so it's a self-supported system. It is coordinated by volunteers willing to join SAC to support the community. (http://wiki.osgeo.org/wiki/SAC and http://lists.osgeo.org/pipermail/sac) From a project point of view, it works nearly perfectly. However, I can admit it, it costs a lot of work to administer and maintain all the services. It is a load of work, indeed. I've given the long story to share some observations and experiences in terms of brainstorming, however, I'm not sure what capabilities Boost holds in its hand in terms of server-side infrastructure. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net