Could we consider fixing a date for boost 1.33. I would like to agree to just concentrate on fixes, tests and resolving pending issues regarding code currently checked into cvs.. I think this would be relatively painless - at least compared to the last time. Robert Ramey
On Sun, 30 Jan 2005 15:45:34 -0800, Robert Ramey wrote
Could we consider fixing a date for boost 1.33.
Do we have someone to manage the release yet? It's alot of work and hasn't been too long since 1.32. If the goal is really to release a few targeted bug fixes then it might be better to shoot for 1.32.2 instead. Jeff
Jeff Garland wrote:
Do we have someone to manage the release yet? It's alot of work and hasn't been too long since 1.32. If the goal is really to release a few targeted bug fixes then it might be better to shoot for 1.32.2 instead.
I second that. Are there any fixes that justify a new minor release? Stefan
Whatever number you want is fine with me. I believe we should make release more frequently with smaller increments. This will disuade library authors from cramming stuff in at the last minute which slows things down rather than speeds things up. It will also give users confidence that the number of bugs and quirks is minimized. Robert Ramey The things pending in this release (what ever number it has) a) streams - jonathan turkanis b) serialization - dll version c) I'm not sure what else - ranges might be in here d) miscellaneous bug fixes. In my view the release should be a much simpler affair than it has been in the past. I would like to see a) an announce ment to refrain checking in anything other than bug fixes to pass tests. b) this "quiet period" would be about 10 days or until the test matrix is at acceptable level. c) The release would be "cut" The fact that release contains only one new library and other minor changes hopefully would make this process relatively un dramatic. Robert Ramey Stefan Slapeta wrote:
Jeff Garland wrote:
Do we have someone to manage the release yet? It's alot of work and hasn't been too long since 1.32. If the goal is really to release a few targeted bug fixes then it might be better to shoot for 1.32.2 instead.
I second that. Are there any fixes that justify a new minor release?
Stefan
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Robert Ramey writes: [...]
In my view the release should be a much simpler affair than it has been in the past. I would like to see
a) an announce ment to refrain checking in anything other than bug fixes to pass tests. b) this "quiet period" would be about 10 days or until the test matrix is at acceptable level. c) The release would be "cut"
The fact that release contains only one new library and other minor changes hopefully would make this process relatively un dramatic.
The above assumes that *the main trunk* is in the good state, and it's not -- http://www.meta-comm.com/engineering/boost-regression/developer/summary.html (red shows regressions against 1.32.0). -- Aleksey Gurtovoy MetaCommunications Engineering
Aleksey Gurtovoy wrote:
Robert Ramey writes: [...]
The above assumes that *the main trunk* is in the good state, and it's not --
actually it assumes this the main trunk can be brought to a good state in a relatively short time like 10 days. I don't believe the number of red squares is an accurate reflection of the state and how much work there is to do. Many of these problems have a common cause. In at least one case, there's a new compiler which wasn't tested at 1.32 at all. I believe that a new release have improvements over the current one and have no regressions. Robert Ramey
(red shows regressions against 1.32.0).
Robert Ramey writes:
Aleksey Gurtovoy wrote:
Robert Ramey writes: [...]
The above assumes that *the main trunk* is in the good state, and it's not --
actually it assumes this the main trunk can be brought to a good state in a relatively short time like 10 days.
That's what I meant.
I don't believe the number of red squares is an accurate reflection of the state and how much work there is to do.
I'd say it's proven to be pretty accurate (excluding the extreme cases when everything is red due to Boost-wide or environment/configuration issues).
Many of these problems have a common cause.
Across all the libraries? Note that currently the reports are missing a significant share of (our) Win32 toolsets which will definitely add more colors to the picture.
In at least one case, there's a new compiler which wasn't tested at 1.32 at all.
Which one? If it wasn't tested with 1.32, it shouldn't appear as a regression.
I believe that a new release have improvements over the current one and have no regressions.
If you meant "should have", I agree 100%. -- Aleksey Gurtovoy MetaCommunications Engineering
Aleksey Gurtovoy wrote:
Robert Ramey writes:
Aleksey Gurtovoy wrote:
Robert Ramey writes: [...]
I don't believe the number of red squares is an accurate reflection of the state and how much work there is to do.
I'd say it's proven to be pretty accurate (excluding the extreme cases when everything is red due to Boost-wide or environment/configuration issues).
Many of these problems have a common cause.
Across all the libraries?
Boost.Test is getting upgraded. Its "priviledged" position in the dependency hiearchy means that an issue with this library ripples accross all libraries. This is very apparent when one investigates the the red squares.
Note that currently the reports are missing a significant share of (our) Win32 toolsets which will definitely add more colors to the picture.
In at least one case, there's a new compiler which wasn't tested at 1.32 at all.
Which one? If it wasn't tested with 1.32, it shouldn't appear as a regression.
This is labeled as darwin. Its different that the previous one named darwin. Its Codewarrior 9.3 for the Mac OS X
I believe that a new release have improvements over the current one and have no regressions.
If you meant "should have", I agree 100%.
I believe we are much closer to this than a cursory examination of the test matrix would suggest. Robert Ramey
Aleksey Gurtovoy wrote:
In at least one case, there's a new compiler which wasn't tested at 1.32 at all.
Which one? If it wasn't tested with 1.32, it shouldn't appear as a regression.
Actually there are two: a) the one labeled cw-9.3 is codewarrior 9.3 for the Mac OS X. This is new combination since the release of 1.32 . The issues remaining to be sorted out is which of two standard library implementations to use, etc. b) sunpro 5_3 is also a new platform. Its showing yellow so I suppose its not a regression. Robert Ramey
On Tue, 1 Feb 2005 08:41:29 -0800, Robert Ramey <ramey@rrsd.com> wrote:
b) sunpro 5_3 is also a new platform. Its showing yellow so I suppose its not a regression.
Not at all. Just status quo with that compiler, though a recent thread leads me to believe that a small change may soon fix a number of these errors. See http://thread.gmane.org/gmane.comp.lib.boost.user/7452 and http://thread.gmane.org/gmane.comp.lib.boost.devel/116971 I'm trying to test the change suggested in the first thread now, but regression.py is currently falling over on me: # Getting sources (Tue, 01 Feb 2005 17:21:53 +0000)... # Downloading "http://www.meta-comm.com/engineering/boost/snapshot/boost-CVS-HEAD.tar.bz2" to "/home/nbde52d/src/boost-regression"... # Looking for old unpacked archives... # Unpacking boost tarball ("/home/nbde52d/src/boost-regression/boost-CVS-HEAD.tar.bz2")... # Unpacked into directory "/home/nbde52d/src/boost-regression/boost-CVS-HEAD-05-02-01-1631" # Deleting "/home/nbde52d/src/boost-regression/boost" directory... # Renaming "/home/nbde52d/src/boost-regression/boost-CVS-HEAD-05-02-01-1631" into "/home/nbde52d/src/boost-regression/boost" Traceback (most recent call last): File "./regression.py", line 837, in ? commands[ command ]( **accept_args( args ) ) File "./regression.py", line 666, in regression setup( comment, toolsets, bjam_toolset, pjl_toolset, monitored, proxy, [] ) File "./regression.py", line 396, in setup import_utils() File "./regression.py", line 365, in import_utils import utils as utils_module ImportError: No module named utils Alexsey? -- Caleb Epstein caleb dot epstein at gmail dot com
Caleb Epstein wrote: [...]
I'm trying to test the change suggested in the first thread now, but regression.py is currently falling over on me:
# Getting sources (Tue, 01 Feb 2005 17:21:53 +0000)... # Downloading "http://www.meta-comm.com/engineering/boost/snapshot/boost-CVS-HEAD.tar.bz2" to "/home/nbde52d/src/boost-regression"... # Looking for old unpacked archives... # Unpacking boost tarball ("/home/nbde52d/src/boost-regression/boost-CVS-HEAD.tar.bz2")... # Unpacked into directory "/home/nbde52d/src/boost-regression/boost-CVS-HEAD-05-02-01-1631" # Deleting "/home/nbde52d/src/boost-regression/boost" directory... # Renaming "/home/nbde52d/src/boost-regression/boost-CVS-HEAD-05-02-01-1631" into "/home/nbde52d/src/boost-regression/boost" Traceback (most recent call last): File "./regression.py", line 837, in ? commands[ command ]( **accept_args( args ) ) File "./regression.py", line 666, in regression setup( comment, toolsets, bjam_toolset, pjl_toolset, monitored, proxy, [] ) File "./regression.py", line 396, in setup import_utils() File "./regression.py", line 365, in import_utils import utils as utils_module ImportError: No module named utils
This is a typical error that occurs after an incomplete tarball download (which happens quite frequently, and _when_ it happens, its reproducible, say, you can't download a complete tarball then for about an hour! I always thought this is a problem of our proxy.) At least, this says that the utils directory isn't on your hard disk. Just test the integrity of your tarball... BTW, it's strange that the testing script continues even if the tarball isn't complete. Isn't there an error reported from the extraction routine?? Stefan
On Tue, 01 Feb 2005 19:31:53 +0100, Stefan Slapeta <stefan@slapeta.com> wrote:
This is a typical error that occurs after an incomplete tarball download (which happens quite frequently, and _when_ it happens, its reproducible, say, you can't download a complete tarball then for about an hour! I always thought this is a problem of our proxy.) At least, this says that the utils directory isn't on your hard disk. Just test the integrity of your tarball...
And so it is. I've run into this once before but I guess I forgot this answer. I suspect that I grabbed the tarball while it was still being created. If this is the case, can the tarball script be modified to create the file using a temporary name and then removing the old file and renaming the new one when tar finishes?
BTW, it's strange that the testing script continues even if the tarball isn't complete. Isn't there an error reported from the extraction routine??
It appears then when the Python TarFile object is used in pipe mode, it is unable to detect errors in the file it is processing. I took a 100k chunk of the boost-CVS-HEAD.tar.bz2 tarball and ran it through the following code: import tarfile import sys for file in sys.argv[1:]: tarfile.open (file, "r|bz2").list() The program proceeds to list the first 200+ entries in the truncated tarfile, and then exit silently. If the mode string is changed to "r:bz2", the initial 200+ entries are again listed, but the corruption is detected and an exception is thrown. I'd suggest that regression.py be changed to use the "r:" mode syntax (assuming this doesn't try and decompress the entire file in-core) -- Caleb Epstein caleb dot epstein at gmail dot com
Caleb Epstein writes:
On Tue, 01 Feb 2005 19:31:53 +0100, Stefan Slapeta <stefan@slapeta.com> wrote:
This is a typical error that occurs after an incomplete tarball download (which happens quite frequently, and _when_ it happens, its reproducible, say, you can't download a complete tarball then for about an hour! I always thought this is a problem of our proxy.) At least, this says that the utils directory isn't on your hard disk. Just test the integrity of your tarball...
And so it is. I've run into this once before but I guess I forgot this answer.
I suspect that I grabbed the tarball while it was still being created. If this is the case, can the tarball script be modified to create the file using a temporary name and then removing the old file and renaming the new one when tar finishes?
It's not the case, but obviously something's fishy with the tarball creation. We'll look into it.
BTW, it's strange that the testing script continues even if the tarball isn't complete. Isn't there an error reported from the extraction routine??
It appears then when the Python TarFile object is used in pipe mode, it is unable to detect errors in the file it is processing. I took a 100k chunk of the boost-CVS-HEAD.tar.bz2 tarball and ran it through the following code:
import tarfile import sys
for file in sys.argv[1:]: tarfile.open (file, "r|bz2").list()
The program proceeds to list the first 200+ entries in the truncated tarfile, and then exit silently. If the mode string is changed to "r:bz2", the initial 200+ entries are again listed, but the corruption is detected and an exception is thrown.
I'd suggest that regression.py be changed to use the "r:" mode syntax (assuming this doesn't try and decompress the entire file in-core)
Done. The script will update itself automatically on the next run, or you can get the new version manually at http://www.meta-comm.com/engineering/boost/regression.tar.gz. Thanks for researching this! -- Aleksey Gurtovoy MetaCommunications Engineering
Robert Ramey writes:
Aleksey Gurtovoy wrote:
In at least one case, there's a new compiler which wasn't tested at 1.32 at all.
Which one? If it wasn't tested with 1.32, it shouldn't appear as a regression.
Actually there are two:
a) the one labeled cw-9.3 is codewarrior 9.3 for the Mac OS X. This is new combination since the release of 1.32 .
It is. These failures are displayed as regressions because the toolset name does not include the platform and as result the reporting tools are picking up 1.32/cw-9_3 results for Windows. Stephen, could you please adjust your toolset to include the platform name, e.g. "cw-9_3-darwin"?
b) sunpro 5_3 is also a new platform. Its showing yellow so I suppose its not a regression.
Nope, it's not. -- Aleksey Gurtovoy MetaCommunications Engineering
The above assumes that *the main trunk* is in the good state, and it's not -- http://www.meta-comm.com/engineering/boost-regression/developer/summary.html (red shows regressions against 1.32.0).
Probably 90% of those are down to new Boost.Test failures - until that's stable there's no chance of a release. I've also just made some type traits changes that may cause new failures - it's too soon to tell yet as the results aren't all in, and until Boost.Test is fixed many of the tests aren't even getting built anyway. However if we can agree to stabilise Boost's core libs (test, type traits, config) over the next couple of weeks, then we should be able to get a release out soon after that. John.
I've also just made some type traits changes that may cause new failures - it's too soon to tell yet as the results aren't all in, and until Boost.Test is fixed many of the tests aren't even getting built anyway.
It this moment CVS HEAD should compile without errors on most compilers.
However if we can agree to stabilise Boost's core libs (test, type traits, config) over the next couple of weeks, then we should be able to get a release out soon after that.
I am in the middle of major update for Boost.Test. I still need at least 2-3 weeks to complete the set of modification I plan for this release. I am making modification incrementally, so I could see what is broken by what change. Sorry for inconvenience, Gennadiy
It this moment CVS HEAD should compile without errors on most compilers.
Um, take a look at http://www.meta-comm.com/engineering/boost-regression/developer/test.html It doesn't look all that good, sorry.
However if we can agree to stabilise Boost's core libs (test, type traits, config) over the next couple of weeks, then we should be able to get a release out soon after that.
I am in the middle of major update for Boost.Test. I still need at least 2-3 weeks to complete the set of modification I plan for this release. I am making modification incrementally, so I could see what is broken by what change.
OK, I guess we can't really plan a release until after then, I do appreciate that there is really no good time to make a change like this, John.
"John Maddock" <john@johnmaddock.co.uk> wrote in message news:038701c5087b$f39253e0$54540252@fuji...
It this moment CVS HEAD should compile without errors on most compilers.
Um, take a look at http://www.meta-comm.com/engineering/boost-regression/developer/test.html It doesn't look all that good, sorry.
This page doesn't update that frequently Gennadiy
"John Maddock" <john@johnmaddock.co.uk> wrote in message news:038701c5087b$f39253e0$54540252@fuji...
It this moment CVS HEAD should compile without errors on most compilers.
Um, take a look at http://www.meta-comm.com/engineering/boost-regression/developer/test.html It doesn't look all that good, sorry.
Another thing about this page is: 1. cw 9_3 failures are unaccessible 2. intel- 8.1 failures caused by misconfiguration 3. gcc- 3.4.3- linux caused by error like: /usr/local/gcc-3.4.3/bin/g++: cannot execute binary file 4. Looks like many test files did not get updated cuase they point to deleted files Gennadiy
participants (4)
-
Aleksey Gurtovoy -
Caleb Epstein -
Doug Gregor -
Gennadiy Rozental -
Jeff Garland -
John Maddock -
Robert Ramey -
Stefan Slapeta