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.
Mikhail Fursov wrote:
Rana,
I support the first item: to have a separate branch for IPF with periodical
merges to the trunk. Do tests only on merge.
IMO it will simplify the startup for IPF contributors.
Once IPF is ready to run apps as our IA32 version does it will be the time
to move IPF into the trunk.
+ Are there any volunteers to support IPF? Once somebody is interested I
will be glad to help with JIT issues.
On 10/13/06, Rana Dasgupta <[EMAIL PROTECTED]> wrote:
Hi,
There is incomplete support for IPF platforms in the DRLVM codebase, as
many may have seen. It would be nice to complete it. There are a
couple of
issues on how to start this. IPF specific changes are likely to be quite
significant, including changes in the JIT, garbage collector(s),
exception
handling model and other core VM areas, as well as IPF functionality and
performance specific tests. Given the invasive nature of these
changes, it
seems to me that we could:
1. Create a seperate branch in svn and do all IPF work there. JIRA
submissions could be clearly marked [IPF]. Since most committers may not
have access to IPF paltforms ( a safe guess :-) ) right now, they could
help
by just applying the patches and committing the IPF submissions into the
branch( without testing, but certainly code review comments and IPF
verification, if possible are welcome ). It would be the responsibility
of
the few IPF code contributors to keep their branch tested and stable.
This
means some additional work for the committers, but worse..at some point
when
the IPF port is completed, if we want to merge the code back into the
trunk,
that will not be a small task.
2. Not create a seperate branch. Committers ( at least those without
access
to IPF ) could verify on their favorite IA32 or EM64T platform before
committing the IPF related changes also into trunk. This way, we are not
defering the merge problem, but overall everyone is impacted because
there
will be more commits into the trunk, more conflicts, and things will be
somewhat slower. This is somewhat the model that we are following with
EM64T specific submissions now, but IPF specific changes and submissions
are
expected to be of higher volume.
3. Follow 1, but always keep IPF as a special platform on a seperate
branch. Never merge back. As IPF functionality is more complete and
committers get access to IPF machines, we just start testing more
rigorously before commiting IPF code and also start running automated
tests
( whatever we are doing in the main branch ). IPF distributions can be
rolled out of its own branch.
However we do it could be a model for porting to other future platforms (
let's say Mac ) as well. Comments or other ideas?
Thanks,
Rana
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
