On 3/19/2010 4:14 AM, 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. 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:
- Unmaintained components. Many authors are no longer active, and we have no procedures for taking over. - Reviews that are getting rare and, IMO, less interesting then before. - Turnaround time of test results
I think it is also important to ask boost end-users what are the perceived problems with Boost. If I may answer that, as an end-user, I first want to say that from the end-users perspective the problems with Boost are highly overrated. It is still the premier set of libraries for native C++ development. The main problem from an end-user's perspective is the first one you mentioned above. There are Boost libraries which have a few bugs but which simply do not get maintained and it is simply because the library developer, for very human reasons, does not want to continue to maintain the library. I do not know the solution to this but I strongly suspect that when the developer of a library does not want the responsibility to maintain it anymore that it needs to get passed to someone else who is willing to maintain it, or else marked in Boost as not being maintained and thertefore deprecated. I know the latter sounds harsh but the truth is that if no developer wants to maintain software which has problems, or is possibly in need of additions or changes, then the software eventually become unusable. So I would say that anyone submitting a library to Boost needs to understand that once that person no longer wishes to maintain that library, the ability to maintain it reverts to Boost and the original developer can no longer claim that library as his own. To me this seems to be realistic. I view it as very human for a developer to not want to maintain software in perpetuity so I see nothin wrong with this suggestion.