Review Queue Needs Attention
Paul A. Bristow said
Yes - *exposure* is the key to inspiring authors to refine their contributions.
I've argued for some time for a 'experimental' or 'candidate' status.
(And a state not damned with faint praise like 'unstable' - which is perhaps better described as 'likely_to_be_improved' rather than actively 'not stable').
We'd need a simpler review process to agree to put a library into this 'candidate state' from the 'sandbox state'.
This would mean that when libraries are reviewed for full acceptance, they should have received much more use, feedback and refinement, and be really ready for use by those who want a 'release quality' stable product - including decent documentation.
Agreed. Here is the current review queue. 1) Lexer Ben Hanson 2) Shifted Pointer Phil Bouchard 3) Logging John Torjo 4) Join Yigong Liu 5) Pimpl Vladimir Batov 6) Task Oliver Kowalke 7) Endian Beman Dawes 8) Meta State Machine (MSM) Christophe Henry 9) Conversion Vicente Botet 10) Sorting Steven Ross 11) GIL.IO Christian Henning 12) AutoBuffer Thorsten Ottosen 14) Log Andrey Semashev 15) String Convert Vladimir Batov 16) Move Ion Gaztañaga 17) Containers Ion Gaztañaga 18) Interval Containers Joachim Faulhaber 19) Type Traits Extensions Frédéric Bron 20) Interthreads Vicente Botet 21) Bitfield Vicente Botet 22) Lockfree Ivo 23) Faster Signam slots Helge Bahmann The number of review requests is far outstripping the number of volunteer review managers. Considering about six libraries per year are getting reviewed, this is well over a three year back log. And this does not even include some other libraries that have been discussed, but not included. There are alot of good ideas here, they should not be ignored. Some of these libraries have been in the queue for over 18 months. My idea to fix this is well known. I would like something similar to Paul's approach. Those of you who have argued against a "non-stable" branch of boost, how would you propose fixing this "review queue" problem.
Zitat von Tom Brinkman <reportbase@gmail.com>:
The number of review requests is far outstripping the number of volunteer review managers.
is the lack of review managers the bottleneck of the review process right now? I`m relatively new to boost, but judging from the "notes for review managers" on the website that doesn`t sound like a lot of work. I'm planning to submit a library for review myself, and the prospect that that'd take 2 years isn't very encouraging, so I'd probably volunteer just for this reason alone. maybe you could regularily post a call for review managers to the mailing list, with a list and a short description of libraries in need of a review manager? btw, I sent a request for sandbox access to boost-owner recently, to upload a preview of my library to the sandbox. does that take a while or has the process of requesting access changed? I haven't received anything so far.
strasser@uni-bremen.de wrote:
Zitat von Tom Brinkman <reportbase@gmail.com>:
The number of review requests is far outstripping the number of volunteer review managers.
is the lack of review managers the bottleneck of the review process right now?
I`m relatively new to boost, but judging from the "notes for review managers" on the website that doesn`t sound like a lot of work. I'm planning to submit a library for review myself, and the prospect that that'd take 2 years isn't very encouraging, so I'd probably volunteer just for this reason alone.
maybe you could regularily post a call for review managers to the mailing list, with a list and a short description of libraries in need of a review manager?
btw, I sent a request for sandbox access to boost-owner recently, to upload a preview of my library to the sandbox. does that take a while or has the process of requesting access changed? I haven't received anything so far.
I would recommend that authors try find a review manager before they request a review. If no one is interested in being the review manager of a given library then it might be that the author mistook polite interest for serious interest in the determining interest phase. We can easily fix the problem of lack of review managers for proposed libraries by making it clear that it is the author's responsibility to find a review manager for their library. The author of a proposed library should ideally become part of the boost community. That process should start before the library is accepted, not after, and it is through that process that the author finds a review manager. Regards, Luke
Am Tuesday 24 November 2009 22:46:21 schrieb Simonson, Lucanus J:
I would recommend that authors try find a review manager before they request a review. If no one is interested in being the review manager of a given library then it might be that the author mistook polite interest for serious interest in the determining interest phase. We can easily fix the
I don't think the fact alone that noone is currently willing to perform some unappealing bureaucratic work (being a review manager) shows a lack of interest in a library. judging by the review schedule (almost no review managers), that would mean boost isn't very interested in new libraries in general. http://www.boost.org/community/review_schedule.html
Stefan Strasser-2 wrote:
Zitat von Tom Brinkman <reportbase@gmail.com>:
The number of review requests is far outstripping the number of volunteer review managers.
is the lack of review managers the bottleneck of the review process right now?
I`m relatively new to boost, but judging from the "notes for review managers" on the website that doesn`t sound like a lot of work. I'm planning to submit a library for review myself, and the prospect that that'd take 2 years isn't very encouraging, so I'd probably volunteer just for this reason alone.
This is exactly what I did.
maybe you could regularly post a call for review managers to the mailing list, with a list and a short description of libraries in need of a review manager?
The review wizard make a report regularly on the Past Review Results and Milestones page (http://www.boost.org/community/review_schedule.html) including the information you are requesting Review Wizard Status Report Ronald Garcia June 4, 2009 Report (http://www.boost.org/development/report-jun-2009.html) Best, Vicente -- View this message in context: http://old.nabble.com/Review-Queue-Needs-Attention-tp26500094p26507186.html Sent from the Boost - Dev mailing list archive at Nabble.com.
The number of review requests is far outstripping the number of volunteer review managers.
is the lack of review managers the bottleneck of the review process right now?
Maybe, reviewers start to disappear if we have too many reviews too fequently as well :-(
I`m relatively new to boost, but judging from the "notes for review managers" on the website that doesn`t sound like a lot of work. I'm planning to submit a library for review myself, and the prospect that that'd take 2 years isn't very encouraging, so I'd probably volunteer just for this reason alone.
It depends - if there's a lot of contentious discussion then producing a result and a summary of issues can be a bit of work. Other times it's a breaze 'cos it's very clear that the comments all go one way.
maybe you could regularily post a call for review managers to the mailing list, with a list and a short description of libraries in need of a review manager?
btw, I sent a request for sandbox access to boost-owner recently, to upload a preview of my library to the sandbox. does that take a while or has the process of requesting access changed? I haven't received anything so far.
My bad, there's an email invitation on it's way. John.
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Daniel James Sent: Wednesday, November 25, 2009 9:00 AM To: boost@lists.boost.org Subject: Re: [boost] Review Queue Needs Attention
Paul A. Bristow said
(And a state not damned with faint praise like 'unstable' - which is perhaps better described as 'likely_to_be_improved' rather than actively 'not stable').
The apache incubator might be a more appropriate inspiration than Debian unstable.
What's the difference between a non-stable branch as you're suggesting and the existing sandbox? The only difference I could see is to establish some kind of pre-review
I like 'incubator' :-) Hartmut Kaiser wrote process. Sandbox is vital for authors to develop code *jointly* - but for a long time it may not be fit for public consumption. OK, that will take some admin, but much less than a full review because it's not such a long-term commitment that a full review involves. It's pretty obvious if something is worth giving wider exposure. Competing libraries can happily compete ;-) (It would also take some admin to agree that some 'bad egg' libraries might be *removed* from the incubator - but that should be much less contentious too - author 'missing in action', no maintenance, no docs, no users, no progress...).
But that would just move the problem to a different spot, no?
OK It doesn't solve the review problem, but stuff that comes up for review should be in a finished (polished even) state - unlike too many of the things that come up for review. It should be easy to say 'not ready yet' to projects that lack documentation, user base, adequate testing etc without the risk of the authors giving up. As I see it, people are reluctant to put in the considerable amount of 'polishing' work to 'Boost Quality' unless they are reasonably confident that it will prove worth the effort. Incubating will build that confidence. Paul --- Paul A. Bristow Prizet Farmhouse Kendal, UK LA8 8AB +44 1539 561830, mobile +44 7714330204 pbristow@hetp.u-net.com
(And a state not damned with faint praise like 'unstable' - which is perhaps better described as 'likely_to_be_improved' rather than actively 'not stable').
The apache incubator might be a more appropriate inspiration than Debian unstable.
the current sandbox layout has the disadvantage, that single projects are present as sandbox/mylib, which do not run or compile on their own, but require a full set of the boost headers. in order to try out one sandbox library, you need to get the boost checkout/tarball and copy it to sandbox/mylib or vice versa ... it would be nice to have an `integrated' sandbox repository, though, which especially would help when synchronizing the development of libraries (e.g. boost.lockfree and boost.atomic). the linux kernel development has trees like linux-next or tip, which focus on bringing the sources together instead of keeping them apart (as in the current sandbox). for me personally, the boost sandbox does not help when working on code, but only when distributing the code ... best, tim -- tim@klingt.org http://tim.klingt.org Linux is like a wigwam: no windows, no gates, apache inside, stable.
This was sent to me off list. Presumably by mistake so I'm replying here. 2009/11/26 Tim Blechmann <tim@klingt.org>:
(And a state not damned with faint praise like 'unstable' - which is perhaps better described as 'likely_to_be_improved' rather than actively 'not stable').
The apache incubator might be a more appropriate inspiration than Debian unstable.
the current sandbox layout has the disadvantage, that single projects are present as sandbox/mylib, which do not run or compile on their own, but require a full set of the boost headers. in order to try out one sandbox library, you need to get the boost checkout/tarball and copy it to sandbox/mylib or vice versa ...
it would be nice to have an `integrated' sandbox repository, though, which especially would help when synchronizing the development of libraries (e.g. boost.lockfree and boost.atomic). the linux kernel development has trees like linux-next or tip, which focus on bringing the sources together instead of keeping them apart (as in the current sandbox). for me personally, the boost sandbox does not help when working on code, but only when distributing the code ...
best, tim
-- tim@klingt.org http://tim.klingt.org
Linux is like a wigwam: no windows, no gates, apache inside, stable.
We used to have an integrated sandbox, but it became a mess as everything got out of sync so we moved over to the current model. This was partly because we were using CVS at the time which doesn't have great support for branching. But even with better tools you're going to need someone to manage such a tree. It is possible to set up a library so that it can be used outside of the main tree, although I don't think it's very well documented and not many people bother. Daniel
This was sent to me off list. Presumably by mistake so I'm replying here.
was it? it should have been delivered via gmane.comp.lib.boost.devel
We used to have an integrated sandbox, but it became a mess as everything got out of sync so we moved over to the current model. This was partly because we were using CVS at the time which doesn't have great support for branching. But even with better tools you're going to need someone to manage such a tree.
true, it is not a development model suited for cvs/svn ... fortunately, there are other tools out there ... the work of maintaining an integrated tree would could possibly be automated and would probably reduce the work of both developers and `boost-proposed' testers. the development model of the linux kernel showed me how to keep a complex development structure simple ...
It is possible to set up a library so that it can be used outside of the main tree, although I don't think it's very well documented and not many people bother.
is there any documentation about this available? i would be curious to see ... for library developers it would be a great help to be able to use the boost test system, in order to see, if their code does compile on various platforms/compilers. an integrated `boost-proposed' tree could probably be easily integrated into the boost test system just like the `trunk' or `release' branches. this would greatly help library devs to write portable code ... tim -- tim@klingt.org http://tim.klingt.org Im übrigen ist es gescheiter, sich warm zuzudecken als sich zu betrinken. Werner Schwab
Tim Blechmann wrote:
(And a state not damned with faint praise like 'unstable' - which is perhaps better described as 'likely_to_be_improved' rather than actively 'not stable').
The apache incubator might be a more appropriate inspiration than Debian unstable.
the current sandbox layout has the disadvantage, that single projects are present as sandbox/mylib, which do not run or compile on their own, but require a full set of the boost headers. in order to try out one sandbox library, you need to get the boost checkout/tarball and copy it to sandbox/mylib or vice versa ...
Just to clarify -- what is wrong with starting with checkout of 'main' Boost tree, and then doing 2 "svn co" per any sandbox library you want to try? - Volodya
(And a state not damned with faint praise like 'unstable' - which is perhaps better described as 'likely_to_be_improved' rather than actively 'not stable').
The apache incubator might be a more appropriate inspiration than Debian unstable.
the current sandbox layout has the disadvantage, that single projects are present as sandbox/mylib, which do not run or compile on their own, but require a full set of the boost headers. in order to try out one sandbox library, you need to get the boost checkout/tarball and copy it to sandbox/mylib or vice versa ...
Just to clarify -- what is wrong with starting with checkout of 'main' Boost tree, and then doing 2 "svn co" per any sandbox library you want to try?
not sure, whether i understand it correctly. if i check out trunk and sandbox/mylib to myboost/ ... then myboost would contain 2 independent svn checkouts ... does `svn diff' show the diff with trunk or with sandbox/mylib then? tim -- tim@klingt.org http://tim.klingt.org Nothing exists until or unless it is observed. An artist is making something exist by observing it. And his hope for other people is that they will also make it exist by observing it. I call it 'creative observation.' Creative viewing. William S. Burroughs
Tim Blechmann wrote:
(And a state not damned with faint praise like 'unstable' - which is perhaps better described as 'likely_to_be_improved' rather than actively 'not stable').
The apache incubator might be a more appropriate inspiration than Debian unstable.
the current sandbox layout has the disadvantage, that single projects are present as sandbox/mylib, which do not run or compile on their own, but require a full set of the boost headers. in order to try out one sandbox library, you need to get the boost checkout/tarball and copy it to sandbox/mylib or vice versa ...
Just to clarify -- what is wrong with starting with checkout of 'main' Boost tree, and then doing 2 "svn co" per any sandbox library you want to try?
not sure, whether i understand it correctly. if i check out trunk and sandbox/mylib to myboost/ ... then myboost would contain 2 independent svn checkouts ... does `svn diff' show the diff with trunk or with sandbox/mylib then?
"svn diff" without arguments will show difference in 'main boost' "svn diff boost/mylib libs/mylib" will show the difference for the specified library -- but this is probably obvious. Is this a problem and what alternatives do you suggest? - Volodya
> (And a state not damned with faint praise like 'unstable' - which is perhaps > better described as 'likely_to_be_improved' rather than actively 'not stable').
The apache incubator might be a more appropriate inspiration than Debian unstable.
the current sandbox layout has the disadvantage, that single projects are present as sandbox/mylib, which do not run or compile on their own, but require a full set of the boost headers. in order to try out one sandbox library, you need to get the boost checkout/tarball and copy it to sandbox/mylib or vice versa ...
Just to clarify -- what is wrong with starting with checkout of 'main' Boost tree, and then doing 2 "svn co" per any sandbox library you want to try?
not sure, whether i understand it correctly. if i check out trunk and sandbox/mylib to myboost/ ... then myboost would contain 2 independent svn checkouts ... does `svn diff' show the diff with trunk or with sandbox/mylib then?
"svn diff" without arguments will show difference in 'main boost' "svn diff boost/mylib libs/mylib" will show the difference for the specified library -- but this is probably obvious.
Is this a problem and what alternatives do you suggest?
well, both checkouts wouldn't be synchronized ... a distributed version control system would fit for this use case way better ... i don't want to start a scm flamewar, but for me svn appears to be very limited compared to tools like git ... cheers, tim -- tim@klingt.org http://tim.klingt.org Who need fossil fuel when the sun ain't goin' nowhere Amiri Baraka
Tim Blechmann wrote:
>> (And a state not damned with faint praise like 'unstable' - which is perhaps >> better described as 'likely_to_be_improved' rather than actively 'not stable').
The apache incubator might be a more appropriate inspiration than Debian unstable.
the current sandbox layout has the disadvantage, that single projects are present as sandbox/mylib, which do not run or compile on their own, but require a full set of the boost headers. in order to try out one sandbox library, you need to get the boost checkout/tarball and copy it to sandbox/mylib or vice versa ...
Just to clarify -- what is wrong with starting with checkout of 'main' Boost tree, and then doing 2 "svn co" per any sandbox library you want to try?
not sure, whether i understand it correctly. if i check out trunk and sandbox/mylib to myboost/ ... then myboost would contain 2 independent svn checkouts ... does `svn diff' show the diff with trunk or with sandbox/mylib then?
"svn diff" without arguments will show difference in 'main boost' "svn diff boost/mylib libs/mylib" will show the difference for the specified library -- but this is probably obvious.
Is this a problem and what alternatives do you suggest?
well, both checkouts wouldn't be synchronized ... a distributed version control system would fit for this use case way better ... i don't want to start a scm flamewar, but for me svn appears to be very limited compared to tools like git ...
We could probably indeed start a nice flamewar on version control, but before we go that route, I wanted to double check. Is this inconvenience of combining sanbbox libraries with main release the primary issue with the current organization of sandbox? Or there are other issues? Could you list them? Because if it's the only issue, we're doing pretty well ;-) - Volodya
not sure, whether i understand it correctly. if i check out trunk and sandbox/mylib to myboost/ ... then myboost would contain 2 independent svn checkouts ... does `svn diff' show the diff with trunk or with sandbox/mylib then?
"svn diff" without arguments will show difference in 'main boost' "svn diff boost/mylib libs/mylib" will show the difference for the specified library -- but this is probably obvious.
Is this a problem and what alternatives do you suggest?
well, both checkouts wouldn't be synchronized ... a distributed version control system would fit for this use case way better ... i don't want to start a scm flamewar, but for me svn appears to be very limited compared to tools like git ...
We could probably indeed start a nice flamewar on version control, but before we go that route, I wanted to double check. Is this inconvenience of combining sanbbox libraries with main release the primary issue with the current organization of sandbox? Or there are other issues? Could you list them?
Because if it's the only issue, we're doing pretty well ;-)
consider the following use case: boost (upstream) contains boost/memory_order.hpp my_lib uses boost/memory_order.hpp boost (upstream) doesn't define memory_order_consume, my_lib requires memory_order_consume to be defined in boost/memory_order.hpp so both repository checkout clash ... using one merged git repository, this is no issue (possibly the same with mercurial or bazaar) best, tim -- tim@klingt.org http://tim.klingt.org Avoid the world, it's just a lot of dust and drag and means nothing in the end. Jack Kerouac
On Friday 11 December 2009 13:20:53 Tim Blechmann wrote:
not sure, whether i understand it correctly. if i check out trunk and sandbox/mylib to myboost/ ... then myboost would contain 2 independent svn checkouts ... does `svn diff' show the diff with trunk or with sandbox/mylib then?
"svn diff" without arguments will show difference in 'main boost' "svn diff boost/mylib libs/mylib" will show the difference for the specified library -- but this is probably obvious.
Is this a problem and what alternatives do you suggest?
well, both checkouts wouldn't be synchronized ... a distributed version control system would fit for this use case way better ... i don't want to start a scm flamewar, but for me svn appears to be very limited compared to tools like git ...
We could probably indeed start a nice flamewar on version control, but before we go that route, I wanted to double check. Is this inconvenience of combining sanbbox libraries with main release the primary issue with the current organization of sandbox? Or there are other issues? Could you list them?
Because if it's the only issue, we're doing pretty well ;-)
consider the following use case: boost (upstream) contains boost/memory_order.hpp my_lib uses boost/memory_order.hpp
boost (upstream) doesn't define memory_order_consume, my_lib requires memory_order_consume to be defined in boost/memory_order.hpp
And -- what version of what does contain those function there?
so both repository checkout clash ... using one merged git repository, this is no issue (possibly the same with mercurial or bazaar)
Probably the same using SVN. If somebody has a branch called 'memory_order_with_cool_functions', and you have branch called 'tim', then it's not clear to me why you cannot merge relevant commits from 'memory_order_with_cool_functions' to 'tim'. Is this a real use case? If so, maybe you can point me at URLs and we'll check in detail? - Volodya
consider the following use case: boost (upstream) contains boost/memory_order.hpp my_lib uses boost/memory_order.hpp
boost (upstream) doesn't define memory_order_consume, my_lib requires memory_order_consume to be defined in boost/memory_order.hpp
And -- what version of what does contain those function there?
boost-1.41 doesn't contain memory_order_consume, in my use case, boost.atomic does need memory_order_consume. so the boost.atomic repository should provide an updated boost/memory_order.hpp, which is not possible when using 2 svn repositories, is it?
so both repository checkout clash ... using one merged git repository, this is no issue (possibly the same with mercurial or bazaar)
Probably the same using SVN. If somebody has a branch called 'memory_order_with_cool_functions', and you have branch called 'tim', then it's not clear to me why you cannot merge relevant commits from 'memory_order_with_cool_functions' to 'tim'.
- upcoming boost libraries using the sandbox layout do not provide the boost upstream code - svn doesn't provide local branches, does it? - builing `out of place' is undocumented/ugly/hard to configure
Is this a real use case? If so, maybe you can point me at URLs and we'll check in detail?
you can find the boost.atomic code in helge's git repository: http://git.chaoticmind.net/cgi-bin/cgit.cgi/boost.atomic/ tim -- tim@klingt.org http://tim.klingt.org The aim of education is the knowledge, not of facts, but of values William S. Burroughs
On Friday 11 December 2009 13:35:33 Tim Blechmann wrote:
consider the following use case: boost (upstream) contains boost/memory_order.hpp my_lib uses boost/memory_order.hpp
boost (upstream) doesn't define memory_order_consume, my_lib requires memory_order_consume to be defined in boost/memory_order.hpp
And -- what version of what does contain those function there?
boost-1.41 doesn't contain memory_order_consume, in my use case, boost.atomic does need memory_order_consume. so the boost.atomic repository should provide an updated boost/memory_order.hpp, which is not possible when using 2 svn repositories, is it?
Why do you need 2 svn repositories in the first place?
so both repository checkout clash ... using one merged git repository, this is no issue (possibly the same with mercurial or bazaar)
Probably the same using SVN. If somebody has a branch called 'memory_order_with_cool_functions', and you have branch called 'tim', then it's not clear to me why you cannot merge relevant commits from 'memory_order_with_cool_functions' to 'tim'.
- upcoming boost libraries using the sandbox layout do not provide the boost upstream code - svn doesn't provide local branches, does it? - builing `out of place' is undocumented/ugly/hard to configure
Hmm, that does not actually answer my question. If you have a library that cannot work with trunk or release, then you naturally need to put together a branch of Boost that your library can work this. And if you do that, it makes sense to include that library in the tree as well. So, that would be: 1: somebody else svn copy ^/trunk ^/branches/improved_memory_order svn switch ^/branches/improved_memory_order <hack-hack> svn commit -m "Very good" 2. You, later svn copy ^/branches/improved_memory_order ^/branches/atomic svn switch ^/branches/atomic svn add boost/atomic libs/atomic <hack some more> svn commit -m "Initial version" Is there any reason why this would not work? Note that it means you no longer develop your library using the same layout as most sandbox libraries, but it's a consequence of the fact that you depend on a version of code not in trunk.
Is this a real use case? If so, maybe you can point me at URLs and we'll check in detail?
you can find the boost.atomic code in helge's git repository: http://git.chaoticmind.net/cgi-bin/cgit.cgi/boost.atomic/
Oh. Obviously, if your code is in git, then you cannot use "svn merge" with it ;-) - Volodya
consider the following use case: boost (upstream) contains boost/memory_order.hpp my_lib uses boost/memory_order.hpp
boost (upstream) doesn't define memory_order_consume, my_lib requires memory_order_consume to be defined in boost/memory_order.hpp
And -- what version of what does contain those function there?
boost-1.41 doesn't contain memory_order_consume, in my use case, boost.atomic does need memory_order_consume. so the boost.atomic repository should provide an updated boost/memory_order.hpp, which is not possible when using 2 svn repositories, is it?
Why do you need 2 svn repositories in the first place?
your idea: http://article.gmane.org/gmane.comp.lib.boost.devel/197000
so both repository checkout clash ... using one merged git repository, this is no issue (possibly the same with mercurial or bazaar)
Probably the same using SVN. If somebody has a branch called 'memory_order_with_cool_functions', and you have branch called 'tim', then it's not clear to me why you cannot merge relevant commits from 'memory_order_with_cool_functions' to 'tim'.
- upcoming boost libraries using the sandbox layout do not provide the boost upstream code - svn doesn't provide local branches, does it? - builing `out of place' is undocumented/ugly/hard to configure
Hmm, that does not actually answer my question. If you have a library that cannot work with trunk or release, then you naturally need to put together a branch of Boost that your library can work this. And if you do that, it makes sense to include that library in the tree as well. So, that would be:
1: somebody else
svn copy ^/trunk ^/branches/improved_memory_order svn switch ^/branches/improved_memory_order <hack-hack> svn commit -m "Very good"
2. You, later
svn copy ^/branches/improved_memory_order ^/branches/atomic svn switch ^/branches/atomic svn add boost/atomic libs/atomic <hack some more> svn commit -m "Initial version"
Is there any reason why this would not work? Note that it means you no longer develop your library using the same layout as most sandbox libraries, but it's a consequence of the fact that you depend on a version of code not in trunk.
nothing wrong with this, if you have a sandbox svn account ...
Is this a real use case? If so, maybe you can point me at URLs and we'll check in detail?
you can find the boost.atomic code in helge's git repository: http://git.chaoticmind.net/cgi-bin/cgit.cgi/boost.atomic/
Oh. Obviously, if your code is in git, then you cannot use "svn merge" with it ;-)
the increased productivity with using git does well outperform the lost productivity of not being able to use `svn merge' ... but, well, i don't want to start a flame war ... and since i don't have to use svn for my development, i don't care ... i am a happy user of the git repositories of boost (svn mirror), boost.atomic and boost.lockfree, though ... using svn for this would be possible, but quite a pain (i guess you can read `git' as `professional distributed version control system') tim -- tim@klingt.org http://tim.klingt.org The first question I ask myself when something doesn't seem to be beautiful is why do I think it's not beautiful. And very shortly you discover that there is no reason. John Cage.
Tim Blechmann wrote:
consider the following use case: boost (upstream) contains boost/memory_order.hpp my_lib uses boost/memory_order.hpp
boost (upstream) doesn't define memory_order_consume, my_lib requires memory_order_consume to be defined in boost/memory_order.hpp
And -- what version of what does contain those function there?
boost-1.41 doesn't contain memory_order_consume, in my use case, boost.atomic does need memory_order_consume. so the boost.atomic repository should provide an updated boost/memory_order.hpp, which is not possible when using 2 svn repositories, is it?
Why do you need 2 svn repositories in the first place?
your idea: http://article.gmane.org/gmane.comp.lib.boost.devel/197000
That was before you told you have cross-dependencies between sandbox libraries. If there is, I would imagine the branches have to be created in the same repository where trunk lives.
so both repository checkout clash ... using one merged git repository, this is no issue (possibly the same with mercurial or bazaar)
Probably the same using SVN. If somebody has a branch called 'memory_order_with_cool_functions', and you have branch called 'tim', then it's not clear to me why you cannot merge relevant commits from 'memory_order_with_cool_functions' to 'tim'.
- upcoming boost libraries using the sandbox layout do not provide the boost upstream code - svn doesn't provide local branches, does it? - builing `out of place' is undocumented/ugly/hard to configure
Hmm, that does not actually answer my question. If you have a library that cannot work with trunk or release, then you naturally need to put together a branch of Boost that your library can work this. And if you do that, it makes sense to include that library in the tree as well. So, that would be:
1: somebody else
svn copy ^/trunk ^/branches/improved_memory_order svn switch ^/branches/improved_memory_order <hack-hack> svn commit -m "Very good"
2. You, later
svn copy ^/branches/improved_memory_order ^/branches/atomic svn switch ^/branches/atomic svn add boost/atomic libs/atomic <hack some more> svn commit -m "Initial version"
Is there any reason why this would not work? Note that it means you no longer develop your library using the same layout as most sandbox libraries, but it's a consequence of the fact that you depend on a version of code not in trunk.
nothing wrong with this, if you have a sandbox svn account ...
In practice, getting a SVN account takes a day at most.
Is this a real use case? If so, maybe you can point me at URLs and we'll check in detail?
you can find the boost.atomic code in helge's git repository: http://git.chaoticmind.net/cgi-bin/cgit.cgi/boost.atomic/
Oh. Obviously, if your code is in git, then you cannot use "svn merge" with it ;-)
the increased productivity with using git does well outperform the lost productivity of not being able to use `svn merge' ...
So, it appears we've arrived at the following list of issue with the current official arrangement. - sandbox is physically different SVN repository, - handling cross-dependencies between sandbox libraries require full branches, as opposed to just boost/X + libs/X layout - getting SVN access is hard (in your opinion) - git makes you, personally, more productive Is that correct understanding? - Volodya
So, it appears we've arrived at the following list of issue with the current official arrangement. - sandbox is physically different SVN repository, - handling cross-dependencies between sandbox libraries require full branches, as opposed to just boost/X + libs/X layout - getting SVN access is hard (in your opinion)
actually, i am not interested in using the sandbox svn for development ... so i don't care how hard it is to get an svn account ...
- git makes you, personally, more productive
among other issues, because subversion doesn't support local branches and subversion's `svn merge' is nowhere near the power of `git merge' (not to speak of `git rebase')
Is that correct understanding?
more or less :) tim -- tim@klingt.org http://tim.klingt.org A year ago, six months ago, I thought that I was an artist. I no longer think about it, I am. Henry Miller
Tim Blechmann wrote:
So, it appears we've arrived at the following list of issue with the current official arrangement. - sandbox is physically different SVN repository, - handling cross-dependencies between sandbox libraries require full branches, as opposed to just boost/X + libs/X layout - getting SVN access is hard (in your opinion)
actually, i am not interested in using the sandbox svn for development ... so i don't care how hard it is to get an svn account ...
- git makes you, personally, more productive
among other issues, because subversion doesn't support local branches and subversion's `svn merge' is nowhere near the power of `git merge' (not to speak of `git rebase')
I guess these are points that are hard to discuss without getting into highly subjective matters like which features of merge operation are important — not to mention that such matters are offtopic here.
Is that correct understanding?
more or less :)
Thanks, then I've learned what I wanted to know. - Volodya
Vladimir Prus wrote:
Tim Blechmann wrote:
(And a state not damned with faint praise like 'unstable' - which is perhaps better described as 'likely_to_be_improved' rather than actively 'not stable'). The apache incubator might be a more appropriate inspiration than Debian unstable. the current sandbox layout has the disadvantage, that single projects are present as sandbox/mylib, which do not run or compile on their own, but require a full set of the boost headers. in order to try out one sandbox library, you need to get the boost checkout/tarball and copy it to sandbox/mylib or vice versa ...
Just to clarify -- what is wrong with starting with checkout of 'main' Boost tree, and then doing 2 "svn co" per any sandbox library you want to try?
It's not easy to tell the differences between main trunk and the sandbox library, it feels like polluting your boost trunk, you probably need to have different copies of your trunk lying around with or without certain libraries enabled, basically, it's quite a pain to manage. I think providing a Jamfile for the sandbox that would allow to "enable" sandbox pseudo-branches while trying to compile BOOST_ROOT would be very nice. That way you would just checkout the sandbox separately and not pollute anything else, you just use BOOST_ROOT for reference for what you lack. Sure, using actual real branches might be better, but I personally believe that makes the barrier to entry quite higher. Another thing that would make the sandbox feel more serious or involved would be automated tests. I suppose one variant on one platform would be enough, it doesn't even need to be as regular as the trunk.
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Mathias Gaunard Sent: Friday, December 11, 2009 12:25 PM To: boost@lists.boost.org Subject: Re: [boost] Review Queue Needs Attention
Vladimir Prus wrote:
Tim Blechmann wrote:
(And a state not damned with faint praise like 'unstable' - which is
perhaps
better described as 'likely_to_be_improved' rather than actively 'not stable'). The apache incubator might be a more appropriate inspiration than Debian unstable. the current sandbox layout has the disadvantage, that single projects are present as sandbox/mylib, which do not run or compile on their own, but require a full set of the boost headers. in order to try out one sandbox library, you need to get the boost checkout/tarball and copy it to sandbox/mylib or vice versa ...
Just to clarify -- what is wrong with starting with checkout of 'main' Boost tree, and then doing 2 "svn co" per any sandbox library you want to try?
It's not easy to tell the differences between main trunk and the sandbox library, it feels like polluting your boost trunk, you probably need to have different copies of your trunk lying around with or without certain libraries enabled, basically, it's quite a pain to manage.
I think providing a Jamfile for the sandbox that would allow to "enable" sandbox pseudo-branches while trying to compile BOOST_ROOT would be very nice. That way you would just checkout the sandbox separately and not pollute anything else, you just use BOOST_ROOT for reference for what you lack.
Sure, using actual real branches might be better, but I personally believe that makes the barrier to entry quite higher.
Another thing that would make the sandbox feel more serious or involved would be automated tests. I suppose one variant on one platform would be enough, it doesn't even need to be as regular as the trunk.
I think this goes to the nub of the problem - the feeling that sandbox stuff isn't quite 'ready to try' (as opposed to trunk and release which are 'ready to use'). Don't we need a proper 'ready to try' section which has an identical structure to trunk, and for which there should be *some* tests and *some* docs (even if these are placeholders for more complete test and docs)? The hurdle to getting into 'ready to try' could be modest, but higher than sandbox or vault - perhaps needing a sponsor or few? It would be nice if the tests could be run automatically as trunk, but at least users could run the tests (and examples and docs) themselves. We could expect stuff that was claimed to be 'review-ready' to be in this form. It would help reviews if remarks could specify the revision number. But most important it should also mean that far more people have actually used libraries before review proper. The 'ready to try' stuff could also be packaged up into a zip, perhaps at the same time as each proper release, so that those without SVN could also use them. This would reduce the potential load on the SVN server and make it widely available. Paul --- Paul A. Bristow Prizet Farmhouse Kendal, UK LA8 8AB +44 1539 561830, mobile +44 7714330204 pbristow@hetp.u-net.com
participants (11)
-
Daniel James -
John Maddock -
Mathias Gaunard -
Paul A. Bristow -
Simonson, Lucanus J -
Stefan Strasser -
strasser＠uni-bremen.de
-
Tim Blechmann -
Tom Brinkman -
Vicente Botet Escriba -
Vladimir Prus