On 8/25/05, Rick Hillegas <[EMAIL PROTECTED]> wrote:
This situation could potentially improve as we migrate tests into an
assertion-based framework. It's an issue to keep in mind as we write
assertions.
This raises another interesting issue:
o What is a reasonable minimum test barrier for committers to apply when
approving a patch?
Is it enough for the committer to say: "Derbyall runs cleanly under
jdk1.4 on my machine." Should a scrupulous committer also run Derbyall
on J2ME? At this point there are 8+ vms where people expect the tests to
run. And there may be a couple dozen operating systems. Clearly we have
to draw some line between the committer's responsibility and the
responsibility of the platform users. What's the gold standard for
committing patches?
I'm a bit unclear on our process for arresting test drift across useful
platforms. Can someone point me at a description of what we do today?
Thanks,
-Rick
Øystein Grøvlen wrote:
>>>>>>"KAH" == Knut Anders Hatlen < [EMAIL PROTECTED]> writes:
>>>>>>
>>>>>>
>
> KAH> Deepa Remesh <[EMAIL PROTECTED]> writes:
> >> On 8/24/05, Knut Anders Hatlen < [EMAIL PROTECTED]> wrote:
> KAH> [...]
> >>> Is that jvm available for download somewhere?
> >>
> >> Here is the link: http://www-306.ibm.com/software/wireless/wctme_fam/
> >>
> >>> I am working on a patch
> >>> for DERBY-504 and DERBY-519, and I have to modify some tests which also
> >>> run under j9_13 and j9_22. At least, the tests have .out files in
> >>> subdirectories called j9_13 and j9_22. Should I update the tests for
> >>> those platforms too?
> >>
> >> As I understand, all the master(.out) files for a test need to be
> >> modified. (unless for some reason, the test has been excluded to run
> >> with the specific jvm)
>
> KAH> Thanks, Deepa! I'll download it and try to get the tests running.
>
>In my opinion, it seems to be requiring a bit much, if a developer is
>expected to download special VMs in order to be able to modify a
>general test. Would it not be better to do this in cooperation with
>someone who regularly runs on this VM?
>
Here is my 2 cents on it - falling nicely in with all the talk about itches etc. :-) and based on *what I would do*.
If someone likes to support a certain jvm that is not 'standard', then it is up to that person to ensure all possible canons are covered & run with that jvm - *unless* the running of the test with another jvm actually exposes a bug in derby.
I'd expect *everyone* to at *least* run with jdk1.4.2, and if there is a likelyhood of a difference in behavior, jdk1.5 by Sun.
I'd expect a fix if someone running with another jvm actually exposes a bug in derby.
I would expect someone who's updating a master file that has already canons for other supported jvms to at least signal this to the list, and if possible, modify that canon wih a manual effort (i.e. without running the test with that jvm).
Finally, more high-level goal, we should accomodate support for other jvms in the tests and harness themselves, and avoid the need for canons.
Does that sound reasonable?
Myrna
