harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Slava Shakin" <vyacheslav.p.sha...@gmail.com>
Subject Re: [drlvm] IPF functionality
Date Fri, 13 Oct 2006 09:34:02 GMT
Geir,

The following scenario illustrates my point (just in case):
Let's assume that IPF porting group managed to run "hello world" on IPF in 
the main trunk. The next goal might be a bit more sophisticated workload 
(like Eclipse). For fast progress towards that goal the IPF porting group 
will not want any regressions wrt their results in the branch they work 
with. But patches from other (non-IPF) contributors are not supposed to be 
tested on IPF and can easily break even building on that platform.

This is just one more argument for doing IPF porting in a separate branch, 
at least since some point.

I admit that maintaining quality and checking for regressions on new 
platforms is a separate big problem but I believe we could try to avoid it 
during "incubation" of new platforms.

Overall I agree we could wait with branch creation until real problems 
appear.

-- 
Slava Shakin, Intel Middleware Products Division

"Geir Magnusson Jr." <geir@pobox.com> wrote in message 
news:452F56B2.6030802@pobox.com...
>
>
> Slava Shakin wrote:
>> Hi,
>>
>> I have an opposite concern: will the main trunk guarantee it always 
>> builds and works on IPF.
>
> Clearly not.  It doesn't now.
>
>> IMO this will soon become critical for the IPF porting effort but will 
>> imply passing certain pre-commit tests on IPF for any changes which 
>> potentially affect working on this platform. Which relates to another 
>> discussion about the list platforms to test each commit on.
>
> Sure - but the model now is that some small group of contributors will be 
> working on IPF support, seemingly independently of the rest.  I'd think 
> they could ensure that what is offered as patches at least compiles :)
>
>>
>> The first stage of IPF porting effort will probably be porting classlibs 
>> and running things in VM interpreter mode. Perhaps, it makes sense to 
>> keep everything in the main trunk during this period. But later we will 
>> likely want a separate branch.
>>
>
> ---------------------------------------------------------------------
> 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
>
> 




---------------------------------------------------------------------
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


Mime
View raw message