Subject: Re: [boost] GSoC 2011 - Do we need to starting thinking about it?
From: Paul A. Bristow (pbristow_at_[hidden])
Date: 2011-01-25 11:52:21
> -----Original Message-----
> From: boost-bounces_at_[hidden] [mailto:boost-bounces_at_[hidden]]
> On Behalf Of Tim Blechmann
> Sent: Monday, January 24, 2011 7:01 PM
> To: boost_at_[hidden]
> Subject: Re: [boost] GSoC 2011 - Do we need to starting thinking about it?
> > 5. Encourage toolkit-like additions to existing libraries, rather than
> > writing a full-blown library. These have historically been more
> true. i have been doing a gsoc project last year, implementing heap data
> structures. in the end i had the feeling that i have implemented quite a
> code, but that it is too early for review, but that it needs to be used by
> order to mature. otoh, there are already heap data structures in boost as
> bgl, although they have a very specific interface, which is optimized for
> the end, i doubt that anyone ever used the code: i never got any question
> it, nor did i use it myself ...
That's a bit disappointing - to Boost, as well as you.
Did you feel that you spent too much time cutting code?
And/or too little producing documentation, examples and other things that
would 'sell' the project and get enough users with experience enough to get
to a review?
I suspect that any projects have far, far to big ambitions, when what we
probably most want out of a project is a *finished* job.
To achieve this, IMO we need to
* Emphasise the need to finish.
* Reduce significant the size of what's bitten off.
* Make sure that little time is wasted getting over the
Boost_way_of_doing_things (high) hurdle. A project template would help
here, and especially a template for documentation using the Quickbook,
Doxygen chain. Without these we will end up with something that can't be
reviewed or maintained.
(A GSoC project might even be creating those templates?)
--- Paul A. Bristow, Prizet Farmhouse, Kendal LA8 8AB UK +44 1539 561830 07714330204 pbristow_at_[hidden]
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk