Re: [boost] is review system in place is extremely slow? (wasRe:[rfc] rcpp)
From Robert Ramey
to move those 3 libraries to the 'detail' namespace of Boost.Task and have review as it is, as opposed to waiting. What do you think?
I think I caught hell for doing something similar in the serialization library. I had to make a number of components such as BOOST_STRONGTYPEDEF, state_saver, smart_cast, etc. which I put into boost - (not detail) and year afterwards this was raised as a huge problem. And this was even though the components had been their through two reviews. So I would be careful about doing this.
This seems a little more negative than I remember. If we are thinking of the same thread (see e.g. http://lists.boost.org/Archives/boost/2007/11/130567.php ) then a lot of the discussion was about headers directly in the boost root directory rather than a subdirectory, rather the issue at hand. My opinion is that there is no overarching programming design deity that is going to come down and smite us if we be a bit pragmatic. So what if Move [*], Fiber and Atomic get "smuggled" in if Task gets reviewed and accepted first? They don't have to be documented as accepted - on the contrary the documentation could have appropriate warnings as *not* formally accepted apart for indirect use via Task.
Another issue is: if Boost.Task depends upon Boost.Fiber and Boost.Atomic, what happens if the Boost.Fiber or Boost .Atomic are not approved?
Sometimes the laudable goal of perfection turns open source projects into games of Nomic! Again, pragmatism should play a role here else Boost will never be the rich and full set of libraries that it fantastically could be. Pete [*] Move seems so core these days - another bit of pragmatism would see that fast-tracked through.
Pete Bartlett wrote:
My opinion is that there is no overarching programming design deity that is going to come down and smite us if we be a bit pragmatic. So what if Move [*], Fiber and Atomic get "smuggled" in if Task gets reviewed and accepted first? They don't have to be documented as accepted - on the contrary the documentation could have appropriate warnings as *not* formally accepted apart for indirect use via Task.
It looks like the author of Atomic has not even asked for a review, since it is not in the schedule. I can't even find Atomic in the vault or sandbox. I looked at Fiber in the vault and sandbox and it has no documentation. If a library has no documentation it is not a library, its just code. I looked at Move in the sandbox and it also has no documentation. If documented properly Move probably could be fast tracked because there is so little code there. Rather than direct frustration at boost for the slowness of the review process, how about directing your frustration at the library authors who aren't bothering to write documentation and get into the review queue? Who would agree to be review manager for a library with no documentation? I think acceptance into boost sounds like a great idea to a lot of talented programmers until they find out they have to spent significant effort writing high quality documentation. For the ones who follow through the review process works just fine. Once the libraries are in a state where they could be accepted and the authors are active in requesting a review and looking for a review manager and it still isn't happening then you can complain that the process itself is broken. If you want these libraries accepted why don't you go ahead and take over responsibility for them, get the documentation up to acceptable standards and ask for reviews yourself? Regards, Luke
On 24 February 2010 23:25, Simonson, Lucanus J <lucanus.j.simonson@intel.com> wrote:
I looked at Fiber in the vault and sandbox and it has no documentation. If a library has no documentation it is not a library, its just code. I looked at Move in the sandbox and it also has no documentation. If documented properly Move probably could be fast tracked because there is so little code there.
Both libraries have documentation. You need to look under their 'libs' directories. Daniel
Hi, ----- Original Message ----- From: "Simonson, Lucanus J" <lucanus.j.simonson@intel.com> To: <boost@lists.boost.org> Sent: Thursday, February 25, 2010 12:25 AM Subject: Re: [boost] is review system in place is extremelyslow? (wasRe:[rfc] rcpp)
Pete Bartlett wrote:
My opinion is that there is no overarching programming design deity that is going to come down and smite us if we be a bit pragmatic. So what if Move [*], Fiber and Atomic get "smuggled" in if Task gets reviewed and accepted first? They don't have to be documented as accepted - on the contrary the documentation could have appropriate warnings as *not* formally accepted apart for indirect use via Task.
It looks like the author of Atomic has not even asked for a review, since it is not in the schedule. I can't even find Atomic in the vault or sandbox.
You are right, but the dependency is purely for internal implementation. So no matter for this library. Anyway, you can find a link here https://svn.boost.org/trac/boost/wiki/LibrariesUnderConstruction#Boost.Atomi....
I looked at Fiber in the vault and sandbox and it has no documentation. If a library has no documentation it is not a library, its just code. The link you can find on http://www.boost.org/community/review_schedule.html is broken. The previous link contained libraries Move and Atomic with its respective documentations. Oliver, please can you restore the link?
I looked at Move in the sandbox and it also has no documentation. If documented properly Move probably could be fast tracked because there is so little code there.
The links in http://www.boost.org/community/review_schedule.html works for me.
Rather than direct frustration at boost for the slowness of the review process, how about directing your frustration at the library authors who aren't bothering to write documentation and get into the review queue? Who would agree to be review manager for a library with no documentation? I think acceptance into boost sounds like a great idea to a lot of talented programmers until they find out they have to spent significant effort writing high quality documentation. For the ones who follow through the review process works just fine. Once the libraries are in a state where they could be accepted and the authors are active in requesting a review and looking for a review manager and it still isn't happening then you can complain that the process itself is broken.
All the libraries on the review schedule have their documentation and the authors are doing a good work. There is not issue for this point. Errors as the broken-link are human. Best, Vicente
vicente.botet wrote:
I looked at Move in the sandbox and it also has no documentation. If documented properly Move probably could be fast tracked because there is so little code there.
The links in http://www.boost.org/community/review_schedule.html works for me.
My mistake, and my appologies to the library authors. The documentation for Move looks nicer than my own. Regards, Luke
Pete Bartlett wrote:
From Robert Ramey
to move those 3 libraries to the 'detail' namespace of Boost.Task and have review as it is, as opposed to waiting. What do you think?
I think I caught hell for doing something similar in the serialization library. I had to make a number of components such as BOOST_STRONGTYPEDEF, state_saver, smart_cast, etc. which I put into boost - (not detail) and year afterwards this was raised as a huge problem. And this was even though the components had been their through two reviews. So I would be careful about doing this.
This seems a little more negative than I remember. If we are thinking of the same thread (see e.g. http://lists.boost.org/Archives/boost/2007/11/130567.php ) then a lot of the discussion was about headers directly in the boost root directory rather than a subdirectory, rather the issue at hand.
Hmmm - I thought ..Fiber and Atomic were intended to be put into boost/.. rather than boost/detail/... In any case there is lots of stuff in boost/ and no clear policy about it. Note that I'm not advocating one thing or another. Rather I'm relating that the lack of definition on this created a lot of problem for me in the past, in spite of the best of intentions. Robert Ramey
participants (5)
-
Daniel James -
Pete Bartlett -
Robert Ramey -
Simonson, Lucanus J -
vicente.botet