Improving the Boost Review process
I would like to bring up some ideas to improve the review process: 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 ? 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) ? 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 2. Have a high level review before a detailed review -------------------------------------------------------------------------- a) Is the library in the priority list ? 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. c) Is the library really world-class or broadly useful? There can be libraries that have multiple functionality but none is great. A good example for this is with libraries that incorporate some xml functionality but it's very limited and then you have to rely on another library for broader usage. 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. 3. Encourage specialized libraries ------------------------------------------------- There are many libraries that have a smaller audience but if they are designed to be world-class then they bring value to boost. 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. This needs thinking but it would be good to get more people to contribute to libraries in which they were not the original authors.
Jose wrote:
I would like to bring up some ideas to improve the review process:
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) ?
Just to get rid of some confusion here: The Property Tree Library does not have the same goal as the program option library and the two libraries are very different. The Property Tree Library does allow you to build quick option parsers, but this is not the main motivation for the library, and it is perfectly valid for a library to include such a facility in the review process. If the majority of reviewers actually think it is better to use the Program Option Library we can always exclude this particular part of The Property Tree Library. That said, my pre-review assessment as review manager was that the overlap was minimal. -Thorsten
On 4/20/06, Thorsten Ottosen <thorsten.ottosen@dezide.com> wrote:
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) ?
Just to get rid of some confusion here: The Property Tree Library does not have the same goal as the program option library and the two libraries are very different. The Property Tree Library does allow you to build quick option parsers, but this is not the main motivation for the library, and it is perfectly valid for a library to include such a facility in the review process. If the majority of reviewers actually think it is better to use the Program Option Library we can always exclude this particular part of The Property Tree Library. That said, my pre-review assessment as review manager was that the overlap was minimal.
In the case you raise, I am not saying some functionality should be excluded but maybe the PT lib should obsolete the PO lib. The PT lib goal is broad (compared to PO lib)
Jose wrote:
On 4/20/06, Thorsten Ottosen <thorsten.ottosen@dezide.com> wrote: That said, my
pre-review assessment as review manager was that the overlap was minimal.
In the case you raise, I am not saying some functionality should be excluded but maybe the PT lib should obsolete the PO lib.
I don't think that is relevant. The domain are sufficiently different and PT comes nowhere close to replacing PO. -Thorsten
In the case you raise, I am not saying some functionality should be excluded but maybe the PT lib should obsolete the PO lib. The PT lib goal is broad (compared to PO lib)
I'm sure program options should _not_ be obsoleted. They support many things property tree does not (and should not), like options descriptions and notifications. They also present quite a different interface that allows automatic verification/validation of options passed, automatic generation of help messages, and probably more stuff that I am not aware of. Best regards, Marcin
Marcin Kalicinski wrote:
I'm sure program options should _not_ be obsoleted. They support many things property tree does not (and should not), like options descriptions and notifications. They also present quite a different interface that allows automatic verification/validation of options passed, automatic generation of help messages, and probably more stuff that I am not aware of.
On the other hand, that is only frontend stuff, i.e. things that could be added to read_advanced_cmdline. The backing store could still be made a PT. Sebastian Redl
Jose <jmalv04@gmail.com> writes:
I would like to bring up some ideas to improve the review process:
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?
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?
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?
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.
a) Is the library in the priority list ?
And what if it isn't?
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?
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?"
There can be libraries that have multiple functionality but none is great. A good example for this is with libraries that incorporate some xml functionality but it's very limited and then you have to rely on another library for broader usage.
That sounds very theoretical. Have we had actual problems arise that would be addressed by this change?
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?
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.
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.
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? -- Dave Abrahams Boost Consulting www.boost-consulting.com
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
participants (5)
-
David Abrahams -
Jose -
Marcin Kalicinski -
Sebastian Redl -
Thorsten Ottosen