Rana Dasgupta wrote:
I think that over time, we will start seeing IPF specific code files
appearing ... eg., quite a different jit, IPFhelpers.cpp,
IPFexception_filters.cpp, IPFnativestack.cpp, IPFprofiledrivers.cpp etc.
That is my impression of how most IPF ports go. Even in the main codebase
they will virtually be a branch. While they are architecturally quite
seperate, they are seperate enough to maybe not cause a lot of conflict.
So the question is really one of how we want to manage this, and if we want
to consider the IPF work as mainline work or secondary.
I think it's secondary from the POV of availability, where x86 is
ubiquitous, not in importance as a platform.
That is my
understanding. I am fine with Geir's choice, and his comment about it being
easier to manage one codeline makes sense. But I would request leaving this
open for some more comments from the jit guys and others before we decide.
My point is that we don't need a "decision" to get moving forward. We
can just move forward with the status quo, and if we run into a problem,
then we can decide what to do...
geir
Thanks,
Rana
On 10/12/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
>
> How about trying to do in main line for now, reserving branch until
> needed?
>
> We'd agree that committers put in the patches and test on supported
> platforms (not IPF) and those doing the IPF work test and adjust as
> necessary.
>
> That way, we at least try to keep one codeline that we know works. It
> also would "restrict" the freedom of the IPF contributions to stay
> within the bounds of the mainline code, and in the event an
architecture
> change is needed to support IPF that would affect other platforms, we
> can talk together.
>
> I volunteer to help with the IPF patches.
>
>
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
