[release] scope_exit, local_function, utility/identity_type, and functional/overloaded_function
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 -- View this message in context: http://boost.2283326.n4.nabble.com/boost-release-scope-exit-local-function-u... Sent from the Boost - Dev mailing list archive at Nabble.com.
On 19 April 2012 21:08, lcaminiti <lorcaminiti@gmail.com> 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?
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 -- View this message in context: http://boost.2283326.n4.nabble.com/boost-release-scope-exit-local-function-u... Sent from the Boost - Dev mailing list archive at Nabble.com.
On 1 May 2012 01:59, lcaminiti <lorcaminiti@gmail.com> 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).
Daniel James-3 wrote
On 1 May 2012 01:59, lcaminiti <lorcaminiti@> 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 -- View this message in context: http://boost.2283326.n4.nabble.com/boost-release-scope-exit-local-function-u... Sent from the Boost - Dev mailing list archive at Nabble.com.
On 4/30/2012 1:37 PM, Daniel James wrote:
On 19 April 2012 21:08, lcaminiti <lorcaminiti@gmail.com> 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
On Mon, Apr 30, 2012 at 10:19 PM, Eric Niebler <eric@boostpro.com> wrote:
On 4/30/2012 1:37 PM, Daniel James wrote:
On 19 April 2012 21:08, lcaminiti <lorcaminiti@gmail.com> 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#Mergingchangesfromd...
On 4/30/2012 10:28 PM, Jeffrey Lee Hellrung, Jr. wrote:
On Mon, Apr 30, 2012 at 10:19 PM, Eric Niebler <eric@boostpro.com> 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#Mergingchangesfromd...
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
On 1 May 2012 07:21, Eric Niebler <eric@boostpro.com> wrote:
On 4/30/2012 10:28 PM, Jeffrey Lee Hellrung, Jr. wrote:
On Mon, Apr 30, 2012 at 10:19 PM, Eric Niebler <eric@boostpro.com> 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#Mergingchangesfromd...
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.
On Tue, May 1, 2012 at 1:10 AM, Daniel James <dnljms@gmail.com> wrote:
On 1 May 2012 07:21, Eric Niebler <eric@boostpro.com> wrote:
On 4/30/2012 10:28 PM, Jeffrey Lee Hellrung, Jr. wrote:
On Mon, Apr 30, 2012 at 10:19 PM, Eric Niebler <eric@boostpro.com> 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#Mergingchangesfromd...
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
participants (4)
-
Daniel James -
Eric Niebler -
Jeffrey Lee Hellrung, Jr. -
lcaminiti