--- Begin Message ---
> -----Original Message-----
> From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Vladimir Prus
> Sent: Friday, March 19, 2010 8:15 AM
> To: boost@lists.boost.org
> Subject: [boost] The problems with Boost development
>
>
> Hello,
>
> in a recent post, Dave listed a few things that he thinks are wrong
> with Boost development, at present, quoting:
>
> I know I'm not the first person to notice that, as Boost has grown, it
> has become harder and harder to manage, Subversion is getting slow,
> our issue tracker is full to overflowing, and the release process is a
> full-time job.
>
> It seems to be important, right now, to discuss whether this problems are real,
> and what problems are most important. So, I would like to ask that everybody
> who is somehow involved in *development* -- whether in writing code, triaging bugs,
> sending patches, or managing thing, list three most important problems with Boost now.
> Please keep the items to a sentence or two, so that we can easily collect the problems.
Here's my take:
- bjam is unfamiliar and inscrutable to many, and lacks *effective* documentation and jamfile comments. I see this
as a mega barrier to many who might like to help.
- build/download/install process is not easy enough and not well enough documented - the same user problems keep
cropping up again and again on the lists. (And very probably this is the tip of a much, much bigger iceberg).
- Not enough people willing and able to give time to Boost. Blame the Bankers? ;-)
- Unmaintained components. Many authors are no longer active, and we have no procedures for taking over. I'd make
it easier for others to implement changes to trunk - seems to work now with an informal "Ok to change this?" protocol.
- Bugs that are identified and patches provided take far, far too long to get into trunk, let alone releases. Bugs
whose fix is identified (reasonably well) cannot easily be patched into a users release.
- Nobody has cracked the problem of automating the release process to achieve Beman's laudable 'release early,
release much more often' aim. But this would force users to accept new versions frequently. Personally I don't think
this would anywhere as much trouble as people fear. I'm astonished that people are still expecting answers to questions
about using 1.34 etc - I would just say: "you must try the most recent version first".
My gut reaction to Dave's proposal was "This won't boost Boost".
But I hope to be proved wrong.
Paul
---
Paul A. Bristow
Prizet Farmhouse
Kendal, UK LA8 8AB
+44 1539 561830, mobile +44 7714330204
pbristow@hetp.u-net.com
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
--
Dave Abrahams Meet me at BoostCon: http://www.boostcon.com
BoostPro Computing
http://www.boostpro.com
--- End Message ---