[1.35.0] Developer preparation
Until further notice, the plan is to do quarterly Boost releases, and stick to that schedule even if updates for particular libraries aren't ready. If a library on the trunk isn't ready for a release, the prior release will be used for that library. I hoping for a final cut-off date of Friday, October 19, for making "go/no-go" decisions on which library updates make it into 1.35.0. That means libraries with updates to be included should be passing regression tests on trunk well before then. The process of merging into the release branch will start sooner for libraries already ready. Here is what developers should be doing over the next two weeks: * Start watching the regression tests at http://beta.boost.org/development/tests/trunk/developer/summary.html * For release criteria compilers, fix or markup all failures caused by your library's code. Fix or markup failures caused by your library's code for other compilers according to your own judgment. * For release criteria compilers show failures you think are caused by some other library's code, or by test configuration problems, post list notifications directed at the library or tool causing the problem. For other compilers, do the same if you wish. * For testing on the trunk to be a reliable indicator of release stability, prerequisite libraries on the trunk must be ready for release. If the trunk for your library isn't going to be ready in time for this release, please make a branch of the trunk with your library's name, and "merge" the trunk for your library so it is identical to 1.34.1. Note that if other libraries depend on your library, and you library is causing those libraries to break, you need to fix the trunk or return it to 1.34.1 within the next few days so that you don't impede the other libraries. Now the fun begins, --Beman
Beman Dawes ha escrito:
Until further notice, the plan is to do quarterly Boost releases, and stick to that schedule even if updates for particular libraries aren't ready.
If a library on the trunk isn't ready for a release, the prior release will be used for that library.
I hoping for a final cut-off date of Friday, October 19, for making "go/no-go" decisions on which library updates make it into 1.35.0. That means libraries with updates to be included should be passing regression tests on trunk well before then. The process of merging into the release branch will start sooner for libraries already ready.
I've got a preview version of Boost.MultiIndex for Boost 1.35 at http://www.boost-consulting.com/vault/index.php?direction=0&order=&directory=Containers which is basically stable since a couple of months or more (modulo minute changes since last psoted to the vault), but I haven't still commited it to the trunk as I was waiting for instructions on how the release procedure was going to be carried on. Am I allowed to check this into the trunk? I'm doing several local tests before so as to minimize any potential impact, I guess I'll be ready in 24 to 48 hours. Thank you, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
Joaquín Mª López Muñoz wrote:
Beman Dawes ha escrito:
Until further notice, the plan is to do quarterly Boost releases, and stick to that schedule even if updates for particular libraries aren't ready.
If a library on the trunk isn't ready for a release, the prior release will be used for that library.
I hoping for a final cut-off date of Friday, October 19, for making "go/no-go" decisions on which library updates make it into 1.35.0. That means libraries with updates to be included should be passing regression tests on trunk well before then. The process of merging into the release branch will start sooner for libraries already ready.
I've got a preview version of Boost.MultiIndex for Boost 1.35 at
http://www.boost-consulting.com/vault/index.php?direction=0&order=&directory=Containers
which is basically stable since a couple of months or more (modulo minute changes since last psoted to the vault), but I haven't still commited it to the trunk as I was waiting for instructions on how the release procedure was going to be carried on. Am I allowed to check this into the trunk? I'm doing several local tests before so as to minimize any potential impact, I guess I'll be ready in 24 to 48 hours.
Yes, please do commit it to the trunk. Thanks, --Beman
on Thu Oct 04 2007, Beman Dawes <bdawes-AT-acm.org> wrote:
Until further notice, the plan is to do quarterly Boost releases, and stick to that schedule even if updates for particular libraries aren't ready.
If a library on the trunk isn't ready for a release, the prior release will be used for that library.
I hoping for a final cut-off date of Friday, October 19, for making "go/no-go" decisions on which library updates make it into 1.35.0.
Well, I'm just going through re-entry from Kona, so that gives me very little time to do anything.
That means libraries with updates to be included should be passing regression tests on trunk well before then. The process of merging into the release branch will start sooner for libraries already ready.
Here is what developers should be doing over the next two weeks:
* Start watching the regression tests at http://beta.boost.org/development/tests/trunk/developer/summary.html
OK. My errors look like they are exclusively either: * Linker errors due to a mis-specified set of system libraries that needs to link with various Python components. That should be a relatively easy Boost.Build fix. * Tester misconfiguration issues, as in http://beta.boost.org/development/tests/trunk/developer/output/RSI%20Kludge-... * The import_ test failure. That's Stefan Seefeld's baby and I've asked him to look into it. Also, I had stopped maintaining trunk a long time ago, when I incorrectly understood that we were going to restart from 1.34.x for the next release, so I'm not 100% confident that my work on 1.34 has all been merged to the trunk for any of my libs. Not moving tests over could hide a feature removal, so I need to look at that for all my libs, not just Python.
* For release criteria compilers, fix or markup all failures caused by your library's code. Fix or markup failures caused by your library's code for other compilers according to your own judgment.
* For release criteria compilers show failures you think are caused by some other library's code, or by test configuration problems, post list notifications directed at the library or tool causing the problem. For other compilers, do the same if you wish.
* For testing on the trunk to be a reliable indicator of release stability, prerequisite libraries on the trunk must be ready for release. If the trunk for your library isn't going to be ready in time for this release, please make a branch of the trunk with your library's name, and "merge" the trunk for your library so it is identical to 1.34.1.
Well, I'll certainly need a few more days than "until friday" if Boost.Python is going to be ready for this release. Do you want me to replace the trunk with 1.34.1? We seem to be testing some compilers for 1.35 that we weren't testing for 1.34.1, so I don't have any confidence that it will actually fix the failures we're seeing. What -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
David Abrahams wrote:
* Tester misconfiguration issues, as in http://beta.boost.org/development/tests/trunk/developer/output/RSI%20Kludge-...
Ignore that one... It was only a test I ran to verify the new regression script was working. Now that it's shown up in the tables I'll remove it. Although... it should work since I do have Python25 installed and configured. It's just that I disabled the python25.lib file to make linking with mingw work with the python25.dll. Which should also work with msvc, but I guess BB is not set up that way. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo
Rene Rivera wrote:
David Abrahams wrote:
* Tester misconfiguration issues, as in http://beta.boost.org/development/tests/trunk/developer/output/RSI%20Kludge-...
It's just that I disabled the python25.lib file to make linking with mingw work with the python25.dll. Which should also work with msvc, but I guess BB is not set up that way.
Go figure... MSVC does not do automatic linking when given a DLL file only :-( So it's not a BB issue. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo
on Tue Oct 16 2007, Rene Rivera <grafikrobot-AT-gmail.com> wrote:
Rene Rivera wrote:
David Abrahams wrote:
* Tester misconfiguration issues, as in http://beta.boost.org/development/tests/trunk/developer/output/RSI%20Kludge-...
It's just that I disabled the python25.lib file to make linking with mingw work with the python25.dll. Which should also work with msvc, but I guess BB is not set up that way.
Go figure... MSVC does not do automatic linking when given a DLL file only :-( So it's not a BB issue.
You obviously understand way more about the problem than you've managed to communicate to me. Could you please try to spell out what the problem is and which components you think are at fault? -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
David Abrahams wrote:
on Tue Oct 16 2007, Rene Rivera <grafikrobot-AT-gmail.com> wrote:
Rene Rivera wrote:
* Tester misconfiguration issues, as in http://beta.boost.org/development/tests/trunk/developer/output/RSI%20Kludge-... It's just that I disabled the python25.lib file to make
David Abrahams wrote: linking with mingw work with the python25.dll. Which should also work with msvc, but I guess BB is not set up that way. Go figure... MSVC does not do automatic linking when given a DLL file only :-( So it's not a BB issue.
You obviously understand way more about the problem than you've managed to communicate to me. Could you please try to spell out what the problem is and which components you think are at fault?
Well I don't think I can blame anything for being wrong. The problem is that I have the ActiveState versions of Python installed. Those versions are compiled with MSVC. On the last release I did some changes to BB to get MSVC, Mingw, and Cygwin to all compile and link to Python correctly. Except for one aspect, MinGW can't use the python*.lib because it's an MSVC lib. But it can use the python*.dll directly just fine, since it directly read the exported symbols in the DLL. So to get MinGW to work I just disabled, by renaming to python*~~~.lib, the link library. Not sure if there's anything we can, or should, fix though. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo
on Wed Oct 17 2007, Rene Rivera <grafikrobot-AT-gmail.com> wrote:
Well I don't think I can blame anything for being wrong. The problem is that I have the ActiveState versions of Python installed. Those versions are compiled with MSVC. On the last release I did some changes to BB to get MSVC, Mingw, and Cygwin to all compile and link to Python correctly. Except for one aspect, MinGW can't use the python*.lib because it's an MSVC lib. But it can use the python*.dll directly just fine, since it directly read the exported symbols in the DLL. So to get MinGW to work I just disabled, by renaming to python*~~~.lib, the link library. Not sure if there's anything we can, or should, fix though.
Did you read http://boost.org/libs/python/doc/building.html#notes-for-mingw-and-cygwin-wi... and is it relevant to you? -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
David Abrahams wrote:
on Wed Oct 17 2007, Rene Rivera <grafikrobot-AT-gmail.com> wrote:
Well I don't think I can blame anything for being wrong. The problem is that I have the ActiveState versions of Python installed. Those versions are compiled with MSVC. On the last release I did some changes to BB to get MSVC, Mingw, and Cygwin to all compile and link to Python correctly. Except for one aspect, MinGW can't use the python*.lib because it's an MSVC lib. But it can use the python*.dll directly just fine, since it directly read the exported symbols in the DLL. So to get MinGW to work I just disabled, by renaming to python*~~~.lib, the link library. Not sure if there's anything we can, or should, fix though.
Did you read http://boost.org/libs/python/doc/building.html#notes-for-mingw-and-cygwin-wi... and is it relevant to you?
Yes, and it's only relevant in that if one does create the link library for MinGW using pexports+dlltool it will work. It's making it work with the default ActiveState install that causes problems for MinGW since it will find the MSVC link library first. Hence it might be worth trying to work around it, but probably not at this time. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo
David Abrahams wrote:
on Thu Oct 04 2007, Beman Dawes <bdawes-AT-acm.org> wrote:
Until further notice, the plan is to do quarterly Boost releases, and stick to that schedule even if updates for particular libraries aren't ready.
If a library on the trunk isn't ready for a release, the prior release will be used for that library.
I hoping for a final cut-off date of Friday, October 19, for making "go/no-go" decisions on which library updates make it into 1.35.0.
Well, I'm just going through re-entry from Kona, so that gives me very little time to do anything.
That means libraries with updates to be included should be passing regression tests on trunk well before then. The process of merging into the release branch will start sooner for libraries already ready.
Here is what developers should be doing over the next two weeks:
* Start watching the regression tests at http://beta.boost.org/development/tests/trunk/developer/summary.html
OK. My errors look like they are exclusively either:
* Linker errors due to a mis-specified set of system libraries that needs to link with various Python components. That should be a relatively easy Boost.Build fix.
Is someone working on this fix?
* Tester misconfiguration issues, as in http://beta.boost.org/development/tests/trunk/developer/output/RSI%20Kludge-...
* The import_ test failure. That's Stefan Seefeld's baby and I've asked him to look into it.
Please keep pestering him or markup the test as an expected failure (unless you consider it a showstopper).
Also, I had stopped maintaining trunk a long time ago, when I incorrectly understood that we were going to restart from 1.34.x for the next release, so I'm not 100% confident that my work on 1.34 has all been merged to the trunk for any of my libs. Not moving tests over could hide a feature removal, so I need to look at that for all my libs, not just Python.
Understood.
* For release criteria compilers, fix or markup all failures caused by your library's code. Fix or markup failures caused by your library's code for other compilers according to your own judgment.
* For release criteria compilers show failures you think are caused by some other library's code, or by test configuration problems, post list notifications directed at the library or tool causing the problem. For other compilers, do the same if you wish.
* For testing on the trunk to be a reliable indicator of release stability, prerequisite libraries on the trunk must be ready for release. If the trunk for your library isn't going to be ready in time for this release, please make a branch of the trunk with your library's name, and "merge" the trunk for your library so it is identical to 1.34.1.
Well, I'll certainly need a few more days than "until friday" if Boost.Python is going to be ready for this release.
That Friday date will have to be deferred, although I'm still planning to issue a progress report on Friday. With the tarball testers still broken, we just aren't making the progress hoped for.
Do you want me to replace the trunk with 1.34.1?
That's up to you. You can also simply ask that Boost.Python trunk not be merged into the release, thus skipping all Boost.Python updates for 1.35.0.
We seem to be testing some compilers for 1.35 that we weren't testing for 1.34.1, so I don't have any confidence that it will actually fix the failures we're seeing.
Testing continues to be a serious problem. Intellectually I knew that because of Thomas Witt's experiences, but now that I'm the one having to cope with it, our testing unreliability has really hit home. --Beman
on Wed Oct 17 2007, Beman Dawes <bdawes-AT-acm.org> wrote:
* Start watching the regression tests at http://beta.boost.org/development/tests/trunk/developer/summary.html
OK. My errors look like they are exclusively either:
* Linker errors due to a mis-specified set of system libraries that needs to link with various Python components. That should be a relatively easy Boost.Build fix.
Is someone working on this fix?
Not yet; I've barely had time to assess the situation. I may be able to work on that today.
* Tester misconfiguration issues, as in http://beta.boost.org/development/tests/trunk/developer/output/RSI%20Kludge-...
* The import_ test failure. That's Stefan Seefeld's baby and I've asked him to look into it.
Please keep pestering him or markup the test as an expected failure (unless you consider it a showstopper).
So far he hasn't responded, which worries me a little. I object to marking it up as an expected failure; I don't expect it to fail, and I would rather take the feature out if we can't support it.
Also, I had stopped maintaining trunk a long time ago, when I incorrectly understood that we were going to restart from 1.34.x for the next release, so I'm not 100% confident that my work on 1.34 has all been merged to the trunk for any of my libs. Not moving tests over could hide a feature removal, so I need to look at that for all my libs, not just Python.
Understood.
* For release criteria compilers, fix or markup all failures caused by your library's code. Fix or markup failures caused by your library's code for other compilers according to your own judgment.
* For release criteria compilers show failures you think are caused by some other library's code, or by test configuration problems, post list notifications directed at the library or tool causing the problem. For other compilers, do the same if you wish.
* For testing on the trunk to be a reliable indicator of release stability, prerequisite libraries on the trunk must be ready for release. If the trunk for your library isn't going to be ready in time for this release, please make a branch of the trunk with your library's name, and "merge" the trunk for your library so it is identical to 1.34.1.
Well, I'll certainly need a few more days than "until friday" if Boost.Python is going to be ready for this release.
That Friday date will have to be deferred, although I'm still planning to issue a progress report on Friday. With the tarball testers still broken, we just aren't making the progress hoped for.
Good, well there's a chance, then.
Do you want me to replace the trunk with 1.34.1?
That's up to you. You can also simply ask that Boost.Python trunk not be merged into the release, thus skipping all Boost.Python updates for 1.35.0.
You may not be worried about it, but I am not willing for my own libraries to differ substantially in the long term between the trunk and the release branch. If I have to tell you not to do the merge, I'm also going to roll the broken parts out of the trunk.
We seem to be testing some compilers for 1.35 that we weren't testing for 1.34.1, so I don't have any confidence that it will actually fix the failures we're seeing.
Testing continues to be a serious problem. Intellectually I knew that because of Thomas Witt's experiences, but now that I'm the one having to cope with it, our testing unreliability has really hit home.
Heh, enjoy ;-) -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
on Wed Oct 17 2007, David Abrahams <dave-AT-boost-consulting.com> wrote:
Please keep pestering him or markup the test as an expected failure (unless you consider it a showstopper).
So far he hasn't responded, which worries me a little.
I take it back; I missed his response. He's working on the problem. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
on Tue Oct 16 2007, David Abrahams <dave-AT-boost-consulting.com> wrote:
* The import_ test failure. That's Stefan Seefeld's baby and I've asked him to look into it.
The cause of this problem is fully explained in http://www.thescripts.com/forum/thread619890.html and hopefully, based on the info there, Stefan can come up with a solution. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
David Abrahams wrote:
on Tue Oct 16 2007, David Abrahams <dave-AT-boost-consulting.com> wrote:
* The import_ test failure. That's Stefan Seefeld's baby and I've asked him to look into it.
The cause of this problem is fully explained in http://www.thescripts.com/forum/thread619890.html and hopefully, based on the info there, Stefan can come up with a solution.
That doesn't explain why there were no failures prior to the 1.34 release. Are the current failures all on newly added platforms ? What is different now from before 1.34 ? Thanks, Stefan -- ...ich hab' noch einen Koffer in Berlin...
Stefan Seefeld wrote:
David Abrahams wrote:
on Tue Oct 16 2007, David Abrahams <dave-AT-boost-consulting.com> wrote:
* The import_ test failure. That's Stefan Seefeld's baby and I've asked him to look into it. The cause of this problem is fully explained in http://www.thescripts.com/forum/thread619890.html and hopefully, based on the info there, Stefan can come up with a solution.
That doesn't explain why there were no failures prior to the 1.34 release. Are the current failures all on newly added platforms ? What is different now from before 1.34 ?
It still works on my test platform (COMSOFT), I'm using python 2.4.1. Probably the python version used by the regression test runners have changed? Markus
Markus Schöpflin wrote:
Stefan Seefeld wrote:
That doesn't explain why there were no failures prior to the 1.34 release. Are the current failures all on newly added platforms ? What is different now from before 1.34 ?
It still works on my test platform (COMSOFT), I'm using python 2.4.1. Probably the python version used by the regression test runners have changed?
That's entirely possible (I read that Python's handling of default search paths has changed on Windows with version 2.5). This brings up a point I have been making for a long time: Can the testing / regression harness be fixed to report more parameters that affect the development / runtime environment ? In this particular case: the python version is certainly a critical piece of information, but it doesn't appear to be listed in the platform description. Thanks, Stefan -- ...ich hab' noch einen Koffer in Berlin...
Stefan Seefeld wrote:
Markus Schoepflin wrote:
Stefan Seefeld wrote: Probably the python version used by the regression test runners have changed?
That's entirely possible (I read that Python's handling of default search paths has changed on Windows with version 2.5).
The results on HP-UX are consistent with the theory that import_ test may be affected by Python version: the test passes on a machine with Python 2.5 and fails on a machine with Python 2.3. However, the version of Python is not the only difference between the two systems: the testing on machine with Python 2.5 is done with aCC while testing on machine with Python 2.3 is done with gcc. So, it is possible, that version of Python is not the only factor (if it is a factor at all, of course).
Can the testing / regression harness be fixed to report more parameters that affect the development / runtime environment ? In this particular case: the python version is certainly a critical piece of information, but it doesn't appear to be listed in the platform description.
I list it in comment.html. Thanks, Boris ----- Original Message ----- From: "Stefan Seefeld" <seefeld@sympatico.ca> To: <boost@lists.boost.org> Sent: Thursday, October 25, 2007 9:02 AM Subject: Re: [boost] [1.35.0] Developer preparation Markus Schöpflin wrote:
Stefan Seefeld wrote:
That doesn't explain why there were no failures prior to the 1.34 release. Are the current failures all on newly added platforms ? What is different now from before 1.34 ?
It still works on my test platform (COMSOFT), I'm using python 2.4.1. Probably the python version used by the regression test runners have changed?
That's entirely possible (I read that Python's handling of default search paths has changed on Windows with version 2.5). This brings up a point I have been making for a long time: Can the testing / regression harness be fixed to report more parameters that affect the development / runtime environment ? In this particular case: the python version is certainly a critical piece of information, but it doesn't appear to be listed in the platform description. Thanks, Stefan -- ...ich hab' noch einen Koffer in Berlin... _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Stefan Seefeld wrote:
Markus Schöpflin wrote:
Stefan Seefeld wrote:
That doesn't explain why there were no failures prior to the 1.34 release. Are the current failures all on newly added platforms ? What is different now from before 1.34 ? It still works on my test platform (COMSOFT), I'm using python 2.4.1. Probably the python version used by the regression test runners have changed?
That's entirely possible (I read that Python's handling of default search paths has changed on Windows with version 2.5).
This brings up a point I have been making for a long time:
Can the testing / regression harness be fixed to report more parameters that affect the development / runtime environment ? In this particular case: the python version is certainly a critical piece of information, but it doesn't appear to be listed in the platform description.
Another possibility is to write something like config_info, except for Python, and always display the results. For sample config_info output, see http://beta.boost.org/development/tests/trunk/developer/output/Caleb%20Epste... --Beman
on Wed Oct 31 2007, Beman Dawes <bdawes-AT-acm.org> wrote:
Stefan Seefeld wrote:
Markus Schöpflin wrote:
Stefan Seefeld wrote:
That doesn't explain why there were no failures prior to the 1.34 release. Are the current failures all on newly added platforms ? What is different now from before 1.34 ? It still works on my test platform (COMSOFT), I'm using python 2.4.1. Probably the python version used by the regression test runners have changed?
That's entirely possible (I read that Python's handling of default search paths has changed on Windows with version 2.5).
This brings up a point I have been making for a long time:
Can the testing / regression harness be fixed to report more parameters that affect the development / runtime environment ? In this particular case: the python version is certainly a critical piece of information, but it doesn't appear to be listed in the platform description.
Get the output from passing --debug-configuration when you invoke bjam. That tells everything one needs to know. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
Beman Dawes wrote:
* For release criteria compilers, fix or markup all failures caused by your library's code.
Is there somewhere a list of compilers that are expected to be tested? Which is the set of release criteria compilers? Would someone please be so kind and give me a pointer? Roland aka speedsnail
participants (8)
-
Beman Dawes -
Boris Gubenko -
David Abrahams -
Joaquín Mª López Muñoz -
Markus Schöpflin -
Rene Rivera -
Roland Schwarz -
Stefan Seefeld