Hi, I have an opposite concern: will the main trunk guarantee it always builds and works on IPF. 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.
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. -- Slava Shakin, Intel Middleware Products Division "Mikhail Fursov" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > On 10/13/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: > >> It's harmless now...given it's not interfering with the other stuff, >> what's the problem? > > > Geir, > your proposal "to solve a problem only when you feel that it is a > problem" > sounds reasonable. > Right now IPF code is harmless and we can try to start with the trunk. > Once > we feel that IPF code needs more freedom or our commiters are too > overloaded > to check IPF patches on IA32 we can create a branch for IPF. I'm OK with > it. > > I proposed to use separate branch initially only because I know how it > works. Do-everything-in-the-trunk is a new technique to me :) > > > -- > Mikhail Fursov > --------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
