"John Maddock" <john(a)johnmaddock.co.uk> writes:
>> Heh, not my department. I'm actually shocked that we're wedging
>> is_abstract into the release branch.
>
> Normally a really bad idea, but in this case it's straight addition: it has
> no impact on existing code, and I know that some folks who develop with the
> release versions are asking for it.
Sure, but it adds tests, which as we've seen subsequently add delays.
It's a feature addition; no two ways about it.
--
Dave Abrahams
Boost Consulting
www.boost-consulting.com
Thomas Witt <witt(a)acm.org> writes:
>> b. Use a regular rotating schedule for review managers. If you're
>> not going to be available when your time comes up, it should be
>> your responsibility to find someone to swap with.
>
> From my experience strict rotating works almost never due to time
> constraints or library topic.
Yeah, but the result is that people would know well in advance when
they're scheduled and what library they're scheduled for, and...
> I am unsure whether this is not too much pressure to put it on highly
> skilled volunteers.
... it would take the pressure off of *you* to find replacement
reviewers. But if you're willing to keep that part of the pressure,
so much the better for the rest of us.
--
Dave Abrahams
Boost Consulting
www.boost-consulting.com
Thomas Witt <witt(a)acm.org> writes:
>> I don't think automating would help here.
>> How about having the email' addresses of all the review managers on
>> the formal_review_process.html page?
>> (and update this page as review managers are added or deleted)
>
> I think having names and email adresses on the website is at least
> controversial, if only for mail address harvesters. Though it might be
> a good idea to have the author care for a manager. This could be done
> on a mailing list.
Mail addresses are easy enough to obfuscate in ways that are
transparent to humans.
--
Dave Abrahams
Boost Consulting
www.boost-consulting.com
Just for the sake of completeness, it would probably be a good idea to
note that the use of compressed_pair wouldn't be transparent on an
implementation where a class with virtual functions can be empty. Of
course, I doubt any such implementation exists, but it is possible.
--
Dave Abrahams
Boost Consulting
www.boost-consulting.com