harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Geir Magnusson Jr." <g...@pobox.com>
Subject Re: [general] define pre-commit testing configs to gain the stability
Date Mon, 09 Oct 2006 13:30:12 GMT

On Oct 9, 2006, at 8:52 AM, Mark Hindess wrote:

> On 9 October 2006 at 16:12, "Pavel Ozhdikhin"  
> <pavel.ozhdikhin@gmail.com> wrote:
>> On 10/9/06, Tim Ellison <t.p.ellison@gmail.com> wrote:
>>> Rana Dasgupta wrote:
>>>> 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 i
>> s
>>>> 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 hono
>> r
>>>> 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'
>>>> discretion.
>>> Mandating that patches are pre-tested on a wide variety of  
>>> machines is
>>> not conducive to building a broad community of contributors since  
>>> very
>>> few people have access to all the machines and configurations we are
>>> interested in.  I'd much prefer that we work optimistically and have
>>> lots of people regularly building and testing the code to get the
>>> broadest possible coverage.  We can backtrack if problems arise.
> Agreed.  Broadest possible coverage is much more important.
>> Even is a committer does't have a wide variety of machines I think we
>> can still mandate that his/her commits are checked on the right
>> configuration.
> You'd also need to mandate linker versions and assembler versions too.

Which I think we should do.  I can see no good reason for not doing  
this other than versions people port harmony too not having a given  
version of the toolset available, but that's a problem I'd love to  
have :)


> I'm a committer.  I test most patches on my ia32 thinkpad, which is
> running Debian/testing (mostly).  I've got the following compilers
> installed:
>   gcc-2.95
>   gcc-3.0
>   gcc-3.2
>   gcc-3.3
>   gcc-3.4
>   gcc-4.0
>   gcc-4.1
> It turns out that my gcc-4.0 despite belonging to a package with a
> version number of "4.0.3-3" might not be gcc-4.0.3 because "gcc -v"
> says:
>   gcc-4.0 (GCC) 4.0.4 20060507 (prerelease) (Debian 4.0.3-3)
> So I guess my 4.0.3 and, for example, Geir's on ubuntu are probably
> different.
> I don't plan to compile a new version of 4.0.3 from fresh sources (or
> install the ubuntu version or anything like that) because:
> 1) I don't think it matters that much
> 2) Next week we'd probably find a binutils problem and I'm definitely
> not changing that.
> 3) I actually think diversity is ok.  I've not really seen a huge  
> amount
> of problems with different gcc versions.  And if there are problems  
> with
> compiler incompatibilities then I want them to receive focus quickly -
> breaking is a good way to get peoples attention.  What I'd really not
> want is for problems to go unnoticed because all the committers have
> spent time setting up their machines to be identical.

Agreed,  but they should be close, I believe.


Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org

View raw message