On 6/27/07, Tim Ellison wrote:
Stepan Mishura wrote:
> On 6/26/07, Tim Ellison wrote:
>> If you have spare cycles to do more testing then maybe you could test
>> the current candidate some more. I think that would of greater value
>> than overlapping the same tests on a new candidate that will be
>> essentially the same.
>
> I don't see any issue with overlapping tests results.
Don't get me wrong, I'm not saying it is a problem - test away!
I expect your results to be very similar.
> There is no guarantee that we'll have correct quick fix for
> StrictMath/Beans by next morning. But by next morning we'll have the
> same test results matrix (that includes 'short' test suites) for new
> snapshot(with last fixes) like we have now for r550333.
Understood. But you would expect to run the long tests on the actual
milestone too, right? AFAIK they are still running on this candidate.
> So we can say
> for sure that a new snapshot is slightly better then previous one. And
> if latter we find that fixes for StrictMath/Beans are not good we may
> declare the new shapshot as M2.
Not sure I understand what you mean by declaring M2 if the fixes are not
good?
We'll have the next milestone candidates:
1) r550333
2) with HARMONY-4285 and HARMONY-4269
3) with fixed StrictMath/Beans (in case if fixes are ready)
The second candidate is supposed to be is slightly better then
previous one(r550333). Let's test it! Also if we have fixes for
StrictMath/Beans let's create the third candidate and test it too. If
the third candidate is the best we'll promote it as M2 otherwise we'll
promote the second one.
Thanks,
Stepan.
> IMO, we can apply the same rule for testing during code freeze as do
> for commiting: "do it early and often".
oh yeah, and "be smart" :-) Keep up the good work Stepan!
Regards,
Tim
