Re: [incubation] continuous integration of another Eclipseproject...

["Mark Stoodley" <mstoodle@xxxxxxxxxx>]

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:	mstoodle@xxxxxxxxxx
We cannot solve our problems with the same thinking we used when we created them - Albert Einstein

From:      
 Wayne Beaton <wayne.beaton@xxxxxxxxxxxxxxxxxxxxxx>
To:      
 Discussions for new
Eclipse projects <incubation@xxxxxxxxxxx>
Date:      
 2017/07/31 09:32 PM
Subject:    
   Re: [incubation]
continuous integration of another Eclipseproject...
Sent by:    
   incubation-bounces@xxxxxxxxxxx

---

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 <gunnar@xxxxxxxxxxxxxxx>
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
incubation@xxxxxxxxxxx
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
incubation@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/incubation