I have done "make run-test" on critical and some random assemblies but none
of them showed differences between 48518 and 48520. When you informed me
about regressions I did a "make run-test" comparsion on corlib again but I
did not get any differences.
It was a copy-n-paste error. I fixed it in rev 48556.
Thanks for the fix. I think this error should occur in corlib tests but I
did not see it. I had more errors in results than on
http://mono.ximian.com/tests/displayTestResults.php so this may be the cause
because the relevant tests may failed in the unpatched version as well. And
I am sure that the tests were executed on Mono and I used the right
revisions.
BTW are there any other unfixed or fixed regressions?
Thanks for the explanations. I already knew most of these things but I have
never used buildbot. How can I use it? Are there any documentation about it?
The only think I know is that it is available on
http://mono.ximian.com:8008/.
Kornél
----- Original Message -----
From: "Sebastien Pouliot" <[EMAIL PROTECTED]>
To: "Kornél Pál" <[EMAIL PROTECTED]>
Cc: <[email protected]>
Sent: Friday, August 19, 2005 7:07 PM
Subject: Re: [Mono-dev] corlib version and #if symbol questions
Hello Kornel,
On Fri, 2005-19-08 at 17:59 +0200, Kornél Pál wrote:
I did not experience regressions. Note that I was unable to do make -k
check
because it failed on r48518 as well (maybe because of my build
environment;
cygwin) but I have done make run-test on critical assemblies and compared
the results. There were no change in passed and failed test count and
test
numbers.
Try doing "svn up -r 48518" then a "make run-test" under corlib.
After that try the same thing but for revision 45819.
If you're using cygwin then make sure that the unit tests are executed
using Mono and not the MS runtime.
I have little experience in regression tracking. If you are more
experienced
I would appreciate if you could give me some hints and commands that help
regression tracking.
It's simple, just make sure you run "make run-test" for each assembly
that your patch will change. If there are errors then make sure that the
errors were already existing prior to committing.
Note that this is not perfect as a change in assembly X could result in
problems in assembly Y (which would means that assembly X is missing
important unit tests) but it will catch most problems.
Finally if, for any reason, you are unable to test the changes please
say so when sending the patch for review on the mailing-list. That way
someone else can test it before it gets committed (and yes that would
probably requires more time to approve the patch).
After committing a large patch (or a patch that can influence lots of
thing, e.g. many patches in corlib) you should also start buildbot
(which sadly seems offline at the moment). This will give you extra
insurance ;-)
I have never tested or compiled r48519 because it is the update of mcs
tree
only. r48520 is the update of mono tree. If you use r48519 it may result
in
errors. I checked out mcs and mono separatedly and I was unable to make
svn
to commit them in a single command. If you know the solution please let
me
know.
It isn't a "in between commits" bug. The failures were still there this
morning (at revision 48555). I had to (a) go back to revision 48518 to
return to a normal (no failure) status and (b) try 48519 to ensure it
was this exact patch that caused the problem.
Unless I mistyped something the version patch should not have any effects
that result in regressions because I did not (wanted to) modify code
behaviour.
It was a copy-n-paste error. I fixed it in rev 48556.
Could you please send me (or to the list if you want) some test results
pointing out the regressions?
Daily tests results
http://mono.ximian.com/tests/displayTestResults.php
--
Sebastien
_______________________________________________
Mono-devel-list mailing list
[email protected]
http://lists.ximian.com/mailman/listinfo/mono-devel-list
_______________________________________________
Mono-devel-list mailing list
[email protected]
http://lists.ximian.com/mailman/listinfo/mono-devel-list
