[1.61] Two weeks remaining for new libraries and breaking changes
I wanted to remind that the master branch is closing for new libraries and breaking changes on Feb 24, about two weeks from now. We'll be closed for major changes on March 2. That's not a lot of time, please make sure any big work is completed. Thanks, -- Vladimir Prus http://vladimirprus.com
On 2/10/16 10:25 PM, Vladimir Prus wrote:
I wanted to remind that the master branch is closing for new libraries and breaking changes on Feb 24, about two weeks from now. We'll be closed for major changes on March 2. That's not a lot of time, please make sure any big work is completed.
Thanks,
I've been trying for weeks to get tests to pass on develop branch so I can merge them in to the master. These changes were intended for 1.60 but I wasn't able to get this done in time. So I started way early to avoid this problem for 1.61. But I'm hung up on a few issues with the build system. a) Current status is that I can pass all my tests on my local machine - Mac OSX when building static libraries. But now - due to a change from an "upgrade" to El Capitan - boost build won't build and run tests for shared libraries on this plaform. b) I've got some issues with function visibility which are visible on the test matrix. Unfortunately, I can't see the error messages because they are truncated on the on line test matrix. They are truncated due to the fact that on the compilers in question there is a long list of warnings from other libraries - like spirit. The online display of the test matrix needs to elminate the truncation of these error messages. c) stuck by the above, I cloned boost to my old XP laptop. This is and iffy operation due to some issues related to connectivity, timeouts, etc. d) I did manage to get past c). I followed the instructions "getting started" to use cygwin. I use cygwin because I prefer the unix shell and the cygwin tests are failing on the online test matrix. e) I tried to run and build library_status, etc. but found that it wasn't there. Turns out that this is in a separate repo - regression. I can't imagine with that would be the case but there it is. And it also seems that it only has a develop branch but no master branch. Again, I can't imagine why anyone would want to do this in the context of the boost library conventions. f) So I build library status from the regression - turns out that it's changed and has new documentation. This expands it's original functionality by having it call b2 as a sub process. This is so that that one doesn't have to use some sort of script to run the three programs which are used to build the local test matrix. It also means you can't run them one by one in an obvious way. g) attempting to move forward, I just invoke the command suggested by the documentation and I can't get it to work. Looks like process_jam_log suffers from some sort of similar affliction. Maybe if I spent more time fussing with it ... - but got to keep moving on. h) So I drop back and just run b2 which which fails due to some issue related to unix vs windows directory names. A little back and forth with Steven result in isolation of the problem in b2 build which he adds on his list of things to do. He suggests trying to build b2 with windows rather than cygwin gcc as as workaround. This doesn't seem to resolve the problem. So I'm stuck unless I want to dive in a lot deeper which I don't really have the time to do. This stuff should be easier - but it keeps getting harder and harder. I'm not fingering anyone specific - it's just that what seems are isolated problems associated with corner cases add up to major pain for other people trying to use software. One thing that I think would be helpful would be for the regression directory to be: a) included when one clones modularized boost b) include both develop and master branches c) have develop branch tested before being merged into the master branch. In other words, boost tools should be subjected to the same regimen that our libraries are. We should be eating our dog food. Robert Ramey
On 11/02/2016 17:49, Robert Ramey wrote:
On 2/10/16 10:25 PM, Vladimir Prus wrote:
I wanted to remind that the master branch is closing for new libraries and breaking changes on Feb 24, about two weeks from now. We'll be closed for major changes on March 2. That's not a lot of time, please make sure any big work is completed.
Thanks,
I've been trying for weeks to get tests to pass on develop branch so I can merge them in to the master. These changes were intended for 1.60 but I wasn't able to get this done in time. So I started way early to avoid this problem for 1.61. But I'm hung up on a few issues with the build system.
For msvc-14.0 only a trivial change is required: In xml_oarchive.hpp: void save_binary(const void *address, std::size_t count); should be: BOOST_ARCHIVE_DECL void save_binary(const void *address, std::size_t count); There are still 2 failures after that - test_dll_exported_test fails I *think* because you never set -DPOLYMORPHIC_BASE_EXPORT on the command line, so nothing is actually exported, and test_iterators fails with an assertion which I haven't looked into. HTH, John.
AMDG On 02/11/2016 10:49 AM, Robert Ramey wrote:
h) So I drop back and just run b2 which which fails due to some issue related to unix vs windows directory names. A little back and forth with Steven result in isolation of the problem in b2 build which he adds on his list of things to do. He suggests trying to build b2 with windows rather than cygwin gcc as as workaround. This doesn't seem to resolve the problem.
That's odd. Since I can't reproduce the problem, I had assumed that it was dependent on cygwin. In Christ, Steven Watanabe
On 2/11/16 11:11 AM, Steven Watanabe wrote:
AMDG
On 02/11/2016 10:49 AM, Robert Ramey wrote:
h) So I drop back and just run b2 which which fails due to some issue related to unix vs windows directory names. A little back and forth with Steven result in isolation of the problem in b2 build which he adds on his list of things to do. He suggests trying to build b2 with windows rather than cygwin gcc as as workaround. This doesn't seem to resolve the problem.
That's odd. Since I can't reproduce the problem, I had assumed that it was dependent on cygwin.
I think your assumption is correct. Why rebuilding with booststrap.bat doesn't address the problem is likely unrelated and very well possible my fault in some way. When I start to experiment, sometimes I lose track of the changes I've made and confuse the issue. Sorry about that.
In Christ, Steven Watanabe
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Hi Robert, On 11-Feb-16 8:49 PM, Robert Ramey wrote:
On 2/10/16 10:25 PM, Vladimir Prus wrote:
I wanted to remind that the master branch is closing for new libraries and breaking changes on Feb 24, about two weeks from now. We'll be closed for major changes on March 2. That's not a lot of time, please make sure any big work is completed.
Thanks,
I've been trying for weeks to get tests to pass on develop branch so I can merge them in to the master. These changes were intended for 1.60 but I wasn't able to get this done in time. So I started way early to avoid this problem for 1.61. But I'm hung up on a few issues with the build system.
a) Current status is that I can pass all my tests on my local machine - Mac OSX when building static libraries. But now - due to a change from an "upgrade" to El Capitan - boost build won't build and run tests for shared libraries on this plaform.
It's certainly unfortunate that Apple chose to break some many things in El Capitan, and it's alarming that you're the first to notice the issue as it related to Boost testing. Anyway, we discussed some options on Boost.Build list, and hopefully we'll have them implemented in time for 1.61. -- Vladimir Prus http://vladimirprus.com
On 2/14/16 11:58 PM, Vladimir Prus wrote:
a) Current status is that I can pass all my tests on my local machine - Mac OSX when building static libraries. But now - due to a change from an "upgrade" to El Capitan - boost build won't build and run tests for shared libraries on this plaform.
It's certainly unfortunate that Apple chose to break some many things in El Capitan,
Of course I would like to see this fixed - but truth is I don't think it's holding me up all that much. My normal mode is to test with static libraries and then check in to the develop branch and watch the test matrix. These days it never happens that it passes on the static library test but fails on the shared library tests. So as I said it's not holding me up that much. It is of value to run in all 4 combinations of static/shared debug/release because some combinations eliminated code which is not explicitly called - so called dead code. But the serialization library can require code which is not explicitly referred to by name - code which "looks like" dead code. So one has to take special precautions to make sure that code doesn't get eliminated. The good news is that once one has done this, it seems the problem is eliminated once and for all - at least for the last 10 years.
and it's alarming that you're the first to notice the issue as it related to Boost testing.
Well, El Capitan has been out only a short time - and I'm sure a lot of people have not upgraded so I wouldn't get alarmed. Anyway, we
discussed some options on Boost.Build list, and hopefully we'll have them implemented in time for 1.61.
To me, more urgent is the problem associated with b2 on cygwin. I've noted on this list. Basically if one builds b2 using the bootstrap.sh under cygwin it seems that it get's the / and \ mixed up in the pathnames. And this prevents b2 from working correctly. I wouldn't be surprised if this isn't also a problem with mingw on windows as well. I'm guessing this probably an easy fix for you. I also mentioned that the "regression" tools aren't tested in accordance with Boost customs. I think you (or whoever) should consider this. These tools only are on the develop but not the master branch - and as far as I know - aren't subjected to regular boost testing. I know it seems like a pain to setup - but once it's been done you get a lot of testing without having to spend any time on it. Robert Ramey
AMDG On 02/15/2016 09:19 AM, Robert Ramey wrote:
To me, more urgent is the problem associated with b2 on cygwin. I've noted on this list. Basically if one builds b2 using the bootstrap.sh under cygwin it seems that it get's the / and \ mixed up in the pathnames. And this prevents b2 from working correctly. I wouldn't be surprised if this isn't also a problem with mingw on windows as well. I'm guessing this probably an easy fix for you.
Did my patch not work? In Christ, Steven Watanabe
On 2/15/16 8:37 AM, Steven Watanabe wrote:
AMDG
On 02/15/2016 09:19 AM, Robert Ramey wrote:
To me, more urgent is the problem associated with b2 on cygwin. I've noted on this list. Basically if one builds b2 using the bootstrap.sh under cygwin it seems that it get's the / and \ mixed up in the pathnames. And this prevents b2 from working correctly. I wouldn't be surprised if this isn't also a problem with mingw on windows as well. I'm guessing this probably an easy fix for you.
Did my patch not work?
Honestly, I haven't had time to get back to this yet. Robert Ramey
In Christ, Steven Watanabe
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On 15-Feb-16 8:16 PM, Robert Ramey wrote:
On 2/15/16 8:37 AM, Steven Watanabe wrote:
AMDG
On 02/15/2016 09:19 AM, Robert Ramey wrote:
To me, more urgent is the problem associated with b2 on cygwin. I've noted on this list. Basically if one builds b2 using the bootstrap.sh under cygwin it seems that it get's the / and \ mixed up in the pathnames. And this prevents b2 from working correctly. I wouldn't be surprised if this isn't also a problem with mingw on windows as well. I'm guessing this probably an easy fix for you.
Did my patch not work?
Honestly, I haven't had time to get back to this yet.
So, the summary of this thread is that the ball is in your court? - Volodya -- Vladimir Prus http://vladimirprus.com
On 2/15/16 10:27 PM, Vladimir Prus wrote:
On 15-Feb-16 8:16 PM, Robert Ramey wrote:
On 2/15/16 8:37 AM, Steven Watanabe wrote:
AMDG
On 02/15/2016 09:19 AM, Robert Ramey wrote:
To me, more urgent is the problem associated with b2 on cygwin. I've noted on this list. Basically if one builds b2 using the bootstrap.sh under cygwin it seems that it get's the / and \ mixed up in the pathnames. And this prevents b2 from working correctly. I wouldn't be surprised if this isn't also a problem with mingw on windows as well. I'm guessing this probably an easy fix for you.
Did my patch not work?
Honestly, I haven't had time to get back to this yet.
So, the summary of this thread is that the ball is in your court?
I have made a personal commitment to maintaining the boost serialization library. So the "ball is ALWAYS in my court". In order to fulfill this commitment, I depend on a number of resources: a) my personal time b) my own computer hardware c) other boost libraries - the library depends upon other boost components such as boost spirit d) boost build - b2 etc. e) boost regression testing setup up What do I do when one of the above resources fails to work as advertised? This is the question I face. In many cases, personal time, hardware, etc. I try to make adjustments. Sometimes this means delay in response time, etc. Sometimes this means me taking on things that are incidental to the library maintenance such as testing a fix in some other component, etc. So, the ball is in my court, but that doesn't mean it's not in other courts too! I believe that some small and easy changes would make development of easier for every one: a) the regression system should implement the develop/master branch system which boost libraries do. This would permit any changes to the regression code and/or anything it depends upon to be tested separately before being unleashed on unsuspecting library developers. b) the testing/build components should be tested the same way that boost libraries are tested. Were this being done, any anomalies on b2 or other components would be detected the moment they occurred so that library developers wouldn't have to spend (a lot) if time tracking them down. c) the regression system should be a boost submodule so it gets distributed along whenever one clones the main project. This would be useful to those who want to understand what's going on and make available the components of the regression system to others which might find them useful. The current system has them in a separate repo which doesn't have a master branch. I found this to be rather confusing while spending time spelunking into things that are really outside of my responsibility and expertise. d) The regression test matrix is generated by testing the develop branch of each library against the develop branch of other libraries. Currently, the boost library fails to build with the spirit library on the develop branch. So all the serialization library tests fail on the test matrix. I presume that all other tests of libraries on the develop branch which depend upon the serialization library fail because the serialization library won't build on that branch. As boost get's bigger, this problem get's worse. How can this be acceptable? I do appreciate all the suggestions I receive to work around specific problems. But it would save a huge amount of time if the above changes were made so these problems wouldn't come up in the first place. Suggestions a), b) and c) would be easy to implement. d) is somewhat more challenging - but well worth it. Robert Ramey
On Tue, Feb 16, 2016 at 10:34 AM, Robert Ramey <ramey@rrsd.com> wrote:
On 2/15/16 10:27 PM, Vladimir Prus wrote:
On 15-Feb-16 8:16 PM, Robert Ramey wrote:
On 2/15/16 8:37 AM, Steven Watanabe wrote:
AMDG
On 02/15/2016 09:19 AM, Robert Ramey wrote:
To me, more urgent is the problem associated with b2 on cygwin. I've noted on this list. Basically if one builds b2 using the bootstrap.sh under cygwin it seems that it get's the / and \ mixed up in the pathnames. And this prevents b2 from working correctly. I wouldn't be surprised if this isn't also a problem with mingw on windows as well. I'm guessing this probably an easy fix for you.
Did my patch not work?
Honestly, I haven't had time to get back to this yet.
So, the summary of this thread is that the ball is in your court?
I have made a personal commitment to maintaining the boost serialization library. So the "ball is ALWAYS in my court".
In order to fulfill this commitment, I depend on a number of resources:
a) my personal time b) my own computer hardware c) other boost libraries - the library depends upon other boost components such as boost spirit d) boost build - b2 etc. e) boost regression testing setup up
The same applies to all of us. (A) What do I do when one of the above resources fails to work as advertised?
This is the question I face. In many cases, personal time, hardware, etc. I try to make adjustments. Sometimes this means delay in response time, etc. Sometimes this means me taking on things that are incidental to the library maintenance such as testing a fix in some other component, etc.
The same applies to all of us. (B) So, the ball is in my court, but that doesn't mean it's not in other courts
too!
I believe that some small and easy changes would make development of easier for every one:
a) the regression system should implement the develop/master branch system which boost libraries do. This would permit any changes to the regression code and/or anything it depends upon to be tested separately before being unleashed on unsuspecting library developers.
1. Has there been an instance where the regression system changes failed in the current single branch? 2. Where would we get the resources to test with more than one branch of the regression system? (C) b) the testing/build components should be tested the same way that boost
libraries are tested. Were this being done, any anomalies on b2 or other components would be detected the moment they occurred so that library developers wouldn't have to spend (a lot) if time tracking them down.
They are currently tested more than most libraries: https://travis-ci.org/boostorg/build/builds/108576884 https://travis-ci.org/boostorg/build/builds/85795874 https://travis-ci.org/boostorg/boost/builds/109532213 https://travis-ci.org/boostorg/boost/builds/109546290 http://www.boost.org/development/tests/master/developer/build.html http://www.boost.org/development/tests/master/developer/build.html Is there more testing that should be done?
c) the regression system should be a boost submodule so it gets distributed along whenever one clones the main project. This would be useful to those who want to understand what's going on and make available the components of the regression system to others which might find them useful. The current system has them in a separate repo which doesn't have a master branch. I found this to be rather confusing while spending time spelunking into things that are really outside of my responsibility and expertise.
First see (C). Second.. 1. Making it a submodule (as it used to be), adds perceived requirements on it that I don't want to keep (as it adds to the time I need to spend in dealing with it). 2. It's only slight convenience for a small percentage of Boost developers for some small percentage of time. 3. It adds unneeded clutter to the Boost releases as it would get included in what end users get. d) The regression test matrix is generated by testing the develop branch of
each library against the develop branch of other libraries. Currently, the boost library fails to build with the spirit library on the develop branch.
Did I miss someone mention this on the dev list with a [spirit] tag?
So all the serialization library tests fail on the test matrix. I presume that all other tests of libraries on the develop branch which depend upon the serialization library fail because the serialization library won't build on that branch. As boost get's bigger, this problem get's worse. How can this be acceptable?
It's not acceptable. But given that (A) and (B) also apply to the Spirit maintainers it's hard to avoid :-( I do appreciate all the suggestions I receive to work around specific
problems. But it would save a huge amount of time if the above changes were made so these problems wouldn't come up in the first place. Suggestions a), b) and c) would be easy to implement. d) is somewhat more challenging - but well worth it.
I don't see a suggestion in (d). -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail
On 2/16/16 9:17 AM, Rene Rivera wrote:
I believe that some small and easy changes would make development of easier for every one:
a) the regression system should implement the develop/master branch system which boost libraries do. This would permit any changes to the regression code and/or anything it depends upon to be tested separately before being unleashed on unsuspecting library developers.
1. Has there been an instance where the regression system changes failed in the current single branch?
Hmmm - isn't that how we got to this thread? I cloned modular boost to my xp machine where I have cygwin installed. I invoked booststrap.sh from the cygwin shell and it builds b2 executable and maybe some other stuff. When I try to invoke b2 to run local tests on the library it doesn't work. I think stephen points to a change to b2 source - but maybe it's some jam file. My point is that something has been released that doesn't work as one would expect. For boost libraries we have a mechanism to detect and diminish the incidence of this problem - the distinction between the master and develop branch. A problem of this type should be detectable before library developers start using the code.
2. Where would we get the resources to test with more than one branch of the regression system?
the same place we get the resources to build the current test matrices. tools should be tested/deployed with the same system used to test and deploy libraries. There should not be separate system. If there is some reason that this is not easy to do, then it's time to take a step back and consider why that might be.
(C)
b) the testing/build components should be tested the same way that boost
libraries are tested. Were this being done, any anomalies on b2 or other components would be detected the moment they occurred so that library developers wouldn't have to spend (a lot) if time tracking them down.
They are currently tested more than most libraries:
https://travis-ci.org/boostorg/build/builds/108576884 https://travis-ci.org/boostorg/build/builds/85795874 https://travis-ci.org/boostorg/boost/builds/109532213 https://travis-ci.org/boostorg/boost/builds/109546290 http://www.boost.org/development/tests/master/developer/build.html http://www.boost.org/development/tests/master/developer/build.html
Is there more testing that should be done?
I confess that I've never seen this before. I don't see a way to discover this through www.boost.org. Now that you've pointed it out to me I'm failures of the mingw platorms. These might be similar to cygwin which isn't tested. http://www.boost.org/development/tests/master/developer/output/igaztanaga-gc... The reference to travis intrigues me for a number of reasons and for the first time ever investigated what travis is and how it works. It's unclear to me what this would entail to use and why it might be helpful. Doesn't seem that it tests mingw or cygwin either though.
c) the regression system should be a boost submodule so it gets distributed along whenever one clones the main project. This would be useful to those who want to understand what's going on and make available the components of the regression system to others which might find them useful. The current system has them in a separate repo which doesn't have a master branch. I found this to be rather confusing while spending time spelunking into things that are really outside of my responsibility and expertise.
First see (C). Second..
1. Making it a submodule (as it used to be), adds perceived requirements on it that I don't want to keep (as it adds to the time I need to spend in dealing with it). 2. It's only slight convenience for a small percentage of Boost developers for some small percentage of time.
for me it's not a small percentage.
3. It adds unneeded clutter to the Boost releases as it would get included in what end users get.
d) The regression test matrix is generated by testing the develop branch of
each library against the develop branch of other libraries. Currently, the boost library fails to build with the spirit library on the develop branch.
Did I miss someone mention this on the dev list with a [spirit] tag?
LOL - I only discovered it in the last day or so. Things like this happen on a regular basis. When it looks like it's a problem, I check the offending library and verify that there is a problem on tests of that library. The I usually give it a couple of days because I assume the developer looks on the test matrix after he check something in. If it persists then I complain. I try to avoid inadvertently transforming boost lists into the Robert Ramey rant list.
So all the serialization library tests fail on the test matrix. I presume that all other tests of libraries on the develop branch which depend upon the serialization library fail because the serialization library won't build on that branch. As boost get's bigger, this problem get's worse. How can this be acceptable?
It's not acceptable. But given that (A) and (B) also apply to the Spirit maintainers it's hard to avoid :-(
I do appreciate all the suggestions I receive to work around specific
problems. But it would save a huge amount of time if the above changes were made so these problems wouldn't come up in the first place. Suggestions a), b) and c) would be easy to implement. d) is somewhat more challenging - but well worth it.
I don't see a suggestion in (d).
Sorry, the suggestion is that on the develop test matrix, each library be tested on the develop branch against the other libraries on the master branch. This would permit a developer to make an innocent mistake without bringing down the whole system. Robert Ramey
AMDG On 02/16/2016 11:44 AM, Robert Ramey wrote:
Hmmm - isn't that how we got to this thread? I cloned modular boost to my xp machine where I have cygwin installed. I invoked booststrap.sh from the cygwin shell and it builds b2 executable and maybe some other stuff. When I try to invoke b2 to run local tests on the library it doesn't work. I think stephen points to a change to b2 source - but maybe it's some jam file. My point is that something has been released that doesn't work as one would expect. For boost libraries we have a mechanism to detect and diminish the incidence of this problem - the distinction between the master and develop branch. A problem of this type should be detectable before library developers start using the code.
This problem slipped through because no one is testing this configuration. In Christ, Steven Watanabe
On 2/16/2016 1:44 PM, Robert Ramey wrote:
On 2/16/16 9:17 AM, Rene Rivera wrote:
I believe that some small and easy changes would make development of easier for every one:
a) the regression system should implement the develop/master branch system which boost libraries do. This would permit any changes to the regression code and/or anything it depends upon to be tested separately before being unleashed on unsuspecting library developers.
1. Has there been an instance where the regression system changes failed in the current single branch?
Hmmm - isn't that how we got to this thread? I cloned modular boost to my xp machine where I have cygwin installed. I invoked booststrap.sh from the cygwin shell and it builds b2 executable and maybe some other stuff. When I try to invoke b2 to run local tests on the library it doesn't work. I think stephen points to a change to b2 source - but maybe it's some jam file. My point is that something has been released that doesn't work as one would expect. For boost libraries we have a mechanism to detect and diminish the incidence of this problem - the distinction between the master and develop branch. A problem of this type should be detectable before library developers start using the code.
2. Where would we get the resources to test with more than one branch of the regression system?
the same place we get the resources to build the current test matrices. tools should be tested/deployed with the same system used to test and deploy libraries. There should not be separate system. If there is some reason that this is not easy to do, then it's time to take a step back and consider why that might be.
(C)
b) the testing/build components should be tested the same way that boost
libraries are tested. Were this being done, any anomalies on b2 or other components would be detected the moment they occurred so that library developers wouldn't have to spend (a lot) if time tracking them down.
They are currently tested more than most libraries:
https://travis-ci.org/boostorg/build/builds/108576884 https://travis-ci.org/boostorg/build/builds/85795874 https://travis-ci.org/boostorg/boost/builds/109532213 https://travis-ci.org/boostorg/boost/builds/109546290 http://www.boost.org/development/tests/master/developer/build.html http://www.boost.org/development/tests/master/developer/build.html
Is there more testing that should be done?
I confess that I've never seen this before. I don't see a way to discover this through www.boost.org.
Now that you've pointed it out to me I'm failures of the mingw platorms. These might be similar to cygwin which isn't tested.
http://www.boost.org/development/tests/master/developer/output/igaztanaga-gc...
The reference to travis intrigues me for a number of reasons and for the first time ever investigated what travis is and how it works. It's unclear to me what this would entail to use and why it might be helpful. Doesn't seem that it tests mingw or cygwin either though.
c) the regression system should be a boost submodule so it gets distributed along whenever one clones the main project. This would be useful to those who want to understand what's going on and make available the components of the regression system to others which might find them useful. The current system has them in a separate repo which doesn't have a master branch. I found this to be rather confusing while spending time spelunking into things that are really outside of my responsibility and expertise.
First see (C). Second..
1. Making it a submodule (as it used to be), adds perceived requirements on it that I don't want to keep (as it adds to the time I need to spend in dealing with it). 2. It's only slight convenience for a small percentage of Boost developers for some small percentage of time.
for me it's not a small percentage.
3. It adds unneeded clutter to the Boost releases as it would get included in what end users get.
d) The regression test matrix is generated by testing the develop branch of
each library against the develop branch of other libraries. Currently, the boost library fails to build with the spirit library on the develop branch.
Did I miss someone mention this on the dev list with a [spirit] tag?
LOL - I only discovered it in the last day or so. Things like this happen on a regular basis. When it looks like it's a problem, I check the offending library and verify that there is a problem on tests of that library. The I usually give it a couple of days because I assume the developer looks on the test matrix after he check something in. If it persists then I complain. I try to avoid inadvertently transforming boost lists into the Robert Ramey rant list.
So all the serialization library tests fail on the test matrix. I presume that all other tests of libraries on the develop branch which depend upon the serialization library fail because the serialization library won't build on that branch. As boost get's bigger, this problem get's worse. How can this be acceptable?
It's not acceptable. But given that (A) and (B) also apply to the Spirit maintainers it's hard to avoid :-(
I do appreciate all the suggestions I receive to work around specific
problems. But it would save a huge amount of time if the above changes were made so these problems wouldn't come up in the first place. Suggestions a), b) and c) would be easy to implement. d) is somewhat more challenging - but well worth it.
I don't see a suggestion in (d).
Sorry, the suggestion is that on the develop test matrix, each library be tested on the develop branch against the other libraries on the master branch. This would permit a developer to make an innocent mistake without bringing down the whole system.
This creates a problem when code in one library in the 'develop' branch depends on code in another library in the 'develop' branch. I think this situation is far more likely than code in one library in the 'develop' branch having to wait until code in another library it may depend on is promoted to the 'master' branch of that library. Therefore while I understand the greater stability of testing the 'develop' branch of a library against the 'master' branch of all other libraries I am opposed to this sort of testing as a practical regression testing solution. Ideally we should have a testing system where one could specify for any given library its library dependencies, and one could also specify which branch of each library dependency we want to test against. But we are a long way from such a system at present.
AMDG On 02/16/2016 12:08 PM, Edward Diener wrote:
On 2/16/2016 1:44 PM, Robert Ramey wrote:
Sorry, the suggestion is that on the develop test matrix, each library be tested on the develop branch against the other libraries on the master branch. This would permit a developer to make an innocent mistake without bringing down the whole system.
This creates a problem when code in one library in the 'develop' branch depends on code in another library in the 'develop' branch. I think this situation is far more likely than code in one library in the 'develop' branch having to wait until code in another library it may depend on is promoted to the 'master' branch of that library. Therefore while I understand the greater stability of testing the 'develop' branch of a library against the 'master' branch of all other libraries I am opposed to this sort of testing as a practical regression testing solution.
Case in point: https://github.com/boostorg/iostreams/pull/23 https://github.com/boostorg/build/pull/112
Ideally we should have a testing system where one could specify for any given library its library dependencies, and one could also specify which branch of each library dependency we want to test against. But we are a long way from such a system at present.
Even if it were possible, I can almost guarantee that it wouldn't be kept up-to-date. In Christ, Steven Watanabe
On 2/16/16 11:08 AM, Edward Diener wrote:
Sorry, the suggestion is that on the develop test matrix, each library be tested on the develop branch against the other libraries on the master branch. This would permit a developer to make an innocent mistake without bringing down the whole system.
This creates a problem when code in one library in the 'develop' branch depends on code in another library in the 'develop' branch.
I think this is an exceedingly rare occurrence and I doubt that it ever happens. If I'm working on library A and it depends on library B, I'm looking at library B's documented API. This is on the master branch. I can't know what the developer API is thinking. Unless I'm in some sort of intimate contact with him, I can't know what features he's including that I need to use right now.
I think this situation is far more likely than code in one library in the 'develop' branch having to wait until code in another library it may depend on is promoted to the 'master' branch of that library.
I disagree. see above. This situation occurs on a regular basis. It's the situation right now as I write this. Date/Time library uses the serialization library which uses spirit/classic which now has a bug so it's holding up testing on serialization, date-time and any others which include serialization support.
Therefore while I understand the greater stability of testing the 'develop' branch of a library against the 'master' branch of all other libraries I am opposed to this sort of testing as a practical regression testing solution.
noted:
Ideally we should have a testing system where one could specify for any given library its library dependencies, and one could also specify which branch of each library dependency we want to test against. But we are a long way from such a system at present.
I don't think that this would be worth the effort required. Robert Ramey
On 2016-02-16 22:45, Robert Ramey wrote:
On 2/16/16 11:08 AM, Edward Diener wrote:
Sorry, the suggestion is that on the develop test matrix, each library be tested on the develop branch against the other libraries on the master branch. This would permit a developer to make an innocent mistake without bringing down the whole system.
This creates a problem when code in one library in the 'develop' branch depends on code in another library in the 'develop' branch.
I think this is an exceedingly rare occurrence and I doubt that it ever happens.
Just recently I've had another case of synchronized update of multiple repositories on develop. https://github.com/boostorg/winapi/pull/20 https://github.com/boostorg/dll/pull/7 https://github.com/boostorg/dll/pull/8 Such situations appear more often than you think. In general, I want my develop code to be tested against develop of other libraries to be able to detect failures before they get released. I wouldn't mind to have _additional_ testing against master of all other libraries.
On 2/16/16 11:30 PM, Andrey Semashev wrote:
On 2016-02-16 22:45, Robert Ramey wrote:
On 2/16/16 11:08 AM, Edward Diener wrote:
Sorry, the suggestion is that on the develop test matrix, each library be tested on the develop branch against the other libraries on the master branch. This would permit a developer to make an innocent mistake without bringing down the whole system.
This creates a problem when code in one library in the 'develop' branch depends on code in another library in the 'develop' branch.
I think this is an exceedingly rare occurrence and I doubt that it ever happens.
Just recently I've had another case of synchronized update of multiple repositories on develop.
https://github.com/boostorg/winapi/pull/20 https://github.com/boostorg/dll/pull/7 https://github.com/boostorg/dll/pull/8
Such situations appear more often than you think.
another case? Looking at this particular case I think "exceedingly rare" is still an accurate characterization.
In general, I want my develop code to be tested against develop of other libraries to be able to detect failures before they get released.
When something in your library fails, how do you know whether it's in your library or some other library you depend upon? It can take a huge amount of time to find an error in another library.
I wouldn't mind to have _additional_ testing against master of all other libraries.
This is currently easy to do on your own system. Just leave the modular boost superproject on it's master branch, checkout your particular library and switch it to the develop branch. Now when you run your tests locally, you'll be running against the (almost) known good master. So you can be (almost) certain that any problem is in your own code. In fact, I'm guessing that a lot of people are actually doing this right now without realizing it. The problem comes when they check in the develop branch and all of a sudden they're working with other peoples (possibly buggy) develop branch and things go haywire. Think of testing as a scientific experiment to prove/disprove that your latest changes are correct/incorrect. The experiment can vary only one variable at a time (your code). If you hold the other variables (other's libraries) constant , then your experimental results are very hard to interpret. This is bad enough. What's worse is that if I check an code containing an error into the develop branch, I generate a bunch of failures for other library authors. It makes me reluctant to add/change features. Robert Ramey
On 2016-02-17 11:25, Robert Ramey wrote:
On 2/16/16 11:30 PM, Andrey Semashev wrote:
In general, I want my develop code to be tested against develop of other libraries to be able to detect failures before they get released.
When something in your library fails, how do you know whether it's in your library or some other library you depend upon?
I look into the problem, provided I have time.
It can take a huge amount of time to find an error in another library.
Most of the time I can pinpoint the source of the problem fairly quickly (a few minutes of inspecting the error message and the source code is usually enough). That's not always the case, I'll give you that. But on the flip side errors get detected quickier, and I'm also often able to prepare a PR to fix the problem, so often the fix is also applied quickier.
I wouldn't mind to have _additional_ testing against master of all other libraries.
This is currently easy to do on your own system.
I know. I just don't bother doing that because that's inconvenient for my workflow.
AMDG On 02/17/2016 01:25 AM, Robert Ramey wrote:
On 2/16/16 11:30 PM, Andrey Semashev wrote:
Just recently I've had another case of synchronized update of multiple repositories on develop.
https://github.com/boostorg/winapi/pull/20 https://github.com/boostorg/dll/pull/7 https://github.com/boostorg/dll/pull/8
Such situations appear more often than you think.
another case? Looking at this particular case I think "exceedingly rare" is still an accurate characterization.
With the example I posted, that makes two of your "exceedingly rare" cases in the last week. In Christ, Steven Watanabe
On Wed, Feb 17, 2016 at 9:10 AM, Steven Watanabe <watanabesj@gmail.com> wrote:
AMDG
On 02/17/2016 01:25 AM, Robert Ramey wrote:
On 2/16/16 11:30 PM, Andrey Semashev wrote:
Just recently I've had another case of synchronized update of multiple repositories on develop.
https://github.com/boostorg/winapi/pull/20 https://github.com/boostorg/dll/pull/7 https://github.com/boostorg/dll/pull/8
Such situations appear more often than you think.
another case? Looking at this particular case I think "exceedingly rare" is still an accurate characterization.
With the example I posted, that makes two of your "exceedingly rare" cases in the last week.
I also have another case that "came up" December/January involving close to a dozen libraries. But I created all the changes, and it was build system related (i.e. changing build files). It hasn't made it to master yet. And I need to push it to master all "at once" (not looking forward to that). -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail
On 2/17/16 7:15 AM, Rene Rivera wrote:
On Wed, Feb 17, 2016 at 9:10 AM, Steven Watanabe <watanabesj@gmail.com> wrote:
AMDG
On 02/17/2016 01:25 AM, Robert Ramey wrote:
On 2/16/16 11:30 PM, Andrey Semashev wrote:
Just recently I've had another case of synchronized update of multiple repositories on develop.
https://github.com/boostorg/winapi/pull/20 https://github.com/boostorg/dll/pull/7 https://github.com/boostorg/dll/pull/8
Such situations appear more often than you think.
another case? Looking at this particular case I think "exceedingly rare" is still an accurate characterization.
With the example I posted, that makes two of your "exceedingly rare" cases in the last week.
I also have another case that "came up" December/January involving close to a dozen libraries. But I created all the changes, and it was build system related (i.e. changing build files). It hasn't made it to master yet. And I need to push it to master all "at once" (not looking forward to that).
right. And if you were doing it my way (assuming you aren't inadvertently doing this way already), you'd have much less anxiety about this. Robert Ramey
On Wed, Feb 17, 2016 at 10:51 AM, Robert Ramey <ramey@rrsd.com> wrote:
On 2/17/16 7:15 AM, Rene Rivera wrote:
On Wed, Feb 17, 2016 at 9:10 AM, Steven Watanabe <watanabesj@gmail.com> wrote:
AMDG
On 02/17/2016 01:25 AM, Robert Ramey wrote:
On 2/16/16 11:30 PM, Andrey Semashev wrote:
Just recently I've had another case of synchronized update of multiple repositories on develop.
https://github.com/boostorg/winapi/pull/20 https://github.com/boostorg/dll/pull/7 https://github.com/boostorg/dll/pull/8
Such situations appear more often than you think.
another case? Looking at this particular case I think "exceedingly rare" is still an accurate characterization.
With the example I posted, that makes two of your "exceedingly rare" cases in the last week.
I also have another case that "came up" December/January involving close to a dozen libraries. But I created all the changes, and it was build system related (i.e. changing build files). It hasn't made it to master yet. And I need to push it to master all "at once" (not looking forward to that).
right. And if you were doing it my way (assuming you aren't inadvertently doing this way already), you'd have much less anxiety about this.
Note.. I'm in favor of your idea of develop-against-master testing. But I'm now thinking it's best to make it an option for each library as to what mode they should be tested in. Of course I think the ideal would be to test both ways.. But we don't have the testing capacity to do that at this time. -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail
On 2/17/16 7:10 AM, Steven Watanabe wrote:
AMDG
On 02/17/2016 01:25 AM, Robert Ramey wrote:
On 2/16/16 11:30 PM, Andrey Semashev wrote:
Just recently I've had another case of synchronized update of multiple repositories on develop.
https://github.com/boostorg/winapi/pull/20 https://github.com/boostorg/dll/pull/7 https://github.com/boostorg/dll/pull/8
Such situations appear more often than you think.
another case? Looking at this particular case I think "exceedingly rare" is still an accurate characterization.
With the example I posted, that makes two of your "exceedingly rare" cases in the last week.
All these cases relate to two coupled libraries. Regardless of questions about the wisdom and/or avoidability of such coupling, these examples aren't counter examples to my main point. In these examples, the correct action would be to checkout both coupled libraries, switch both to develop branch and update and run tests on those two (or three...) while leaving the other 125 libraries in master. Of course in this case they have to pushed and merged as a pair - because they're coupled. But it doesn't argue against my suggestion.
In Christ, Steven Watanabe
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Robert Ramey wrote:
All these cases relate to two coupled libraries.
If by "coupled" you mean interdependent, that is, library X depends on Y and Y depends on X, then no. The typical case is this: - your library X uses Y - you propose a new feature for Y - ... which you use in X - the new feature of Y is in develop - ... and so is your use of it - therefore, X's develop depends on Y's develop Y is often Boost.Config and it's not coupled to anything. If you have to test against Y's master, you need to wait until the new feature is merged into master before being able to make use of it.
On 2/17/16 9:06 AM, Peter Dimov wrote:
Robert Ramey wrote:
All these cases relate to two coupled libraries.
If by "coupled" you mean interdependent, that is, library X depends on Y and Y depends on X, then no.
I meant that some enhancement of X is dependent upon some enhancement of Y. I think that should be clear. The typical case is this:
- your library X uses Y - you propose a new feature for Y - ... which you use in X - the new feature of Y is in develop - ... and so is your use of it - therefore, X's develop depends on Y's develop
Y is often Boost.Config and it's not coupled to anything.
If you have to test against Y's master, you need to wait until the new feature is merged into master before being able to make use of it.
Right, that's why i recommend doing the push of both at once. I don't think this constitutes and argument against my main point. Robert Ramey
On 2/16/2016 12:17 PM, Rene Rivera wrote:
On Tue, Feb 16, 2016 at 10:34 AM, Robert Ramey <ramey@rrsd.com> wrote:
On 2/15/16 10:27 PM, Vladimir Prus wrote:
On 15-Feb-16 8:16 PM, Robert Ramey wrote:
On 2/15/16 8:37 AM, Steven Watanabe wrote:
AMDG
On 02/15/2016 09:19 AM, Robert Ramey wrote:
To me, more urgent is the problem associated with b2 on cygwin. I've noted on this list. Basically if one builds b2 using the bootstrap.sh under cygwin it seems that it get's the / and \ mixed up in the pathnames. And this prevents b2 from working correctly. I wouldn't be surprised if this isn't also a problem with mingw on windows as well. I'm guessing this probably an easy fix for you.
Did my patch not work?
Honestly, I haven't had time to get back to this yet.
So, the summary of this thread is that the ball is in your court?
I have made a personal commitment to maintaining the boost serialization library. So the "ball is ALWAYS in my court".
In order to fulfill this commitment, I depend on a number of resources:
a) my personal time b) my own computer hardware c) other boost libraries - the library depends upon other boost components such as boost spirit d) boost build - b2 etc. e) boost regression testing setup up
The same applies to all of us. (A)
What do I do when one of the above resources fails to work as advertised?
This is the question I face. In many cases, personal time, hardware, etc. I try to make adjustments. Sometimes this means delay in response time, etc. Sometimes this means me taking on things that are incidental to the library maintenance such as testing a fix in some other component, etc.
The same applies to all of us. (B)
So, the ball is in my court, but that doesn't mean it's not in other courts
too!
I believe that some small and easy changes would make development of easier for every one:
a) the regression system should implement the develop/master branch system which boost libraries do. This would permit any changes to the regression code and/or anything it depends upon to be tested separately before being unleashed on unsuspecting library developers.
1. Has there been an instance where the regression system changes failed in the current single branch? 2. Where would we get the resources to test with more than one branch of the regression system?
Do we even have tests to certify that the regression testing system is working properly ? If we do have such tests I do not see why the tests could not be run for a 'develop' branch as well as for a 'master' branch, just like any other Boost library. In general I agree with Robert that Boost tools should be tested just like any Boost library should be tested, in order to ascertain that any changes made to a Boost tool is working properly.
(C)
b) the testing/build components should be tested the same way that boost
libraries are tested. Were this being done, any anomalies on b2 or other components would be detected the moment they occurred so that library developers wouldn't have to spend (a lot) if time tracking them down.
They are currently tested more than most libraries:
https://travis-ci.org/boostorg/build/builds/108576884 https://travis-ci.org/boostorg/build/builds/85795874 https://travis-ci.org/boostorg/boost/builds/109532213 https://travis-ci.org/boostorg/boost/builds/109546290 http://www.boost.org/development/tests/master/developer/build.html http://www.boost.org/development/tests/master/developer/build.html
Is there more testing that should be done?
c) the regression system should be a boost submodule so it gets distributed along whenever one clones the main project. This would be useful to those who want to understand what's going on and make available the components of the regression system to others which might find them useful. The current system has them in a separate repo which doesn't have a master branch. I found this to be rather confusing while spending time spelunking into things that are really outside of my responsibility and expertise.
First see (C). Second..
1. Making it a submodule (as it used to be), adds perceived requirements on it that I don't want to keep (as it adds to the time I need to spend in dealing with it).
The same applies to all of us. <g>
2. It's only slight convenience for a small percentage of Boost developers for some small percentage of time. 3. It adds unneeded clutter to the Boost releases as it would get included in what end users get.
Simply because a library/tool is regression tested does not mean that those tests have to be part of an official Boost release. Granted that is normally the case but I believe we do have means by which our modular-boost source is reduced to a lesser number of files for an official Boost release.
d) The regression test matrix is generated by testing the develop branch of
each library against the develop branch of other libraries. Currently, the boost library fails to build with the spirit library on the develop branch.
Did I miss someone mention this on the dev list with a [spirit] tag?
So all the serialization library tests fail on the test matrix. I presume that all other tests of libraries on the develop branch which depend upon the serialization library fail because the serialization library won't build on that branch. As boost get's bigger, this problem get's worse. How can this be acceptable?
It's not acceptable. But given that (A) and (B) also apply to the Spirit maintainers it's hard to avoid :-(
I do appreciate all the suggestions I receive to work around specific
problems. But it would save a huge amount of time if the above changes were made so these problems wouldn't come up in the first place. Suggestions a), b) and c) would be easy to implement. d) is somewhat more challenging - but well worth it.
I don't see a suggestion in (d).
On 16-Feb-16 7:34 PM, Robert Ramey wrote:
On 2/15/16 10:27 PM, Vladimir Prus wrote:
On 15-Feb-16 8:16 PM, Robert Ramey wrote:
On 2/15/16 8:37 AM, Steven Watanabe wrote:
AMDG
On 02/15/2016 09:19 AM, Robert Ramey wrote:
To me, more urgent is the problem associated with b2 on cygwin. I've noted on this list. Basically if one builds b2 using the bootstrap.sh under cygwin it seems that it get's the / and \ mixed up in the pathnames. And this prevents b2 from working correctly. I wouldn't be surprised if this isn't also a problem with mingw on windows as well. I'm guessing this probably an easy fix for you.
Did my patch not work?
Honestly, I haven't had time to get back to this yet.
So, the summary of this thread is that the ball is in your court?
I have made a personal commitment to maintaining the boost serialization library. So the "ball is ALWAYS in my court".
In order to fulfill this commitment, I depend on a number of resources:
a) my personal time b) my own computer hardware c) other boost libraries - the library depends upon other boost components such as boost spirit d) boost build - b2 etc. e) boost regression testing setup up
Robert, While I'd be happy to discuss a bigger picture, one point at a time, we have 1.61 deadlines in a couple of weeks, so I'd rather we tackle the immediate issues first. - It seems you have some issues on Cygwin - Steven has provided a patch - You haven't had the time to look into it yet So, it seems that on the issue of cygwin testing, you are the person who has to make the next step. Is that correct? -- Vladimir Prus http://vladimirprus.com
On 2/17/16 1:25 AM, Vladimir Prus wrote:
- It seems you have some issues on Cygwin - Steven has provided a patch - You haven't had the time to look into it yet
So, it seems that on the issue of cygwin testing, you are the person who has to make the next step. Is that correct?
LOL - I'm a volunteer, I don't HAVE to do anything. But I do have to make a choice. My options are a) spend time with b2 development along the lines that Stephen has suggested. b) presume that testing on my os shows that the serialization library is indeed correct and ignore the testing failures on cygwin and maybe? mingw. c) ignore the failures on the develop test matrix due to changes in develop of other libraries and just merge from develop into release. d) do nothing and wait for other stuff to get fixed. The serialization library won't get the latest improvements, but it won't break anything either. That's the option I chose for 1.59. I can do it again. I fix bugs and check enhancements to the library on my local system. At this point I presume they are correct and that I haven't introduced new bugs. I look to the test system to prove me wrong. But right now for the reasons I've cited, it can't do that. I need the help it's supposed to provide but it's providing it. I'm not so concerned about the next release as I am about this process working smoothly. I've made several suggestions about how we can make this simpler - which amount to making the test system development look more like the rest of boost. I'm really reluctant to dive into b2 development/debug for a number of reasons which I'm guessing should be pretty obvious. Robert Ramey
On 17-Feb-16 8:02 PM, Robert Ramey wrote:
On 2/17/16 1:25 AM, Vladimir Prus wrote:
- It seems you have some issues on Cygwin - Steven has provided a patch - You haven't had the time to look into it yet
So, it seems that on the issue of cygwin testing, you are the person who has to make the next step. Is that correct?
LOL - I'm a volunteer, I don't HAVE to do anything.
Is anybody on this list directly paid for his work on Boost? ;-)
But I do have to make a choice. My options are
a) spend time with b2 development along the lines that Stephen has suggested.
Steven has provided a patch, you only need to apply it and try again. Do you think you can allocate 5 minutes for this some time soon?
b) presume that testing on my os shows that the serialization library is indeed correct and ignore the testing failures on cygwin and maybe? mingw.
c) ignore the failures on the develop test matrix due to changes in develop of other libraries and just merge from develop into release.
As a release manager, I would advise against this approach - because if things break in master, all options at our disposal will be bad.
d) do nothing and wait for other stuff to get fixed. The serialization library won't get the latest improvements, but it won't break anything either. That's the option I chose for 1.59. I can do it again.
I fix bugs and check enhancements to the library on my local system. At this point I presume they are correct and that I haven't introduced new bugs. I look to the test system to prove me wrong. But right now for the reasons I've cited, it can't do that. I need the help it's supposed to provide but it's providing it. I'm not so concerned about the next release as I am about this process working smoothly. I've made several suggestions about how we can make this simpler - which amount to making the test system development look more like the rest of boost.
Could we adopt a more iterative approach? As you point out, we're volunteers, so a large and vague task like 'write a test suite for regression report generator' is both hard to schedule, and is high-risk, given that such a test suite might not fix your actual problems. It would be more convenient to fix immediate issues, adding tests as we go - after all, that's how Boost.Build got to hundreds of testcases, and I see no reason why we should do differently for regression report generator. If I understand correctly, the current issues for you are: - Shared library testing on OS El Capitan. I will take a look. - Testing on cygwin. Patch was provided, it seems that your testing of said patch is still the best approach. - Some unspecified issues with function visibility. If you need help with this, could you post a separate email. - Issues where Spirit either affects Serialization, or produces too many warnings causing everything else in the log to be truncated. If this still an issue, could you post a separate email detailing the problem? Thanks, -- Vladimir Prus http://vladimirprus.com
On 2/17/16 11:47 PM, Vladimir Prus wrote:
But I do have to make a choice. My options are
a) spend time with b2 development along the lines that Stephen has suggested.
Steven has provided a patch, you only need to apply it and try again. Do you think you can allocate 5 minutes for this some time soon?
I don't think it's 5 min - it never is. But I'll try to find some (more) time to do this. If our testing system was more helpful, Stephen could make the change on develop and check it and watch the b2 test results. THAT might be 5 minutes. I realize that this presumes that cygwin/mingw are not being tested by the test volunteers so this criticism is a little unfair. I do have ideas on how to address this - but they're too far off topic for this thread. - even for me.
b) presume that testing on my os shows that the serialization library is indeed correct and ignore the testing failures on cygwin and maybe? mingw.
c) ignore the failures on the develop test matrix due to changes in develop of other libraries and just merge from develop into release.
As a release manager, I would advise against this approach - because if things break in master,
We're in agreement here. It's my policy that every merge to the master should result in a strict improvement in the library - No net increase in the number of known bugs and no net decrease in the number of freatures/compilers/environment supported. But course I need the testing system in order to implement this policy.
I've made several suggestions about how we can make this simpler - which amount to making the test system development look more like the rest of boost.
Could we adopt a more iterative approach? As you point out, we're volunteers, so a large and vague task like 'write a test suite for regression report generator' is both hard to schedule, and is high-risk, given that such a test suite might not fix your actual problems.
I'm very sympathetic and don't expect immediate action - not that that keeps me from complaining. In general, I'd like to see boost tools development, testing, and deployment look much more similar to boost libraries. I think this would result in better tools and less work. Saying another way, I think that our development, review, testing and deployment practices have worked pretty well and I want to base the development of tools on the same model. In practice this would look like: a) tools directory structure would look more like libraries b) review of tools api, etc. would be more public and formal. In fairness, the openness of the tool process has improved over the past year. I think at C++Now I complained about the "drive-by tool development" where I felt I was getting ambushed by some fait compli. Maybe that made a difference - but probably not. c) since the tools look like the libraries and many of them already have some tests, it would be easy to integrate them into the same testing regimin we already have. d) none of the above would require any (as far as I know) re-coding just some directory/repository re-organization. e) I think this would make things far easier for tool builders and maintainers. They wouldn't have a special setup. Any user with a problem with a tool could open up an issue etc. ... f) it would be simpler for users and would encourage them to submit more fixes, etc. I'm willing to consider regression.py script a special beast which doesn't fit into this scheme. But leveraging our design patterns and infrastructure to better support tool development would help address other problems - like the one which provokes this tread. It would be more convenient to fix immediate issues,
adding tests as we go - after all, that's how Boost.Build got to hundreds of testcases, and I see no reason why we should do differently for regression report generator.
I agree. I didn't mean to suggest otherwise. I'd just like to see what we already have used more effectively.
If I understand correctly, the current issues for you are:
- Shared library testing on OS El Capitan. I will take a look. - Testing on cygwin. Patch was provided, it seems that your testing of said patch is still the best approach. OK - Some unspecified issues with function visibility. If you need help with this, could you post a separate email. This is sort of interesting. correctly setting up visibility across multiple compilers, multiple shared libraries, etc. turns out to be a lot trickier to get right that first meets the idea. In the case of the serialization library its especially stick as one library wserialization is used as a callee while at the same time acts as a caller into the serialization library. It seems like it should be simple - but it hasn't been for me. The msvc compiler generates a lot of warnings (from spirit) when building the library. The output is truncated so the errors can't be seen. The turn around using the test matrix was just too slow - a couple of days waiting for test results to cycle. So I resolved to fire up my old XP laptop with MSVC so I could test locally on this platform. This would cut my turnaround time to 1 minute. At that point I ran into the b2/cygwin problem - which btw takes a lot of time to track down and verify with Stephen.
- Issues where Spirit either affects Serialization, or produces too many warnings causing everything else in the log to be truncated. If this still an issue, could you post a separate email detailing the problem?
Well, spirit generates a lot of warnings. But this is only a problem when the library fails to build - as it was when I was struggling with visibility issues. I think I got the visibility issue addressed but then things failed to build due to some issue with spirit in the develop branch. Now it looks like that is fixed and the libraries build, But a large number of tests are failing because of new problem in boost optional develop branch. Testing a against the develop branch is like trying to build a castle on quicksand. Maybe this sheds some light on the motivation for my suggestions. and BTW - that actual changes in the serialization library I'm trying to get in are not at all trivial - among others getting utf8 codeconvert to work properly across a bunch of different libraries - some of them buggy in their own right. This is not made any easier of the way we implemented the utf8_codecvt facet in the boost / detail at the insistence of David Abrahams because it had never been reviewed. This is another instance of violating our standard patterns and practices because it seems expedient only to suffer the consequences longer term. Robert Ramey
On Thu, Feb 18, 2016 at 11:40 AM, Robert Ramey <ramey@rrsd.com> wrote:
On 2/17/16 11:47 PM, Vladimir Prus wrote:
But I do have to make a choice. My options are
a) spend time with b2 development along the lines that Stephen has suggested.
Steven has provided a patch, you only need to apply it and try again. Do you think you can allocate 5 minutes for this some time soon?
I don't think it's 5 min - it never is. But I'll try to find some (more) time to do this. If our testing system was more helpful, Stephen could make the change on develop and check it and watch the b2 test results. THAT might be 5 minutes. I realize that this presumes that cygwin/mingw are not being tested by the test volunteers so this criticism is a little unfair. I do have ideas on how to address this - but they're too far off topic for this thread. - even for me.
FYI.. B2 has a develop and master branch. And, yes, Stephen could have check his patch in. But, I suspect, he decided it would be safer and faster to have you try it out since you had a repeatable failure case. Than to subject others using the b2 develop branch to an experiment. -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail
On 2/18/16 10:00 AM, Rene Rivera wrote:
FYI.. B2 has a develop and master branch. And, yes, Stephen could have check his patch in. But, I suspect, he decided it would be safer and faster to have you try it out since you had a repeatable failure case. Than to subject others using the b2 develop branch to an experiment.
Hallelujah !!! That's my argument that we should test our own code on the develop branch against all other code libraries and tools on the master branch! Robert Ramey
On 11.02.2016 01:25, Vladimir Prus wrote:
I wanted to remind that the master branch is closing for new libraries and breaking changes on Feb 24, about two weeks from now. We'll be closed for major changes on March 2. That's not a lot of time, please make sure any big work is completed.
I have just merged a PR to the Boost.Python 'develop' branch that fixes a regression in Boost 1.60 (https://github.com/boostorg/python/pull/59). I would very much like to get this into master for the 1.61 release, though I'm aware that this doesn't give us much time. Luckily the fix is small, and doesn't have any ramifications outside Boost.Python. I'm now waiting to see what the next test builds show, though I'm unclear about the testing schedule, i.e. how long I need to wait until I can safely merge the 'develop' branch to 'master'. Thanks, Stefan -- ...ich hab' noch einen Koffer in Berlin...
On 3/6/2016 9:11 PM, Stefan Seefeld wrote:
On 11.02.2016 01:25, Vladimir Prus wrote:
I wanted to remind that the master branch is closing for new libraries and breaking changes on Feb 24, about two weeks from now. We'll be closed for major changes on March 2. That's not a lot of time, please make sure any big work is completed.
I have just merged a PR to the Boost.Python 'develop' branch that fixes a regression in Boost 1.60 (https://github.com/boostorg/python/pull/59). I would very much like to get this into master for the 1.61 release, though I'm aware that this doesn't give us much time. Luckily the fix is small, and doesn't have any ramifications outside Boost.Python. I'm now waiting to see what the next test builds show, though I'm unclear about the testing schedule, i.e. how long I need to wait until I can safely merge the 'develop' branch to 'master'.
Stefan, it seems to me that this patch can be merged to master as soon as master is open for bugfixes, hopefully soon. Probably you'll have test results at that point as well. -- Vladimir Prus http://vladimirprus.com
On 19.03.2016 15:47, Vladimir Prus wrote:
On 3/6/2016 9:11 PM, Stefan Seefeld wrote:
On 11.02.2016 01:25, Vladimir Prus wrote:
I wanted to remind that the master branch is closing for new libraries and breaking changes on Feb 24, about two weeks from now. We'll be closed for major changes on March 2. That's not a lot of time, please make sure any big work is completed.
I have just merged a PR to the Boost.Python 'develop' branch that fixes a regression in Boost 1.60 (https://github.com/boostorg/python/pull/59). I would very much like to get this into master for the 1.61 release, though I'm aware that this doesn't give us much time. Luckily the fix is small, and doesn't have any ramifications outside Boost.Python. I'm now waiting to see what the next test builds show, though I'm unclear about the testing schedule, i.e. how long I need to wait until I can safely merge the 'develop' branch to 'master'.
Stefan,
it seems to me that this patch can be merged to master as soon as master is open for bugfixes, hopefully soon. Probably you'll have test results at that point as well.
The Boost.Python develop branch was merged to master just before the deadline, so all is good. (I'm a bit unsure about the proper process to submit release notes, though.) Thanks, Stefan -- ...ich hab' noch einen Koffer in Berlin...
Op 11-2-2016 om 7:25 schreef Vladimir Prus:
I wanted to remind that the master branch is closing for new libraries and breaking changes on Feb 24, about two weeks from now. We'll be closed for major changes on March 2. That's not a lot of time, please make sure any big work is completed.
Hi, according to the calendar the masterbranch today openend for bugfixes for 1.61. We have some (a bugfix and some cleanup in include folders). All regression tests are OK. OK to merge? Regards, Barend
On 3/17/2016 10:10 PM, Barend Gehrels wrote:
Op 11-2-2016 om 7:25 schreef Vladimir Prus:
I wanted to remind that the master branch is closing for new libraries and breaking changes on Feb 24, about two weeks from now. We'll be closed for major changes on March 2. That's not a lot of time, please make sure any big work is completed.
Hi, according to the calendar the masterbranch today openend for bugfixes for 1.61. We have some (a bugfix and some cleanup in include folders). All regression tests are OK.
OK to merge?
Hi Barend, the master branch is not yet open - it will be open as soon as beta 1 rc 1 is tested by Boosters and becomes beta 1. Thanks for the patience! -- Vladimir Prus http://vladimirprus.com
participants (10)
-
Andrey Semashev -
Barend Gehrels -
Edward Diener -
John Maddock -
Peter Dimov -
Rene Rivera -
Robert Ramey -
Stefan Seefeld -
Steven Watanabe -
Vladimir Prus