[boost] [release] scope_exit, local_function, utility/identity_type, and functional/overloaded_function

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

[boost] [release] scope_exit, local_function, utility/identity_type, and functional/overloaded_function

lcaminiti
Hello release managers,

I've been working in the trunk on a few libraries which are almost ready to be released:
a) When is the release date?
b) What do I have to do to merge into release? (This will be my 1st release merge :) ).

1) ScopeExit (improved)
I'm waiting on MVSC 9 and 10 tests to cycle to make sure they all pass. Other compilers OK.

2) Utility/IdentityType (new)
Should be ready to be merged into release.

3) Functional/OverloadedFunction (new)
Should be ready to be merged into release.

4) LocalFunction (new)
I'm making final fixes for some tests on some of compilers. Hopefully, I'll be done in 2 weeks max.

For all of those, I've followed the checklist so I've run the code inspection tool, updated all docs, librariers.htm, and maintainers.txt.

Thanks a lot.
--Lorenzo
Reply | Threaded
Open this post in threaded view
|

Re: [release] scope_exit, local_function, utility/identity_type, and functional/overloaded_function

Daniel James-3
On 19 April 2012 21:08, lcaminiti <[hidden email]> wrote:
> Hello release managers,
>
> I've been working in the trunk on a few libraries which are almost ready to
> be released:

Sorry for the very slow reply.

> a) When is the release date?

Dunno.

> b) What do I have to do to merge into release? (This will be my 1st release
> merge :) ).

The best thing to do is merge the individual changesets from the root, ie.

svn merge -c'revision-number' ^/trunk

But that can be a lot of hassle. So it might be better to merge from
your libraries subdirectories. When adding a new library to release,
use 'svn cp' to copy the appropriate directories, later merges can be
done in the appropriate directories, making use of subversion's merge
tracking.

For existing libraries, there's a good chance they haven't got very
good merge history, so, errr, do whatever works?

> 1) ScopeExit (improved)
> I'm waiting on MVSC 9 and 10 tests to cycle to make sure they all pass.
> Other compilers OK.
>
> 2) Utility/IdentityType (new)
> Should be ready to be merged into release.
>
> 3) Functional/OverloadedFunction (new)
> Should be ready to be merged into release.
>
> 4) LocalFunction (new)
> I'm making final fixes for some tests on some of compilers. Hopefully, I'll
> be done in 2 weeks max.
>
> For all of those, I've followed the checklist so I've run the code
> inspection tool, updated all docs, librariers.htm, and maintainers.txt.

Looks fine, (at least it did when I looked last week). I did find the
way you force some tests to fail a bit odd, why don't you just let
them fail naturally?

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

Re: [release] scope_exit, local_function, utility/identity_type, and functional/overloaded_function

lcaminiti
Daniel James-3 wrote
> For all of those, I've followed the checklist so I've run the code
> inspection tool, updated all docs, librariers.htm, and maintainers.txt.

Looks fine, (at least it did when I looked last week). I did find the
way you force some tests to fail a bit odd, why don't you just let
them fail naturally?
Which tests?

Some ScopeExit and LocalFunction requires variadic macros and C++11 lambdas so I used Boost.Config to detect if these are not supported and fail these tests with

#error "variadic macros required"

or

#error "lambda functions required"

I find these errors more readable than the ugly ones the libraries will generate otherwise. The point is that users should not use some library features at all without variadic macros or lambda functions (so if the libraries generate nasty errors when the regression tests check these features blindly on all compilers).

Are these the tests you are referring to?

Thanks.
--Lorenzo
Reply | Threaded
Open this post in threaded view
|

Re: [release] scope_exit, local_function, utility/identity_type, and functional/overloaded_function

Eric Niebler-3
In reply to this post by Daniel James-3
On 4/30/2012 1:37 PM, Daniel James wrote:

> On 19 April 2012 21:08, lcaminiti <[hidden email]> wrote:
>> b) What do I have to do to merge into release? (This will be my 1st release
>> merge :) ).
>
> The best thing to do is merge the individual changesets from the root, ie.
>
> svn merge -c'revision-number' ^/trunk
>
> But that can be a lot of hassle. So it might be better to merge from
> your libraries subdirectories. When adding a new library to release,
> use 'svn cp' to copy the appropriate directories, later merges can be
> done in the appropriate directories, making use of subversion's merge
> tracking.

Merging from the root is Boost's recommended practice, and is not
painful at all if you're using a recent version of svn. Prefer to do it
that way.

You can merge many changesets to release at once using:

svn merge -c 1111 -c 2222 -c 3333 ^/trunk

where 1111, 2222, etc are the numbers of the changesets. (I didn't know
about the ^/trunk syntax until just now, and I've never used it, but I
will now. Thanks, Daniel.)

--
Eric Niebler
BoostPro Computing
http://www.boostpro.com

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

Re: [release] scope_exit, local_function, utility/identity_type, and functional/overloaded_function

Jeffrey Lee Hellrung, Jr.-2
On Mon, Apr 30, 2012 at 10:19 PM, Eric Niebler <[hidden email]> wrote:

> On 4/30/2012 1:37 PM, Daniel James wrote:
> > On 19 April 2012 21:08, lcaminiti <[hidden email]> wrote:
> >> b) What do I have to do to merge into release? (This will be my 1st
> release
> >> merge :) ).
> >
> > The best thing to do is merge the individual changesets from the root,
> ie.
> >
> > svn merge -c'revision-number' ^/trunk
> >
> > But that can be a lot of hassle. So it might be better to merge from
> > your libraries subdirectories. When adding a new library to release,
> > use 'svn cp' to copy the appropriate directories, later merges can be
> > done in the appropriate directories, making use of subversion's merge
> > tracking.
>
> Merging from the root is Boost's recommended practice, and is not
> painful at all if you're using a recent version of svn. Prefer to do it
> that way.
>
> You can merge many changesets to release at once using:
>
> svn merge -c 1111 -c 2222 -c 3333 ^/trunk
>
> where 1111, 2222, etc are the numbers of the changesets. (I didn't know
> about the ^/trunk syntax until just now, and I've never used it, but I
> will now. Thanks, Daniel.)


Hmmm..what you're saying *looks* to be in conflict with [1] (which,
incidently, I just modified as the TortoiseSVN instructions were outdated).
Can you (or Daniel, or anyone) clarify/comment?

Thanks!

- Jeff

[1]
https://svn.boost.org/trac/boost/wiki/ImprovingPractices#Mergingchangesfromdevelopmenttrunktoreleasebranch

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

Re: [release] scope_exit, local_function, utility/identity_type, and functional/overloaded_function

Eric Niebler-3
On 4/30/2012 10:28 PM, Jeffrey Lee Hellrung, Jr. wrote:

> On Mon, Apr 30, 2012 at 10:19 PM, Eric Niebler <[hidden email]> wrote:
>> Merging from the root is Boost's recommended practice, and is not
>> painful at all if you're using a recent version of svn. Prefer to do it
>> that way.
>>
>> You can merge many changesets to release at once using:
>>
>> svn merge -c 1111 -c 2222 -c 3333 ^/trunk
>>
>> where 1111, 2222, etc are the numbers of the changesets. (I didn't know
>> about the ^/trunk syntax until just now, and I've never used it, but I
>> will now. Thanks, Daniel.)
>
> Hmmm..what you're saying *looks* to be in conflict with [1] (which,
> incidently, I just modified as the TortoiseSVN instructions were outdated).
> Can you (or Daniel, or anyone) clarify/comment?
>
> Thanks!
>
> - Jeff
>
> [1]
> https://svn.boost.org/trac/boost/wiki/ImprovingPractices#Mergingchangesfromdevelopmenttrunktoreleasebranch

Hrm. Either best practice has changed while I was sleeping (possible),
or else whoever wrote this didn't know about Boost's merge policy. The
proscription against merging individual files and subdirectories comes
from long ago ... possibly a time when svn merge tracking was very
rudimentary. It's possible that it doesn't make a difference now. Does
anybody know?

--
Eric Niebler
BoostPro Computing
http://www.boostpro.com

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

Re: [release] scope_exit, local_function, utility/identity_type, and functional/overloaded_function

Daniel James-3
In reply to this post by lcaminiti
On 1 May 2012 01:59, lcaminiti <[hidden email]> wrote:

>
> Daniel James-3 wrote
>>
>>> For all of those, I've followed the checklist so I've run the code
>>> inspection tool, updated all docs, librariers.htm, and maintainers.txt.
>>
>> Looks fine, (at least it did when I looked last week). I did find the
>> way you force some tests to fail a bit odd, why don't you just let
>> them fail naturally?
>>
>
> Which tests?
>
> Some ScopeExit and LocalFunction requires variadic macros and C++11 lambdas
> so I used Boost.Config to detect if these are not supported and fail these
> tests with
>
> #error "variadic macros required"
>
> or
>
> #error "lambda functions required"
>
> I find these errors more readable than the ugly ones the libraries will
> generate otherwise. The point is that users should not use some library
> features at all without variadic macros or lambda functions (so if the
> libraries generate nasty errors when the regression tests check these
> features blindly on all compilers).

Sorry, that was more an aside than a big sticking point, but those
were the tests I was referring to. I'll try to explain. Although what
I actually do is suppress failures for C++11 features that aren't
available, so I'll first explain the reason I do that.

Consider a user of your library who runs the tests for every release
to check that there are no regressions. The first time they do that
they notice there are failures, check them, find they're an acceptable
failure and learn that test failures for your library are acceptable.
For the next few releases they continue to check them, but after a few
releases they will inevitably get less careful, which means that they
could easily miss an unacceptable failure. So for them the best thing
to do is to force the test to pass. They really just want a binary 'is
this okay' check to quickly and easily flag problems. Acceptable
failures defeat that purpose.

So... why not suppress these failures? A good reason might be to avoid
loosing information - the test might unexpectedly pass because the
information from the config macro is incorrect. You also don't want to
suppress a failure for a genuine problem that you are working on
fixing. Or maybe because a particular setup just isn't supported at
all, and the tests should fail.

What you're doing is using the test results as documentation. IMO test
results are not appropriate places for documentation (the tests
themselves can be useful as documentation). Ideally a user shouldn't
read test results, they just check that they passed. It's better to
list portability issues in the actual documentation.

Of course this is all my opinion, not an official policy. Basically it
boils down to the belief that a test failure should be an actual
problem. (I'll repeat for casual readers - this is about tests for
C++11 features which aren't available, not about failures due to
compiler/library bugs).

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

Re: [release] scope_exit, local_function, utility/identity_type, and functional/overloaded_function

Daniel James-3
In reply to this post by Eric Niebler-3
On 1 May 2012 07:21, Eric Niebler <[hidden email]> wrote:
> On 4/30/2012 10:28 PM, Jeffrey Lee Hellrung, Jr. wrote:
>> On Mon, Apr 30, 2012 at 10:19 PM, Eric Niebler <[hidden email]> wrote:
>>> Merging from the root is Boost's recommended practice, and is not
>>> painful at all if you're using a recent version of svn. Prefer to do it
>>> that way.

I meant it's a pain to have to keep track of exactly which changesets
you want to merge, with a better system the version control system
should keep track of that for you. But part of the reason it's a pain
is that we can't use 'svn mergeinfo' from the root to see what hasn't
been merged, which would be less of a problem if everyone did merge at
the root.

>> Hmmm..what you're saying *looks* to be in conflict with [1] (which,
>> incidently, I just modified as the TortoiseSVN instructions were outdated).
>> Can you (or Daniel, or anyone) clarify/comment?
>>
https://svn.boost.org/trac/boost/wiki/ImprovingPractices#Mergingchangesfromdevelopmenttrunktoreleasebranch
>
> Hrm. Either best practice has changed while I was sleeping (possible),
> or else whoever wrote this didn't know about Boost's merge policy.

Most of the wiki's content hasn't been discussed or reviewed in any
way. It's just someone's opinion (as are posts like this). I don't
think we have a generally accepted 'best practice' for merging.

> The
> proscription against merging individual files and subdirectories comes
> from long ago ... possibly a time when svn merge tracking was very
> rudimentary. It's possible that it doesn't make a difference now. Does
> anybody know?

It still makes a difference. Having a lot of merge metadata makes
merging slower and more complicated. It also makes mergeinfo slower
and less accurate in parent directories It would be great if we could
get subversion to tell us exactly which changesets haven't been merged
to release, but we can't because the metadata is too messy. Since it's
quite likely we'll switch from subversion in the near future, I don't
think it's worth the effort to clean it up. So my compromise is to
keep the metadata in a good condition for my individual parts of the
tree.

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

Re: [release] scope_exit, local_function, utility/identity_type, and functional/overloaded_function

lcaminiti
In reply to this post by Daniel James-3
Daniel James-3 wrote
On 1 May 2012 01:59, lcaminiti <[hidden email]> wrote:
>
> Daniel James-3 wrote
>>
>>> For all of those, I've followed the checklist so I've run the code
>>> inspection tool, updated all docs, librariers.htm, and maintainers.txt.
>>
>> Looks fine, (at least it did when I looked last week). I did find the
>> way you force some tests to fail a bit odd, why don't you just let
>> them fail naturally?
>>
>
> Which tests?
>
> Some ScopeExit and LocalFunction requires variadic macros and C++11 lambdas
> so I used Boost.Config to detect if these are not supported and fail these
> tests with
>
> #error "variadic macros required"
>
> or
>
> #error "lambda functions required"
>
> I find these errors more readable than the ugly ones the libraries will
> generate otherwise. The point is that users should not use some library
> features at all without variadic macros or lambda functions (so if the
> libraries generate nasty errors when the regression tests check these
> features blindly on all compilers).

Sorry, that was more an aside than a big sticking point, but those
were the tests I was referring to. I'll try to explain. Although what
I actually do is suppress failures for C++11 features that aren't
available, so I'll first explain the reason I do that.

Consider a user of your library who runs the tests for every release
to check that there are no regressions. The first time they do that
they notice there are failures, check them, find they're an acceptable
failure and learn that test failures for your library are acceptable.
For the next few releases they continue to check them, but after a few
releases they will inevitably get less careful, which means that they
could easily miss an unacceptable failure. So for them the best thing
to do is to force the test to pass. They really just want a binary 'is
this okay' check to quickly and easily flag problems. Acceptable
failures defeat that purpose.

So... why not suppress these failures? A good reason might be to avoid
loosing information - the test might unexpectedly pass because the
information from the config macro is incorrect. You also don't want to
suppress a failure for a genuine problem that you are working on
fixing. Or maybe because a particular setup just isn't supported at
all, and the tests should fail.

What you're doing is using the test results as documentation. IMO test
results are not appropriate places for documentation (the tests
themselves can be useful as documentation). Ideally a user shouldn't
read test results, they just check that they passed. It's better to
list portability issues in the actual documentation.

Of course this is all my opinion, not an official policy. Basically it
boils down to the belief that a test failure should be an actual
problem. (I'll repeat for casual readers - this is about tests for
C++11 features which aren't available, not about failures due to
compiler/library bugs).
The library docs say you shouldn't use the library C++11 features on non C++11 compilers. So the tests do not even try to use the library C++11 features on non C++11 compilers and they just #error. However, I went back and forth on this and at some point I had the tests always using the library and crashing on non C++11 compilers so I could really go either way...

Thanks.
--Lorenzo

Reply | Threaded
Open this post in threaded view
|

Re: [release] scope_exit, local_function, utility/identity_type, and functional/overloaded_function

Jeffrey Lee Hellrung, Jr.-2
In reply to this post by Daniel James-3
On Tue, May 1, 2012 at 1:10 AM, Daniel James <[hidden email]> wrote:

> On 1 May 2012 07:21, Eric Niebler <[hidden email]> wrote:
> > On 4/30/2012 10:28 PM, Jeffrey Lee Hellrung, Jr. wrote:
> >> On Mon, Apr 30, 2012 at 10:19 PM, Eric Niebler <[hidden email]>
> wrote:
> >>> Merging from the root is Boost's recommended practice, and is not
> >>> painful at all if you're using a recent version of svn. Prefer to do it
> >>> that way.
>
> I meant it's a pain to have to keep track of exactly which changesets
> you want to merge, with a better system the version control system
> should keep track of that for you. But part of the reason it's a pain
> is that we can't use 'svn mergeinfo' from the root to see what hasn't
> been merged, which would be less of a problem if everyone did merge at
> the root.
>
> >> Hmmm..what you're saying *looks* to be in conflict with [1] (which,
> >> incidently, I just modified as the TortoiseSVN instructions were
> outdated).
> >> Can you (or Daniel, or anyone) clarify/comment?
> >>
>
> https://svn.boost.org/trac/boost/wiki/ImprovingPractices#Mergingchangesfromdevelopmenttrunktoreleasebranch
> >
> > Hrm. Either best practice has changed while I was sleeping (possible),
> > or else whoever wrote this didn't know about Boost's merge policy.
>
> Most of the wiki's content hasn't been discussed or reviewed in any
> way. It's just someone's opinion (as are posts like this). I don't
> think we have a generally accepted 'best practice' for merging.
>
> > The
> > proscription against merging individual files and subdirectories comes
> > from long ago ... possibly a time when svn merge tracking was very
> > rudimentary. It's possible that it doesn't make a difference now. Does
> > anybody know?
>
> It still makes a difference. Having a lot of merge metadata makes
> merging slower and more complicated. It also makes mergeinfo slower
> and less accurate in parent directories It would be great if we could
> get subversion to tell us exactly which changesets haven't been merged
> to release, but we can't because the metadata is too messy. Since it's
> quite likely we'll switch from subversion in the near future, I don't
> think it's worth the effort to clean it up. So my compromise is to
> keep the metadata in a good condition for my individual parts of the
> tree.
>

Okay, I will try to merge from root in the future. It sounds like I
shouldn't bend over backwards to get it working, though (I don't know what
could go wrong...), as long as I can still merge fine at a more local level.

- Jeff

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