On 03/19/2010 11:14 AM, Vladimir Prus wrote:
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.
I can't call myself an active developer of Boost, but I did create quite a few tickets, some with patches, and applied some of them. So I hope I qualify for the survey. First, here are my top 3: 1. The review procedure is failing to deliver new libraries to the users in a reasonable time frame. Some very important libraries stay in the queue for too long without even having a review manager assigned. 2. The lack of maintenance releases. In production environment it is often a rule of thumb that the first release is unstable, and the second (third?) security update is suitable for use. Not having such updates at all leaves Boost in a bad situation. 3. Monolithic design limits development and adoption of Boost. A more modular approach is needed. I'd like to draw attention to the fact that none of these issues is of instrumental nature. I recognize the problems with unsatisfactory performance of Trac and complex build system of Boost, but to my mind these are of secondary concern. A far more important thing to do is to decide the further course of Boost development. Then the instrumental layer will naturally follow the chosen direction. Now, some more details on the outlined issues. 1. The review procedure. ======================== The topic raises rather often, there are suggestions from different participants, but it seems that nothing changes eventually. Reviews still happen rarely, there are too few review managers, and sometimes reviewers are also lacking. It looks like Boost has grew too big and the core Boost community members just don't have the time to pay attention to the new proposals. Another possible reason for this effect could be that the interest for Boost is cooling down, but I don't want to believe that. After all, Boost was, is and will be the place for innovative ideas in the world of C++, and losing interest for such a place would mean losing interest in C++ as a whole. Anyway, I think, we should identify the reasons of this stagnation. Of course, the first thing that comes to mind is the lack of time of the volunteers. True, I can barely comprehend the amount of time a review manager should dedicate to the review. This is especially true in case of big submissions to Boost. This amount of time should be reduced. The following ways of doing that come to mind (some were discussed earlier on the ML, but I'll rehash): - Introduce the voting mechanism. Voting should be as easy as clicking on a yes/no link or icon on a web page + an optional small comment. No ML subscription required. The review manager may take into account those votes as an indication of public interest and appreciation of the submission. - Separate the mechanism of posting a full review and the library discussion. It would make it easier to collect the formal reviews without having to read through all the discussion. Perhaps, a separate ML for formal reviews would suffice. A web page with a few fields to fill in to post the review would also be very helpful, especially for the occasional newcomers. - Reduce the number of formal questions for the review. IMHO, three questions of design, docs and implementation quality, plus the final yes/no verdict should suffice for the review. The rest should be optional. - Provide automated ways of assisting the review, such as scripts for updating the web site for the review (e.g. post an announcement in the news section, prepare the aforementioned web page for posting reviews, etc.), formal mailings (review is upcoming, review has started, review is in progress, review has finished) and whatever other things needed. Ideally, I would like to reduce the time needed for such routine things to a minimum. Another reason is the lack of motivation. I think, it is fair to say that people that invest their time and effort into Boost should be rewarded somehow. I'm not saying that Boost should become a commercial software (please, no!), but the appropriate acknowledgement of their efforts should be in place (on the front page of the web site and the release notes). Perhaps, a donation system could be established, so that release and review managers do get monetary rewards, too. On the current stage I don't consider reviewers to be rewarded, because the library acceptance itself is a reward for them, as for the interested parties. But the library author is free to acknowledge them in the library credits page. And the third reason I'd like to outline is the lack of people. The problem is twofold. On one side, the entering barrier for a person into Boost is quite high. One has to be a quite experienced developer to participate in reviews, let alone to be a review manager. While the review manager should be experienced, I'm not sure the requirement is adequate with regard to the reviewers. I think it should be possible for the less experienced users to see if documentation and examples are clear and understandable, while the more advanced developers have more time to evaluate the implementation and the interface of the library. The other side of the problem is that Boost is rather closed to its community. I don't know how it happens, but on independent news I regularly read of such projects as KDE, GNOME, Qt, Linux Kernel and others, but nearly nothing about Boost, which, I believe, has no less importance in the world of C++. The Boost web site changes rarely - essentially, the news column only lists recent Boost releases. For an outsider, nothing really happens around Boost, and that's sad. If Boost was more open and advertised on public (perhaps, not a good wording, but I can't come up with a better phrase now), I think, there would be much more activity in Boost, and during reviews in particular. To be continued...