harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rana Dasgupta" <rdasg...@gmail.com>
Subject Re: [general] define pre-commit testing configs to gain the stability
Date Fri, 06 Oct 2006 19:24:05 GMT
On 10/6/06, Pavel Ozhdikhin <pavel.ozhdikhin@gmail.com> wrote:
> >If we agree on common testing configs we can make sure the Harmony
> >will be stable on at least this set of configurations. This does not
> >mean we won't fix problems on other configurations. The goal is to
> >gain and maintain general stability.
> >I propose to work out a set of configs the committers will use to
> >check patches before committing them to SVN. We can start with a few
> >configs defining the platform, OS familly and the compiler used. When
> >we are sure the Harmony is stable we can add more configurations. IMO,
> >it would be reasonable to start with 3 configurations - one
> >configuration for each supported platform, for example:
> >- Windows / IA32 / MSVS .NET 2003 / release
> >- Linux / IA32 / GCC 4.0.3 / release
> >- Linux / EM64T / GCC 4.0.3 / release
> We need to check both release and debug builds...the binaries and timing
characteristics are too different. At this immediate stage of the project, I
would suggest leaving out EM64T as part of mandatory testing( unless it is
EM64T specific functionality, eg., codegen ). Too few contributors and
committers have access to it. We are not yet at a stage where we can make
this mandatory.

 If possible all submissions should be tested( by submitters ) on all the
combinations identified . It is actually more urgent for submitters to do
this. We should stop patches by email. Also, at this point, it is an honor
system, we can't attach 6 before and after test logs to each JIRA
submission. The committer could randomly check on one or more combination,
...the more the better obviously.

 In some cases, submissions will be platform specific ( eg., very new code
like GC V5, platform specific bug fixes or a simple case of developer not
having all the machines ). I would leave these to the committers'


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message