Stjepan Rajko | 20 Nov 06:22

[signals2][review] signals2 review results

** signals2 review results **

I am pleased to announce that the signals2 library by Frank Mori Hess
is accepted into boost, pending some conditions outlined below are
met.  I would like to thank the author for his work on this library,
and for his very responsive participation in the review.  I would also
like to thank Franz Alt, Jean-Cristophe Benoist, Vicente Botet, Fabio
Fracassi, Johan Råde, Ravikiran Rajagopal, Andrew Webber, and Jesse
Williamson for submitting reviews, and Terry Golubiewski, Michael
Marcin, and Hansjörg for additional comments regarding the library.

There were 5 votes cast for the acceptance of this library, and 3
against accepting the library at this time.  The reviewers that were
against immediate inclusion of signals2 suggested that the library
should be accepted when several stated problems are addressed
adequately.

Overall, the library was regarded as a much needed thread-safe
successor of Boost.Signals.  Those that have tried switching from
Boost.Signals to signals2 have found the switch rather painless (at
least in the cases that don't involve the Boost.Signals trackable
interface), and some reported using signals2 and/or its previous
versions in production code.  Some additional improvements that were
mentioned are an automatic connection management system based on
shared_ptr, and a change of namespace (which avoids problems with QT).

Additionally, many requests were made for improvements in the
documentation, as well as some improvements in thread-related testing
and some possible changes to the interface.  Frank has addressed many
of the issues in the review, and in many cases offered concrete steps
(Continue reading)

Frank Mori Hess | 21 Nov 03:01
Favicon

Re: [boost] [signals2][review] signals2 review results

On Thursday 20 November 2008 00:25, Stjepan Rajko wrote:
> I am pleased to announce that the signals2 library by Frank Mori Hess
> is accepted into boost, pending some conditions outlined below are
> met.  I would like to thank the author for his work on this library,
> and for his very responsive participation in the review.  I would also
> like to thank Franz Alt, Jean-Cristophe Benoist, Vicente Botet, Fabio
> Fracassi, Johan Råde, Ravikiran Rajagopal, Andrew Webber, and Jesse
> Williamson for submitting reviews, and Terry Golubiewski, Michael
> Marcin, and Hansjörg for additional comments regarding the library.

Thank you to Stjepan for managing the review, and to everyone who took the 
time to write reviews and provide feedback.

> As stated, the above issues should be addressed before moving the
> signals2 library to the boost trunk.  

I'll post a RFC to the boost devel/users lists once I'm done addressing the 
issues raised during the review, to give people an opportunity to provide 
more input before it goes into a release.  One minor point: my 
understanding is code in the trunk doesn't go into releases until it is 
manually copied into the release branch.  So I think the important move 
wouldn't be the one from sandbox to trunk, but copying the library into 
the release branch.

_______________________________________________
Boost-users mailing list
Boost-users <at> lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/boost-users
(Continue reading)

Stjepan Rajko | 21 Nov 05:29

Re: [boost] [signals2][review] signals2 review results

On Thu, Nov 20, 2008 at 7:01 PM, Frank Mori Hess <fmhess <at> speakeasy.net> wrote:
>
> I'll post a RFC to the boost devel/users lists once I'm done addressing the
> issues raised during the review, to give people an opportunity to provide
> more input before it goes into a release.  One minor point: my
> understanding is code in the trunk doesn't go into releases until it is
> manually copied into the release branch.  So I think the important move
> wouldn't be the one from sandbox to trunk, but copying the library into
> the release branch.
>

I was unsure on this issue myself, so I went with the more
conservative decision.  This was partly because I was mirroring
previous reviews that had similar conditions (but those were before
the current release process), and partly because every once in a while
I see a discussion on the list that tries to pin down how stable or
unstable the trunk is supposed to be, and I don't recall seeing a hard
decision on the issue.  My concern was that boost users or developers
that use the trunk would have to deal with potentially frequent
post-review changes should they choose to use signals2.

I think working in a branch (http://svn.boost.org/svn/boost/branches/)
would definitely be fine (this would be better than the sandbox
because you could integrate with the boost structure - from what I
remember branching all of boost into the sandbox is frowned upon).
Could you do that until you feel like you have a relatively stable and
reliable implementation? (depending on what changes you plan to make
to the implementation, that might not take much).

Another option might be to just create a signals2 directory in the
(Continue reading)


Gmane