The question came up as to whether 1.43.0 is still open for bug fixes. The answer is, yes, with permission from one of the release managers. My rationale is that there are still an uncomfortable number for test failures, and so taking a few more days to clear more failures is well worthwhile. The release is currently scheduled for next Monday, but I'm guessing release may run a few days later than that. --Beman
On 4/27/2010 12:32 PM, Beman Dawes wrote:
The question came up as to whether 1.43.0 is still open for bug fixes.
The answer is, yes, with permission from one of the release managers.
My rationale is that there are still an uncomfortable number for test failures, and so taking a few more days to clear more failures is well worthwhile.
The release is currently scheduled for next Monday, but I'm guessing release may run a few days later than that.
I'd be more comfortable if we had a list of specific regressions that needed to be fixed for 1.43 rather than just saying the number of failures is too high. Times were, the test matrix would come up with red squares for new failures compared to the last release. Do we still have that? It seems not. -- Eric Niebler BoostPro Computing http://www.boostpro.com
On 4/27/2010 5:59 PM, Eric Niebler wrote:
On 4/27/2010 12:32 PM, Beman Dawes wrote:
The question came up as to whether 1.43.0 is still open for bug fixes.
The answer is, yes, with permission from one of the release managers.
My rationale is that there are still an uncomfortable number for test failures, and so taking a few more days to clear more failures is well worthwhile.
The release is currently scheduled for next Monday, but I'm guessing release may run a few days later than that.
I'd be more comfortable if we had a list of specific regressions that needed to be fixed for 1.43 rather than just saying the number of failures is too high. Times were, the test matrix would come up with red squares for new failures compared to the last release. Do we still have that? It seems not.
We don't because it's actually a rather painful process to maintain that state... As it involves having all the testers generate a test run with the specific version and having a different post-process to generate the previous errors file which then gets checked into the repo. Hence I gave up on trying to update that. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org (msn) - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail
Rene Rivera <grafikrobot <at> gmail.com> writes:
We don't because it's actually a rather painful process to maintain that state... As it involves having all the testers generate a test run with the specific version and having a different post-process to generate the previous errors file which then gets checked into the repo. Hence I gave up on trying to update that.
What about generating a 'previous results' file from the release branch test results at the time of a release (rather than from a seperate test run)?
participants (4)
-
Beman Dawes -
Eric Niebler -
Rene Rivera -
Richard Webb