[review queue] What to do about the library review queue?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
158 messages Options
12345678
Reply | Threaded
Open this post in threaded view
|

Re: [partly OT] Re: [review queue] What to do about the library review queue?

Boost - Dev mailing list


> -----Original Message-----
> From: Boost [mailto:[hidden email]] On Behalf Of Vinnie Falco via Boost
> Sent: 16 March 2017 12:10
> To: [hidden email]
> Cc: Vinnie Falco
> Subject: Re: [boost] [partly OT] Re: [review queue] What to do about the library review queue?
>
> On Thu, Mar 16, 2017 at 8:06 AM, Glen Fernandes via Boost
> <[hidden email]> wrote:
> > ...until we truly move to Github Issues
>
> What needs to be done in order to make this happen?

Make sure that we do not lose the BIG history in Trac, including many links documentation issues in Trac,  (for example
https://svn.boost.org/trac/boost/ticket/12908), and make all this available in GitHub.

Nobody has been prepared to do this, so many projects are still using Trac.

If projects are moving to use GitHub instead (or starting new projects using GitHub entirely), it would be helpful if somehow users
who referred to Trac to find or report bugs would be altered to this.  I don't know how to do this, but it would be a first step.
(I'd also like to know how best to provide an equivalent to the above examples of a link to Trac).

After a decade or two, the stuff in Trac will become of historical interest only, but until then ...

Paul

---
Paul A. Bristow
Prizet Farmhouse
Kendal UK LA8 8AB
+44 (0) 1539 561830









_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [partly OT] Re: [review queue] What to do about the library review queue?

Boost - Dev mailing list
On Thu, Mar 16, 2017 at 8:57 AM, Paul A. Bristow via Boost
<[hidden email]> wrote:
> If projects are moving to use GitHub instead (or starting new projects using
> GitHub entirely)

If my library makes it into Boost I would vastly prefer to continue
using GitHub issues

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [review queue] What to do about the library review queue?

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 15/03/2017 18:30, Olaf van der Spek wrote:
> On Wed, Mar 15, 2017 at 5:16 PM, Niall Douglas via Boost
> <[hidden email]> wrote:
>> There are increasing problems with Boost.ASIO as it gets ever further
>> away from ASIO.
>
> Why is Boost Asio diverging from Asio?

Boost.ASIO has always had a more conservative update track to ASIO
(Boost.ASIO is auto generated by script from ASIO), but since the
Networking TS was voted in, only serious bug fixes from ASIO have been
backported to Boost.ASIO as ASIO has effectively become unstable due to
the pace of changes.

Particularly big changes lie around the strands implementation judging
from the noise of complaint about it. There are a fair few more big
differences in API, features supported, scalability and so on.

Niall

--
ned Productions Limited Consulting
http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [partly OT] Re: [review queue] What to do about the library review queue?

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 16/03/2017 12:10, Vinnie Falco via Boost wrote:
> On Thu, Mar 16, 2017 at 8:06 AM, Glen Fernandes via Boost
> <[hidden email]> wrote:
>> ...until we truly move to Github Issues
>
> What needs to be done in order to make this happen?

A decision needs to be taken on how best to port the Trac issues into
github.

Some years ago I volunteered to upgrade Trac to a version capable of
auto syncing github and Trac issues because the Trac we use is very,
very ancient and is a giant unpatched security hole.

I got nowhere, so I gave up. You'd be surprised how hard it is to change
anything spanning more than one library at Boost.

Niall

--
ned Productions Limited Consulting
http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [review queue] What to do about the library review queue?

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list


On 3/15/17 13:26, Robert Ramey via Boost wrote:

> On 3/14/17 2:53 PM, Robert Ramey via Boost wrote:
>> All correct.  This suggestion has been floating around since at least
>> 2010.  I think it's time to implement it.  I propose the following text
>> to be placed in the appropriate place.
>>
>> "Only those who have managed a boost review can expect their library
>> submissions to be to be reviewed."
>>
>> This clearly states the rule and allows for some exceptions.
>
> OK - I've endorsed one of Naill's ideas in the form of the above
> suggestion.
>
> a) I think it's simple to implement.
> b) if it doesn't work it's simple to retract.
> c) We've had the normal back and forth about it - with the usual number
> of tangents and side tracts and I don't see a strong argument against at
> least trying it out.
>
> So let's try this out.
>
> The only thing is I don't have any idea who has the authority to
> implement this.  The Review Wizard could just start implementing it on
> his own - though I'm not sure he'd be comfortable with that.  So I'll
> guess that its the steering committee.  I'll send them a copy.
>
> Robert Ramey
>

(without my committee hat on)

This implies that the  problem is a lack of review managers. I see my
other email wasn't replied to. Perhaps because it is easier to talk
about review managers. So let me sum up my other response to see if we
can get some discussion here:

* 7 of 22 libraries in the queue have review managers assigned.
  One-third isn't great but it isn't a disaster.
* Those 7 libraries with managers could represent back-to-back
  reviews for the next 2 - 4 months.
* Libraries with a manager and no review date often represent a
  library that isn't completely ready to go. Part of the job of the
  manager is to ensure that the library is ready. This could be an
  indicator that the system is working.
* Libraries with a manager and no review date can also mean that
  finding a date is complicated.
* (both of the above observations are from personal experience)
* Not having a review manager might be an indicator of not enough
  interest in a library. It is the job of the author to ensure there
  is enough interest by the community. Perhaps the author hasn't done
  enough promotion. Maybe more solicitation on the ML is required or
  perhaps people just don't find the solution interesting. One person
  saying, "that sounds like a neat library!" shouldn't constitute
  interest.


I don't have time right now to go back through the history of items in
the review queue to determine if interest from the community was
determined before the library was placed on the list. Just producing a
library that the author finds interesting and useful doesn't make it a
candidate for Boost.

I'd like to see a purging of the queue before we get all excited about
finding managers.

* If a library doesn't have a manager, remove it from the queue.
* Authors take the pulse of the community to determine interest.
* If there is interest, the library gets placed back in the queue
  and solicitation of a manager can begin.


Lets not try and fix non-problems. Maybe review managers are a problem
but I'm not convinced. Why am I not convinced? Because of candid
discussions with past managers who had the same feeling as me: "I'm just
not interested in any of the libraries in the queue."  You will note
that has obviously changed for me in the past few months.

michael

--
Michael Caisse
Ciere Consulting
ciere.com

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [review queue] What to do about the library review queue?

Boost - Dev mailing list
+1 to everything Micheal said.

Zach

On Thu, Mar 16, 2017 at 9:49 AM, Michael Caisse via Boost <
[hidden email]> wrote:

>
>
> On 3/15/17 13:26, Robert Ramey via Boost wrote:
> > On 3/14/17 2:53 PM, Robert Ramey via Boost wrote:
> >> All correct.  This suggestion has been floating around since at least
> >> 2010.  I think it's time to implement it.  I propose the following text
> >> to be placed in the appropriate place.
> >>
> >> "Only those who have managed a boost review can expect their library
> >> submissions to be to be reviewed."
> >>
> >> This clearly states the rule and allows for some exceptions.
> >
> > OK - I've endorsed one of Naill's ideas in the form of the above
> > suggestion.
> >
> > a) I think it's simple to implement.
> > b) if it doesn't work it's simple to retract.
> > c) We've had the normal back and forth about it - with the usual number
> > of tangents and side tracts and I don't see a strong argument against at
> > least trying it out.
> >
> > So let's try this out.
> >
> > The only thing is I don't have any idea who has the authority to
> > implement this.  The Review Wizard could just start implementing it on
> > his own - though I'm not sure he'd be comfortable with that.  So I'll
> > guess that its the steering committee.  I'll send them a copy.
> >
> > Robert Ramey
> >
>
> (without my committee hat on)
>
> This implies that the  problem is a lack of review managers. I see my
> other email wasn't replied to. Perhaps because it is easier to talk
> about review managers. So let me sum up my other response to see if we
> can get some discussion here:
>
> * 7 of 22 libraries in the queue have review managers assigned.
>   One-third isn't great but it isn't a disaster.
> * Those 7 libraries with managers could represent back-to-back
>   reviews for the next 2 - 4 months.
> * Libraries with a manager and no review date often represent a
>   library that isn't completely ready to go. Part of the job of the
>   manager is to ensure that the library is ready. This could be an
>   indicator that the system is working.
> * Libraries with a manager and no review date can also mean that
>   finding a date is complicated.
> * (both of the above observations are from personal experience)
> * Not having a review manager might be an indicator of not enough
>   interest in a library. It is the job of the author to ensure there
>   is enough interest by the community. Perhaps the author hasn't done
>   enough promotion. Maybe more solicitation on the ML is required or
>   perhaps people just don't find the solution interesting. One person
>   saying, "that sounds like a neat library!" shouldn't constitute
>   interest.
>
>
> I don't have time right now to go back through the history of items in
> the review queue to determine if interest from the community was
> determined before the library was placed on the list. Just producing a
> library that the author finds interesting and useful doesn't make it a
> candidate for Boost.
>
> I'd like to see a purging of the queue before we get all excited about
> finding managers.
>
> * If a library doesn't have a manager, remove it from the queue.
> * Authors take the pulse of the community to determine interest.
> * If there is interest, the library gets placed back in the queue
>   and solicitation of a manager can begin.
>
>
> Lets not try and fix non-problems. Maybe review managers are a problem
> but I'm not convinced. Why am I not convinced? Because of candid
> discussions with past managers who had the same feeling as me: "I'm just
> not interested in any of the libraries in the queue."  You will note
> that has obviously changed for me in the past few months.
>
> michael
>
> --
> Michael Caisse
> Ciere Consulting
> ciere.com
>
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/
> mailman/listinfo.cgi/boost
>

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [partly OT] Re: [review queue] What to do about the library review queue?

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
Niall Douglas wrote:
> On 16/03/2017 12:10, Vinnie Falco via Boost wrote:
> > On Thu, Mar 16, 2017 at 8:06 AM, Glen Fernandes via Boost
> > <[hidden email]> wrote:
> >> ...until we truly move to Github Issues
> >
> > What needs to be done in order to make this happen?
>
> A decision needs to be taken on how best to port the Trac issues into
> github.

This implies that we want to port the Trac issues into Github. This is not a
requirement. The 'organic' way to migrate to new things is just to move on.
Trac is legacy; leave it in read-only mode so that history is preserved, but
there's no need to do anything else.

Except, of course, point people to Github instead of Trac, and make sure all
libraries have Github issues enabled.

There's no need to fight the natural course of things. Github is obviously a
way better infrastructure; Github PRs once you get CI up and running is so
much superior than Trac patches that it's not even a contest. We just need
to acknowledge that on our front page.


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [partly OT] Re: [review queue] What to do about the library review queue?

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On Thu, Mar 16, 2017 at 10:43 AM, Niall Douglas via Boost
<[hidden email]> wrote:
> A decision needs to be taken on how best to port the Trac issues into
> github.

Here's an alternative, lock Trac so no new issues can be created,
inform users they should open new issues using GitHub, then fix all
the open issues remaining on Trac so there's nothing to port :)

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [partly OT] Re: [review queue] What to do about the library review queue?

Boost - Dev mailing list
> -----Original Message-----
> From: Boost [mailto:[hidden email]] On Behalf Of Vinnie Falco via Boost
> Sent: 16 March 2017 15:25
> To: [hidden email]
> Cc: Vinnie Falco
> Subject: Re: [boost] [partly OT] Re: [review queue] What to do about the library review queue?
>
> On Thu, Mar 16, 2017 at 10:43 AM, Niall Douglas via Boost
> <[hidden email]> wrote:
> > A decision needs to be taken on how best to port the Trac issues into
> > github.
>
> Here's an alternative, lock Trac so no new issues can be created,
> inform users they should open new issues using GitHub, then fix all
> the open issues remaining on Trac so there's nothing to port :)

That might be a bit nuclear - what about all the outstanding issues and discussions in the process of being fixed?

So perhaps we just need to recommend new issues be raised in GitHub, and Trac will fossilize itself.

Paul

PS How should we reference GitHub discussions in 'history'  documentation so that I (and the search engines) can  find them?  The
equivalent of, for example, https://svn.boost.org/trac/boost/ticket/12908).

---
Paul A. Bristow
Prizet Farmhouse
Kendal UK LA8 8AB
+44 (0) 1539 561830








_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [partly OT] Re: [review queue] What to do about the library review queue?

Boost - Dev mailing list
Paul A. Bristow wrote:
> > From: Boost [mailto:[hidden email]] On Behalf Of Vinnie
> > Falco via Boost
> > Here's an alternative, lock Trac so no new issues can be created, inform
> > users they should open new issues using GitHub, then fix all the open
> > issues remaining on Trac so there's nothing to port :)
>
> That might be a bit nuclear - what about all the outstanding issues and
> discussions in the process of being fixed?

Vinnie's suggestion is to disable new issue creation; outstanding issues
will remain unaffected. It was I who proposed putting it all on read-only.
:-)

> PS How should we reference GitHub discussions in 'history'  documentation
> so that I (and the search engines) can  find them?  The equivalent of, for
> example, https://svn.boost.org/trac/boost/ticket/12908).

For references, don't links to Github work fine? F.ex.
https://github.com/boostorg/build/issues/168

Not sure about search engines.


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [partly OT] Re: [review queue] What to do about the library review queue?

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 03/16/17 18:01, Peter Dimov via Boost wrote:

> Niall Douglas wrote:
>> On 16/03/2017 12:10, Vinnie Falco via Boost wrote:
>> > On Thu, Mar 16, 2017 at 8:06 AM, Glen Fernandes via Boost
>> > <[hidden email]> wrote:
>> >> ...until we truly move to Github Issues
>> >
>> > What needs to be done in order to make this happen?
>>
>> A decision needs to be taken on how best to port the Trac issues into
>> github.
>
> This implies that we want to port the Trac issues into Github. This is
> not a requirement. The 'organic' way to migrate to new things is just to
> move on. Trac is legacy; leave it in read-only mode so that history is
> preserved, but there's no need to do anything else.

If we move to GitHub issues, I would rather have all open tickets moved
from Trac there. Leaving them open in read-only Trac is not useful, and
you can't request the reporters to duplicate the tickets on GitHub.

All open tickets should preferably be in one place.


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [partly OT] Re: [review queue] What to do about the library review queue?

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
Paul A. Bristow wrote:

> ... for example, https://svn.boost.org/trac/boost/ticket/12908).

A good opportunity to use a pull request adding a (currently failing) test
instead. :-)


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [partly OT] Re: [review queue] What to do about the library review queue?

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
Andrey Semashev wrote:

> If we move to GitHub issues, I would rather have all open tickets moved
> from Trac there.

That's again a difference in philosophy; I'd rather not because if a ticket
has remained open in Trac for, say, seven years, porting it is of no use;
and if it's a fresh ticket, the proper way to deal with it is to fix and
close it, not port it.


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [partly OT] Re: [review queue] What to do about the library review queue?

Boost - Dev mailing list
On Thu, Mar 16, 2017 at 10:43 AM, Peter Dimov via Boost <
[hidden email]> wrote:

> Andrey Semashev wrote:
>
> If we move to GitHub issues, I would rather have all open tickets moved
>> from Trac there.
>>
>
> That's again a difference in philosophy; I'd rather not because if a
> ticket has remained open in Trac for, say, seven years, porting it is of no
> use; and if it's a fresh ticket, the proper way to deal with it is to fix
> and close it, not port it.
>

I believe the technical term is "clean slate". :)

Emil

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [partly OT] Re: [review queue] What to do about the library review queue?

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 03/16/17 20:43, Peter Dimov via Boost wrote:
> Andrey Semashev wrote:
>
>> If we move to GitHub issues, I would rather have all open tickets
>> moved from Trac there.
>
> That's again a difference in philosophy; I'd rather not because if a
> ticket has remained open in Trac for, say, seven years, porting it is of
> no use; and if it's a fresh ticket, the proper way to deal with it is to
> fix and close it, not port it.

Well, not all tickets can be fixed easily. And the fact that the ticket
hangs for several years doesn't mean it's not valid now.


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [partly OT] Re: [review queue] What to do about the library review queue?

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 16.03.2017 13:35, Andrey Semashev via Boost wrote:

> On 03/16/17 18:01, Peter Dimov via Boost wrote:
>> Niall Douglas wrote:
>>> On 16/03/2017 12:10, Vinnie Falco via Boost wrote:
>>> > On Thu, Mar 16, 2017 at 8:06 AM, Glen Fernandes via Boost
>>> > <[hidden email]> wrote:
>>> >> ...until we truly move to Github Issues
>>> >
>>> > What needs to be done in order to make this happen?
>>>
>>> A decision needs to be taken on how best to port the Trac issues into
>>> github.
>>
>> This implies that we want to port the Trac issues into Github. This is
>> not a requirement. The 'organic' way to migrate to new things is just to
>> move on. Trac is legacy; leave it in read-only mode so that history is
>> preserved, but there's no need to do anything else.
>
> If we move to GitHub issues, I would rather have all open tickets
> moved from Trac there. Leaving them open in read-only Trac is not
> useful, and you can't request the reporters to duplicate the tickets
> on GitHub.
>
> All open tickets should preferably be in one place.

Why not let individual project / library maintainers decide how to
implement the move (or whether they want to move to github issues at all ?)

        Stefan



>
>
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost


--

      ...ich hab' noch einen Koffer in Berlin...


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [partly OT] Re: [review queue] What to do about the library review queue?

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
Andrey Semashev wrote:

> And the fact that the ticket hangs for several years doesn't mean it's not
> valid now.

A difference in philosophy, as I said. Yes, in principle all open tickets
should be preserved for all eternity because, even though nothing was done
for seven years, after five more years someone might actually do something.
But the odds say otherwise. It's much more likely that the ticket is either
obsolete, or will never get any attention.


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [partly OT] Re: [review queue] What to do about the library review queue?

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
Hi,

On 2017-03-16 13:03, Peter Dimov via Boost wrote:
> Oswin Krause wrote:
>> Hi,
>>
>> I doubt that sarcasm will help solve the severe interoperability
>> issues between the very close boost and std versions.
>
> What severe interoperability issues?
sorry for the slightly late reply.

Interoperability issues between code that is designed using the std::
versions and code using the boost libraries. Starting with: mixing boost
and std libraries as it was intended to be.
boost::shared_ptr is an example that one can get to work [1], however it
is not straight forward(look at all the slightly wrong code out there)
and requires sacrifices in performance. Most other libraries are harder
and the situation is often even undefined. For example, I have no idea
what will happen when I use std::this_thread inside a thread started by
boost::thread. Thus it is hard for me to write code that is agnostic to
the threading library used. However, if i settle for boost::thread i
also have to use boost::chrono. I could use preprocessor macros, but if
I have to deliver a library, I have to make a hard decision.


>> I sometimes wish those libraries got never adopted for this reason.
>
> By the standard? This would surely have cured the interoperability
> issues.


[1]http://stackoverflow.com/questions/12314967/cohabitation-of-boostshared-ptr-and-stdshared-ptr

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [partly OT] Re: [review queue] What to do about the library review queue?

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
Stefan Seefeld wrote:

> Why not let individual project / library maintainers decide how to
> implement the move (or whether they want to move to github issues at all
> ?)

Trac is global, so you can't stop people from opening tickets there for just
some libraries.

(Another benefit of using Github (which some will perceive as a drawback) is
that you can't open an issue in Github without specifying the library, as
you can in Trac.)


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [partly OT] Re: [review queue] What to do about the library review queue?

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
Oswin Krause wrote:
> > What severe interoperability issues?
>
> Interoperability issues between code that is designed using the std::
> versions and code using the boost libraries. Starting with: mixing boost
> and std libraries as it was intended to be.
> boost::shared_ptr is an example that one can get to work [1],

Yes, see
http://www.boost.org/doc/libs/1_63_0/libs/smart_ptr/sp_techniques.html#another_sp

> however it is not straight forward(look at all the slightly wrong code out
> there) and requires sacrifices in performance. Most other libraries are
> harder and the situation is often even undefined. For example, I have no
> idea what will happen when I use std::this_thread inside a thread started
> by boost::thread.

This specific case should work; even though the standard doesn't say what
will happen if you use it in threads not started by std::thread, all
implementations ought to support OS threads started by pthread_create or
CreateThread as well. Doesn't matter if Boost.Thread is used.

> Thus it is hard for me to write code that is agnostic to the threading
> library used. However, if i settle for boost::thread i also have to use
> boost::chrono. I could use preprocessor macros, but if I have to deliver a
> library, I have to make a hard decision.

This is a real problem, but your desire

> I sometimes wish those libraries got never adopted for this reason.

is baffling. You do know that boost::shared_ptr predates std::shared_ptr by
many years (the page above is from 2003) and is in fact the reason there is
std::shared_ptr? That we made std::shared_ptr happen? How on Earth not
adopting it would have made things better?


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
12345678