harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sergey Soldatov" <sergey.solda...@gmail.com>
Subject Re: [drlvm] IPF functionality
Date Fri, 13 Oct 2006 10:50:24 GMT
If something can break IPF build it will break it during the merge. And in
this case it will take much more efforts and time to find the reason why the
build is broken. IMHO the main reason to make a separate branch is an
absolutely new implementation which will replace an existing one and this is
not our case.



On 10/13/06, Slava Shakin <vyacheslav.p.shakin@gmail.com> wrote:
>
> 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
>
>


-- 
Sergey Soldatov
Intel Middleware Products Division

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