On 7/5/06, Salikh Zakirov <[EMAIL PROTECTED]> wrote:

Mark Hindess wrote:
>  Salikh Zakirov wrote:
>> Using the fixed classlib snapshot will remove one factor
>> of uncertainty, and will make the DRLVM behaviour more reproducible.
>
> -1
>
> Doing this will hide issues that appear when changes to classlib breaks
> drlvm.  At this stage in the project, I'd rather have such issues be as
> visible as possible.  Such breakages should be relatively easy to fix
> and any drlvm developer should be capable of rolling back classlib svn
> until things are fixed if they get impatient.
>
> I don't see how it significantly affects reproducibility since it is
> trivial to check/record the versions of classlib and drlvm svn when an
> error occurs?

I agree that recording revision numbers of both classlib and drlvm will be
sufficient to reproduce the problem.

The hard part is finding the "good" ones when the latest revisions
do not work, in a case when someone wants to work on something different
than fixing the latest breakages.

I think that the reasonable compromise is to have both capabilities in the
build system (build with classlib snapshot or with latest checkout), and
leave it up to contributors to decide which way to use.




If DRLVM will be built with the class library snapshot we should be sure it
doesn't already contain the breakages.

It means the responsible person for the class library snapshot should run
the VM tests at least. IMO this will complicate

the build process due to the possible test failures because it's not clear
on this stage where a cause of error is.



Therefore I'd prefer to build from scratch using the recent sources. In the
case if any problems happen

we can take any other revision either class library or DRLVM sources and
re-build them if there are any doubts.

In any case you need to take the latest version and to check it when you are
finally going to commit your changes.

Thanks,
Vladimir.


---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Reply via email to