Shouldn't both logging proposals be reviewed in the same formal review
I was the review manager of the two futures libraries and a former review wizard. Two issues that I see: 1) Should we review two or more libraries at the same time No. Because of time commitments and lack of review managers, coordinating two reviews at the same time is too difficult. It has not worked. 2) Should we approve libraries that have significant duplication with another library already in boost? Yes. Each library should be reviewed independently, and approved if it meets the boost community standards. Boost libraries already has lots of overlap, no reason to change at this point. What we should do is encourage the authors to work together submit a combined library. Unfortunately, that has not worked either. The trend is probably going to be more and more library duplication, but this does not concern me. I would find it perfectly acceptable if another "command line" parser was approved, or even if another text parser was approved. The more the better. It shows that boost is still interesting place to come and see what talented c++ developers are up too. There are many ways to abstract a solution and build an interface around it. Boost should encourage a diversity of approaches.
Tom Brinkman <reportbase <at> gmail.com> writes: ... There are many ways to abstract a solution and build an interface around it. Boost should encourage a diversity of approaches.
Yes, it sounds very uplifting and inspiring... and I would agree with that whole-heartedly... if I considered Boost merely the place of purely academic exercise. For many "average" programmers though the Boost libs is first and foremost a product that they want to *use* uniformly throughout a project, many projects. In that light from the commercial deployment and project management points of view having 2 (or worse -- plethora of) functionally-similar facilities readily available is a nightmare as some will end up using one facility and some others will prefer another facility. Shared knowledge is fragmented (people rarely have time and capacity to know all), code reviews, maintenance are difficult, the ultimate product looks unprofessional due to inconsistencies (in case of logging configurations, formats, destinations will be different). It's not an imaginary situation -- our project for various reasons ended up using 3 logging facilities with the very real problems described above. Rectifying the problem now is an expensive and tiring exercise. Do not get me wrong. I am all for creativity, innovation and healthy competition of ideas. However, all that does not have to be dumped onto the user to decide -- users often have no time, capacity, qualifications, freedom to make an educated choice. More so, users often *want* the gurus (and the level of the Boost community is most certainly considerably higher than the average) to make that educated choice for them. It's like one going to a financial planner for help and the planner dumping all the options on to that poor soul. Now that poor customer/user has to be a financial planner himself to make an educated choice. Just my 2c obviously. V.
participants (2)
-
Tom Brinkman -
Vladimir Batov