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?
