Hi Wayne,
Your confidence may be misplaced :( . Sorry to disappoint!
Let me first be clear: this "fork" is not a Fork in the traditional
undesirable sense of the word. OpenJ9 will NOT be doing extensive OMR
development solely for the benefit of OpenJ9. This "fork" is used to
smooth the integration story between OMR and OpenJ9:
1) to provide a way for OpenJ9 to test and soak Java inspired OMR
changes in a Java environment (since there is currently no way to run Java
tests at the language agnostic OMR project)
2) so that OpenJ9 can tag even OMR commits in ways relevant to
OpenJ9 (and actually OpenJDK) rather than in ways only relevant to OMR
3) to provide a way for the OpenJ9 to cherry-pick fixes for Java
test problems without necessarily taking new OMR feature commits, since it
can take a while to do a full round of JVM release testing
Tongue twister thought experiment: how does OpenJ9 fix a
Java test problem it inherits from OMR if that fix isn't or cannot be made
available in the OMR release that the OpenJ9 release took?
(side grumble: I hate having to defend a position starting
from the premise that OMR could break one of its consumers *sigh*)
Also, due to the "special" nature of these two projects and their current
state:
4) we also need to continue to make co-dependent (e.g.
refactoring) changes across OMR and OpenJ9 (as we continue to augment OMR
components and refine the OMR API). It will be easier to manage these
kinds of changes at OpenJ9 if we can build and test them "locally" in an
OpenJ9-specific repository while, at the same time, working with the OMR
community on the proper OMR side of the implementation.
Don't get me wrong though, we don't want #4 to be the natural order of
things. As we better isolate OpenJ9 from Eclipse OMR and get closer to the
point where an Eclipse OMR "release" makes more sense, this kind of thing
will become less frequent and the OpenJ9 pressure will *always* be on
minimizing the difference between our local "fork" and the proper OMR
repository, but I still think #1-3 will be important for OpenJ9 and OMR to
operate successfully. Other projects that use Eclipse OMR right now are
also using this kind of model, but tend to maintain very few (in many
cases, no) additional changes, which is the preferred model. OpenJ9,
however, has a lot more touch points, significantly more testing, and a
larger and more active community than these other projects (hopefully
that's a point in time statement).
I don't think it's as simple as coordinating OpenJ9's release schedule to
the release schedule for OMR, especially since a lot of OpenJ9's
activities will be driven by another large community we don't control
(OpenJDK). We may end up with a coordinated schedule eventually anyway,
but I'm not sure it's a great precedent to set for OMR, a project that
aims to be integrated with many other large and complicated projects with
their own (as a group, uncoordinated) release schedules.
I guess OMR could do daily releases too, but even that wouldn't address
#1-#3.
Mark Stoodley
8200 Warden Avenue
Senior Software Developer
Markham, L6G 1C7
IBM Runtime Technologies
Canada
Phone:
+1-905-413-5831
e-mail:
[email protected]
We cannot solve our problems with the same thinking we used when we
created them - Albert Einstein
From: Wayne Beaton <[email protected]>
To: Discussions for new Eclipse projects <[email protected]>
Date: 2017/07/31 09:32 PM
Subject: Re: [incubation] continuous integration of another
Eclipseproject...
Sent by: [email protected]
It pains me to disagree with Gunnar in a public forum :-)
CQs are not required in theory or in practice in order to consume the
artifacts of another Eclipse project. We would require a CQ if you chose
to fork the code of another Eclipse project, but I'd probably spend a lot
of time trying to talk you out of creating a fork (thereby making it far
more trouble than it's worth). I'm confident that you're not talking about
forking anything.
OMR doesn't produces binary builds AFAIK. It is the nature of the project
that all it produces is source. The Eclipse Development Process tends to
assume that projects produce some sort of binary output based on our
source code, so we're in a bit of a grey area. Normally, one project can
only include officially released (via release review) bits from another
Eclipse project.
OpenJ9 can just pull from OMR Git repositories as part of its own build.
No CQs or explicit tracking will be required.
Given my assumption that OMR doesn't produce any sort of typical build, I
believe that the correct course of action is to coordinate releases (and
release reviews) for OMR and OpenJ9. For OMR, the release event may just
be a tag in the repository.
Best effort should be taken to provide some sort of pointer back to the
OMR project in the bits that are pulled from that project, so that, e.g. a
consumer can have a reasonable chance of finding their way back to the
source. This might simply take the form of a sentence that describes the
relationship in the OpenJ9 project's contribution guide.
I hope that at least some of this makes sense.
Wayne
On Fri, Jul 28, 2017 at 4:45 AM, Gunnar Wagenknecht <
[email protected]> wrote:
> If you consume (and redistribute) any Eclipse project, you inherit their
dependencies. Thus, there is no need to file CQs again.However, in theory
you need a CQ for the Eclipse OMR dependencies.
Re-reading my own text breaks my head. :)
Clarification: no need to file CQs for all of OMR's dependencies. In
theory you need just one CQ to the Eclipse OMR project itself. However,
the latter hasn't really been enforced across the board.
-Gunnar
_______________________________________________
incubation mailing list
[email protected]
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/incubation
--
Wayne Beaton
Director of Open Source Projects
The Eclipse Foundation_______________________________________________
incubation mailing list
[email protected]
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/incubation
_______________________________________________
incubation mailing list
[email protected]
To change your delivery options, retrieve your password, or unsubscribe from
this list, visit
https://dev.eclipse.org/mailman/listinfo/incubation
