What is the status of the Boost.Property_tree library? I notice it is now in the SVN trunk. Does this mean it will be part of the next release? <https://svn.boost.org/svn/boost/trunk/boost/property_tree/> Thanks, Max
What is the status of the Boost.Property_tree library? I notice it is now in the SVN trunk. Does this mean it will be part of the next release?
<https://svn.boost.org/svn/boost/trunk/boost/property_tree/>
I really like the simplicity of this library but this is about the third or fourth request in the last few months without a reply. This is not a slight on the original author or this library, but it does bring up the more general question.. Does boost really want to put an 'unsupported' new library into a release? I'd suggest the release manager consider leaving such libraries in the sandbox if they haven't got a commitment from an individual and they haven't yet been incorporated in a release. A first release is likely to shake down a library more than the review process and it is at this point the author or perhaps a maintainer is valuable. Indeed many libraries change radically enough after the review that they often benefit tremendously from the shakedown that first release gives them. Perhaps new libs need a named sponsor as an entry criterion for incorporation? I also appreciate that the current monolithic boost release cycle can be difficult for new library authors to make a commitment to in advance. Hence the sponsor may not necessarily be the author. Once 'in', inevitably some maintainers will move on. I am grateful for their efforts and the library will then sink or swim on its merits. The issue of what to do or document for such libraries is not one I intended to cover in this email.
Paul Baxter wrote:
What is the status of the Boost.Property_tree library? I notice it is now in the SVN trunk. Does this mean it will be part of the next release?
<https://svn.boost.org/svn/boost/trunk/boost/property_tree/>
I really like the simplicity of this library but this is about the third or fourth request in the last few months without a reply.
If the library is really unsupported, I'd be willing to take over support. I think it's an extremely valuable library for quickly writing a configuration interface. Sebastian
Sebastian Redl wrote:
Paul Baxter wrote:
What is the status of the Boost.Property_tree library? I notice it is now in the SVN trunk. Does this mean it will be part of the next release?
<https://svn.boost.org/svn/boost/trunk/boost/property_tree/>
I really like the simplicity of this library but this is about the third or fourth request in the last few months without a reply.
If the library is really unsupported, I'd be willing to take over support. I think it's an extremely valuable library for quickly writing a configuration interface.
Sebastian _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
The property tree library is a very useful library. At my work, we use it a lot. We have also built some extensions to it, that lets you put (possible nested) STL containers and tuples in a property tree, using the tree structure of the property tree. If the original author has abandoned the library, then it would be great if Sebastian would take over. --Johan Råde
on Tue Mar 11 2008, Sebastian Redl <sebastian.redl-AT-getdesigned.at> wrote:
Paul Baxter wrote:
What is the status of the Boost.Property_tree library? I notice it is now in the SVN trunk. Does this mean it will be part of the next release?
<https://svn.boost.org/svn/boost/trunk/boost/property_tree/>
I really like the simplicity of this library but this is about the third or fourth request in the last few months without a reply.
If the library is really unsupported, I'd be willing to take over support. I think it's an extremely valuable library for quickly writing a configuration interface.
Sebastian, thanks for the offer! Could you contact Marcin Kalicinski <kalita-AT-poczta.onet.pl> about this issue? Note that, considering https://svn.boost.org/trac/boost/browser/trunk/libs/property_tree/index.html, we can't afford to release this in 1.35 -- Dave Abrahams Boost Consulting http://boost-consulting.com
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Paul Baxter
What is the status of the Boost.Property_tree library? I notice it is now in the SVN trunk. Does this mean it will be part of the next release?
<https://svn.boost.org/svn/boost/trunk/boost/property_tree/>
I really like the simplicity of this library but this is about the third or fourth request in the last few months without a reply.
This is not a slight on the original author or this library, but it does bring up the more general question..
Does boost really want to put an 'unsupported' new library into a release?
Yes - if it has adequate tests and they pass? If the library is failing tests or has a significant number of bug reports that have not been addressed it should not be included in the release. Given the current branching scheme as I understand it this should not be a significant problem and should not require the library to be "relegated" to the sandbox. There are obviously a range of possible risks here - a library containing a lot of template metaprogrammming and associated compiler dependent quirks/workarounds is, in general, more likely to: 1) Have latent bugs dependent on usage (as well as compiler) 2) Exhibit new/changed behaviour with new compiler releases The former of these should result in bug reports. The second should be found in automated testing. In any case, I don't believe Property_tree falls into this category and would seem to be a library that "anyone" could step up to the plate and elect to maintain. I would also hope that it would be a library that could be maintained relatively easily with the assistance of the broader boost community - ie. user submitted patches. With trac etc. in place this process should be more effective than it has been in the past. I should note in the particular case of Property_tree, I am a (new/recent) user. It works for me, if it didn't you would have a trac bug submission (with test and patch)... Of course with no maintainer, that might not be much help. ########################################################################## CONFIDENTIALITY NOTE: Please consider our environment before printing this email.This email and any attachments are confidential and may be subject to copyright, legal or some other professional privilege. They are intended solely for the attention and use of the named addressee(s). They may only be copied, distributed or disclosed with the consent of the copyright owner. If you have received this email by mistake or by breach of the confidentiality clause, please notify the sender immediately by return email and delete or destroy all copies of the email. Any confidentiality, privilege or copyright is not waived or lost because this email has been sent to you by mistake. ##########################################################################
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Darryl Green
########################################################################## CONFIDENTIALITY NOTE: Please consider our environment before printing this email.This email and any attachments are confidential and may be subject to copyright, legal or some other professional privilege....
Sorry - work have made some email improvements it seems. Last post from there. I hereby release the above email into the public domain. Anything expressed in that email is my own opinion and not that of my employer etc etc....
on Tue Mar 11 2008, "Darryl Green" <Darryl.Green-AT-maxgaming.com.au> wrote:
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Paul Baxter
What is the status of the Boost.Property_tree library? I notice it is now in the SVN trunk. Does this mean it will be part of the next release?
<https://svn.boost.org/svn/boost/trunk/boost/property_tree/>
I really like the simplicity of this library but this is about the third or fourth request in the last few months without a reply.
This is not a slight on the original author or this library, but it does bring up the more general question..
Does boost really want to put an 'unsupported' new library into a release?
Yes - if it has adequate tests and they pass?
Not without documentation. See https://svn.boost.org/trac/boost/browser/trunk/libs/property_tree/index.html That's an "over-my-dead-body" issue for me. -- Dave Abrahams Boost Consulting http://boost-consulting.com
On Wed, Mar 12, 2008 at 10:34 AM, David Abrahams <dave@boost-consulting.com> wrote:
Not without documentation. See https://svn.boost.org/trac/boost/browser/trunk/libs/property_tree/index.html That's an "over-my-dead-body" issue for me.
This might not have bearing on whether property_tree gets released, but there are some docs at: http://kaalus.atspace.com/ptree/doc/index.html Although, these docs seem a little outdated - at times I've noticed slight discrepancies between the docs and the code in trunk. I've found this to be a very useful little library, too bad it doesn't seem to be supported. Stjepan
On Wed, 2008-03-12 at 13:34 -0400, David Abrahams wrote:
on Tue Mar 11 2008, "Darryl Green" <Darryl.Green-AT-maxgaming.com.au> wrote: Not without documentation. See https://svn.boost.org/trac/boost/browser/trunk/libs/property_tree/index.html That's an "over-my-dead-body" issue for me.
True. There are docs in the sandbox version https://svn.boost.org/trac/boost/browser/sandbox/libs/property_tree/index.ht... which links to https://svn.boost.org/trac/boost/browser/sandbox/libs/property_tree/doc/inde... However, I take your point - the library is not release ready and needs at least some "housekeeping" done. Thanks to Sebastian Redl for offering to take on maintenance. Hopefully not too much work to do to get it release ready (post 1.35). My point remains that I don't think libs should be "relegated" from trunk because they are not release ready. The development guidelines docs don't seem to require this. A loss of release ready status (eg due to a new compiler/platform) can happen to any library, at any time, not just in the case of a newly accepted lib. Code that is not release ready should not be in the release branch, but trunk is another matter surely? When I started to look at what it would take to get property tree release ready I couldn't find any documentation on what a library developer (or contributor) needs to do to get a lib included in the tests? I don't have the faintest idea of how the regression test system works. Are there some docs somewhere? Property_tree is in the release branch. Despite this it is not in the test results. Unless there is some mechanism that stops a library in this condition from being included in the release proper this seems like a problem? --- Darryl Green
on Tue Mar 11 2008, "Paul Baxter" <pauljbaxter-AT-hotmail.com> wrote:
What is the status of the Boost.Property_tree library? I notice it is now in the SVN trunk. Does this mean it will be part of the next release?
<https://svn.boost.org/svn/boost/trunk/boost/property_tree/>
I really like the simplicity of this library but this is about the third or fourth request in the last few months without a reply.
This is not a slight on the original author or this library, but it does bring up the more general question..
Does boost really want to put an 'unsupported' new library into a release?
No.
I'd suggest the release manager consider leaving such libraries in the sandbox if they haven't got a commitment from an individual and they haven't yet been incorporated in a release.
Agreed. In the past we've always assumed that the library author is prepared to support it. Usually that's been a safe assumption, but not always.
A first release is likely to shake down a library more than the review process and it is at this point the author or perhaps a maintainer is valuable. Indeed many libraries change radically enough after the review that they often benefit tremendously from the shakedown that first release gives them.
Perhaps new libs need a named sponsor as an entry criterion for incorporation?
In fact, I don't think we should bother accepting review requests without a commitment from someone to support the code should it be accepted. Naming a responsible support party should be part of the review request requirements. -- Dave Abrahams Boost Consulting http://boost-consulting.com
participants (9)
-
Darryl Green -
Darryl Green -
darryl.green＠aanet.com.au
-
David Abrahams -
Johan Råde -
Max -
Paul Baxter -
Sebastian Redl -
Stjepan Rajko