David Abrahams wrote: [snip]
Vladimir Prus wrote:
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.
This is a great discussion to have; I encourage it for those that are so inclined. IIUC, we're also going to have a talk about that topic from Robert Ramey at BoostCon. If you don't see me participating this time around, don't take it as a lack of support or interest-it's only because I'm too busy working on (partial) solutions to the problems-as-I-see-them and having them ready for BoostCon.
[snip] [1] As a Boost user, I primarily expect libraries in Boost are ones that are being proposed, developed, or tested for possible inclusion into a future C++ Standard. To me, this means that the API will be continuously changing and refined as the libraries receive review and feedback on their use. This is what I get from the vision statement and am grateful that the authors allow me to use their exceptionally high quality libraries in my own projects. I use these libraries at my own risk, my own maintenance, my own quality control, etc. (and hopefully, I report my results back to them.) This is my understanding from the Boost vision statement and the origins of Boost. I think that Boost.Threads and the locking libraries are excellent examples of this evolutionary process. I thought that providing an early adopter TR1 implementation was quite appropriate too. However, because of a few outstanding libraries (serialization, lexical, gil, soci, etc), I've started to like to use / depend on Boost libraries whenever I can because Boost libraries are usually very efficient and well thought out and support generic programming (and already part of my build tree). I think there is another category of libraries that are very useful, but realistically, will never be considered for inclusion into a C++ standard. A question is whether Boost should host these libraries or not. In a nutshell, I believe that the Boost Vision statement needs to be revisited and determine what Boost is. To me, it seems to have wandered a bit away from it's originally established goals. If I could have my cake and eat it too, I would like to see Boost divided into three subprojects: 1) Research and development of C++ Standards and libraries, 2) Repository for complementary (and integrated) but non standards bound libraries, and 3) sandbox projects. Within 1 and 2, there should be unstable, testing, and stable libraries. I believe this would set user's expectations appropriately. BoostBuild is a tremendous tool and I would be very sad to see it get totally replaced by a Make based system. To me, the greatest problem with BoostBuild is lack of user education, and that from lacking the right obviously accessible documentation. When BoostBuild works, it is magic and it works great. When it doesn't, you're committed to multiple hours of pouring through Jamfiles and Googling. After you've done that a few times and figured things out, you only spend minutes when things blow up... Someone said, "Using Unix/Linux is easy, learning it is hard." I think the same applies to C++ and to Boost Build. Once you learn it, you have versatile and problem solving tools. I'm quite excited by the Ryppl page and development. I'm anxiously following it's development and waiting for the testing candidate.