Re: [boost] Re: Type of Review for UnorderedAssociativeContainers&HashFunctions
----- Mensaje original ----- De: Daniel James <daniel@calamity.org.uk> Fecha: Sábado, Febrero 26, 2005 5:40 pm Asunto: [boost] Re: Type of Review for UnorderedAssociativeContainers&HashFunctions
I think tr components should be allowed special status. What's
Thorsten Ottosen wrote: the point in
putting tr components through a normal review, when there can be no interface changes?
If the definition of fast-track review is not suitable for tr components, then let us call it a tr review. The important aspect of such a review is that it should be fast.
Fast as in soon? Or just spending less time on the review? I don't mind waiting in the review queue so unless anyone really wants to see this in Boost as soon as possible, I guess that Boost.Hash should be fast tracked, Boost.Unordered should go in the queue, maybe for a shorter than normal review. Is that okay with everyone?
Is perfect with me at least :) I guess the review wizard should allocate a period for fasttrack reviewing Boost.Hash (which, if I understand it OK, can run in paralel with other regular reviews.) Tom? As for my negative vote to accepting Boost.Unordered for fasttrack, my main concern is that other authors are patiently standing in line for their own reviews, and the size and scope of this library does not justify for a fasttrack treatment, in my humble opinion. Other than that I think the lib is needed and will eventually make it into Boost. Best, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
"JOAQUIN LOPEZ MU?Z" <joaquin@tid.es> wrote in message news:32ded832c0cd.32c0cd32ded8@tid.es...
I think tr components should be allowed special status. What's
Thorsten Ottosen wrote: the point in
putting tr components through a normal review, when there can be no interface changes?
| As for my negative vote to accepting Boost.Unordered for | fasttrack, my main concern is that other authors are patiently | standing in line for their own reviews, and the size and scope | of this library does not justify for a fasttrack treatment, in | my humble opinion. Other than that I think the lib is needed | and will eventually make it into Boost. IMO any TR compliant component should be allowed into boost without any major review. It's already been through a major year-long review in the standard committee. If some brilliant mind would like to submit a new and different hash-container to boost with more policies and stuff, then he can still do it. That doesn't mean we should have the tr components. Some people have actually spend a lot of time to implement this component, they deserve a fast track-review, so we can all start using it. As for the review queue, then we went by for moths without reviews. I'll suggest that we'll try to avoid that instead. -Thorsten
"Thorsten Ottosen" <nesotto@cs.auc.dk> writes:
"JOAQUIN LOPEZ MU?Z" <joaquin@tid.es> wrote in message news:32ded832c0cd.32c0cd32ded8@tid.es...
I think tr components should be allowed special status. What's
Thorsten Ottosen wrote: the point in
putting tr components through a normal review, when there can be no interface changes?
| As for my negative vote to accepting Boost.Unordered for | fasttrack, my main concern is that other authors are patiently | standing in line for their own reviews, and the size and scope | of this library does not justify for a fasttrack treatment, in | my humble opinion. Other than that I think the lib is needed | and will eventually make it into Boost.
IMO any TR compliant component should be allowed into boost without any major review. It's already been through a major year-long review in the standard committee.
As far as I'm concerned, the test suite for a TR component is the most important part of any submission that implements it. The test suite deserves careful scrutiny. Maybe not two weeks of scrutiny, but probably a week. -- Dave Abrahams Boost Consulting www.boost-consulting.com
participants (3)
-
David Abrahams -
JOAQUIN LOPEZ MU?Z -
Thorsten Ottosen