On 4/21/06, David Abrahams <dave@boost-consulting.com> wrote:
Jose <jmalv04@gmail.com> writes:
1. Have a priority list with the new libraries that boost users need
----------------------------------------------------------------------------------------------
a) must have libraries b) nice to have c) interesting
e.g. is Boost.SQL a nice to have or a must have ? is a Boost.Relational( e.g. RTL-like) a nice to have or a must have ?
And who's going to make those decisions?
This could be done via the list, assuming the criteria for making the decisions is clearly stated. I take as rough Boost goals (from the home page) as to develop libraries that: a) work well with the standard c++ library b) are widely useful c) establish "existing practice" and provide reference implementations So using these goals, all specialized libraries are in group c) as they are by definition not widely useful. Also a Boost.SQL is widely useful but not state of the art, so is probably a nice to have. The whole point of this step is that once some list is available it is easier to encourage people to identify what to work on (I am not trying to create the list here)
e.g. the current Property List library being reviewed: - shouldn't it be part of the existing program options library (if its intended usage is similar to program options library vs a generic tree container) ?
How is this related to library priority? How is this related to improving the review process ?
Sorry. This was stated in the wrong section. It meant to be in section 2 wrt having a high level review. I think it would be easier to discuss first what the library goals are or how it relates to other Boost libraries before going into the detailed technical review. Also, more people can contribute to the high level review but might not have time to go into the technical review.
This would help people working on related libraries to focus their
effort or even contribute when they were not planning to. Also, review time will be optimized and the review queue can be prioritized based on this list. The names can be proposed at this stage so that they are general as intended.
This could also help identify existing libraries that need to evolve, like the ongoing effort in Boost.Threads
How?
E.g. in the mailing list some people have previously identified shortcomings (or new feature requests) in the Property Options lib. but now there is a review for the PT library that has some overlap and also a broad feature set. I am suggesting there should be a way to handle these tradeoffs
2. Have a high level review before a detailed review
--------------------------------------------------------------------------
Everything you're proposing sounds like it adds more process, which can be extremely hard to manage and will probably slow things down.
No, just have two mailing list threads, one that agrees on the goals, relations to other libraries, ... and then go into the the normal review. It's just hard to mix both high level and low level discussions and I think many valuable contributors don't have the time to follow the high level issues buried within the technical discussion
a) Is the library in the priority list ?
And what if it isn't?
1) It is not because we missed it, 2) it is not because it is a specialized library or 3) it is not b/c it shouldn't be If 1) or 2) then ok . The priority list is not bureaucracy it is just a way to help others frame their opinions
b) Should it be a separate library or merge with an existing one ? There can
be lots of small libraries but many might not continue to evolve or be world-class.
The list is pretty self-regulating in this regard. By the time a library comes up for formal review, there should have been plenty of discussion on the list already. Have you read the process carefully?
I read it a while ago but you are right. Actually I am not an expert here, I am coming from the angle of a library user that wants more Boost libraries to solve a broader set of problems and not have to rely on corporate libraries.
c) Is the library really world-class or broadly useful?
That's the job of the review. If we do that in the "high level review" what's the point in having the "detailed review?"
Yes, but the current review is focused on just the technical merits, but why not look at the libraries also from a competitive standpoint, i.e. comparing more with other GNU and commercial ones (whenever possible). Also, I find a library could be world-class design and implementation but it is not "world-class" if is not tackling the right problems, even when using state of the art techniques. Hard to explain this succintly
The priority should be to add libraries that are designed with the
intent of becoming a world-class library (even if they offer limited functionality when reviewed). The outcome of the high level review should be whether to engage in a detailed review or wait till some conditions are met.
How would this improve anything? Many smart people are working on GNU libraries and some are willing to change the license and go through a review but nobody is contacting them b/c we are assuming that they have to request a review (and we are not clear how prioritary is to add such library)
3. Encourage specialized libraries
-------------------------------------------------
Who would do that encouraging, and how would he/she do it?
There are many libraries that have a smaller audience but if they are designed to be world-class then they bring value to boost.
Of couse. They aren't discouraged today.
But they are not encouraged. (just from looking at the goals in the home page)
Also, there has to be a process so that libraries can continue to
evolve once they are part of boost, considering that in many cases the original authors may not be available to contribute.
That's something we could use help in developing.
Yes. This is probably higher priority than my initial idea. A practical process is needed and am happy to contribute my ideas.
This needs thinking but it would be good to get more people to
contribute to libraries in which they were not the original authors.
Who would get those people to contribute, and how would he/she do it?
If there is a practical process at least more people would consider contributing without being asked. This I haven't thought enough about it to give some useful ideas. As I said before, my viewpoint is of the newbie user and not library developer regards