Re: [boost] review system in place is extremely slow? (was Re: [rfc] rcpp)

Subject: Re: [boost] review system in place is extremely slow? (was Re: [rfc] rcpp)
From: Mateusz Loskot (mateusz_at_[hidden])
Date: 2010-02-25 10:00:01

Rene Rivera wrote:
> Nevin Liber wrote:
>> On 24 February 2010 11:10, Michael Fawcett 
>> <michael.fawcett_at_[hidden]>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