On Sep 26, 2006, at 12:41 PM, Tim Ellison wrote:
Geir Magnusson Jr. wrote:
Simone has no problem with us doing a "gentle fork" (in his words) of
the code to build on. By this, we are simply taking a snapshot of
the
project codebase, and building upon it. This is not a hostile,
anti-community act, but simply a recognition that it's useful code
for
us, we want to keep building on the code base, but need to make
modifications for java SE 5 that are incompatible with the needs
of the
pre-Java 5 users that the MX4J project support.
I read this as an indication that MX4J has no interest in pursuing
a 5.0
compatible implementation?
None - there'd be no point.
Likewise we have no interest in distributing
a 1.4 version.
Well, I have no burning interest, but if it meant that we could move
the MX4J community here, I'd have no problem making the "legacy"
builds available for those still using pre Java 5.
We are not becoming "MX4J", although I'd like to do whatever we can
to leave that door open - how we can structure the code in SVN so
that in the future, if Simone has some time and wishes to move his
user base over here, we can easily welcome that community.
Anyway, that's the long and the short of it.
if people like this, I suggest that we put in "standard" SVN
repository
in the same way we do java.util.concurrent. Given the history of the
code, I'm very doubtful we can find full paperwork to get into
"enhanced". The difference is that we'd be modifying it (although if
possible, it would be nice to have a clear boundary between the "old
mx4j code" and our new enhancements, in the event that the mx4j
community comes over...)
Presumably all the enhancements that are made in the Harmony SVN tree
are 'our new enhancements', so identifying them will not be a problem.
Putting the code into standard sounds like the right answer. I assume
that in this scenario, and unlike concurrent, we do not attempt to
keep
the two sites in sync.
Yes, on the last bit, and I think so on everything else - this is a
first for us, so I expect we make a few laps around this particular
rabbit hole in how to work with this. I think that we'll have to
make changes in the "standard" codebase - this would be ours, hence
the honesty in labeling it a fork.
geir
Regards,
Tim
--
Tim Ellison ([EMAIL PROTECTED])
IBM Java technology centre, UK.
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
