headers
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)

Permalink | Reply |
headers
vicente.botet | 21 Nov 07:40

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

----- Original Message ----- 
From: "Stjepan Rajko" <stjepan.rajko <at> gmail.com>
To: <boost <at> lists.boost.org>; "boost users" <boost-users <at> lists.boost.org>; <boost-announce <at> lists.boost.org>
Sent: Thursday, November 20, 2008 6:25 AM
Subject: [boost] [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.  

Hi,

I expected at least a mini review after library modification. Anyway congratulations Franz for the reviev
result. 

I would like to make some suggestion to improve the review management:

* I had notice only at the end of the the review that the review tokes place on two mailing lists (devel ans
user). Maybe this is usaual on Boost reviews but I was not aware. It will be more transaparent if all the
reviews were posted to the same mailing list, maybe a specific one should be created.

* From the 5 committing reviewers making this review possible only 3 made a review and 2 of them late. I'm
wondering if this new rule must be preserved as the review can be accepted without the commiting reviewers review.

* There were some reviews that came into this list by the intermediation of the review manager with a delay
between the posting of the reviwer and forward from the RM. One negative review posted the 4th and reveived
in this list the 11th other positive posted the 2nd and received in this list 3rd. I think that the review
manager should not encourage the reviewers to send the reviews to himself. This will avoid this kind of
(Continue reading)

Permalink | Reply |
headers
Paul Baxter | 21 Nov 09:00
Favicon

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

> I would like to make some suggestion to improve the review management:

<valid points snipped>

Whilst I understand your points, unlike our day job, people do have other 
more pressing commitments and, for many, the extensive effort given to 
reviewing boost libraries is time given in an ad-hoc manner.

Whilst it is good to have the timetable and a specific method for submitting 
reviews, I don't think we need to go further and be more regimented. The 
existing flexibility is a positive part of the process, IMHO.

[ I do have problems with some libraries actually getting to the point of 
review before interest, maturity of interface or implementation are right, 
but that doesn't apply here and has been covered in previous discussions.]

I'm grateful to all who devoted time to this library and I think Stjepan was 
flexible and handled the review very well.

Paul
Permalink | Reply |
headers
Robert Jones | 21 Nov 10:06

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

On Fri, Nov 21, 2008 at 6:40 AM, vicente.botet <vicente.botet <at> wanadoo.fr> wrote:


* I had notice only at the end of the the review that the review tokes place on two mailing lists (devel ans user). Maybe this is usaual on Boost reviews but I was not aware. It will be more transaparent if all the reviews were posted to the same mailing list, maybe a specific one should be created.


A specific maillist for reviews strikes me as an excellent idea. In Joels' review
of his Phoenix 2.0 library there were some outstanding contributions from
people I don't see posting very often, but who apparently feel moved to do
important stuff like reviewing. These comments did much to give me some
historical context, and understanding of structure, alternatives and implementation
decisions. These will inevitably be lost in the general background noise of
on going developments, and it would be nice to have a clear place for these
review comments.

- Rob.
_______________________________________________
Boost-users mailing list
Boost-users <at> lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/boost-users
Permalink | Reply |
headers
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
Permalink | Reply |
headers
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
trunk boost and libs directories, and those that want to get signals2
with the trunk can do an svn switch to a version in the branch (then
they can latch on to a particular version, or the head, and they are
very conscious of the fact that they are working with a library that
might be going through frequent changes).

Sorry if I'm making too much of this, perhaps one of the moderators
can chime in and say that using the trunk is a non-issue and I'll
happily shut up :-)

Best,

Stjepan
Permalink | Reply |

Gmane