Subject: Re: [boost] review system in place is extremely slow? (was Re: [rfc] rcpp)
From: vicente.botet (vicente.botet_at_[hidden])
Date: 2010-02-25 11:16:39
----- Original Message -----
From: "Mateusz Loskot" <mateusz_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Thursday, February 25, 2010 4:00 PM
Subject: Re: [boost] review system in place is extremely slow? (was Re: [rfc] rcpp)
>
> 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?
AFAIK, Boost don't provided a website by library, so you will need to host where you prefer.
> Where to put a project specific Wiki or FAQ?
There is a wiki associated to the Trac system (https://svn.boost.org/trac/boost/wiki). You can add you own page and organize your wiki as you like. I suppose you will need to request to have the right to modify it.
> 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.)
I would prefer you request your users to submit reports to Boost Trac. This allow to check all the Boost tickets with only one tool.
You can add a specific query to show the trickets specific to the component Geometry.
> 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
There are some specific mailing lists, e.g. Threads, Spirit, Doc, .. . all that you need is to have a moderator I think. Have you request such a ML?
> 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.
I agree.
> 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/)
Maybe just doing what you are doing now. Requesting to this ML. IMO things are not so static as people could think.
> 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.
Currently missing in Boost.
> - Trac/Wiki at trac.osgeo.org/project/
Available on request.
> - SVN: at svn.osgeo.org/project/
Already available.
> - mailing lists at lists.osgeo.org
Available on request.
> Some projects get other services like buildbot
> (http://buildbot.osgeo.org), FTP at download.osgeo.org, etc.
Currently missing in Boost.
> 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.
Thanks to share with us all the questions about how to organize you project.
Best,
Vicente