Omr: Request OMR move from eclipse GitHub organization to eclipse-omr organziation

[charliegracie]

I would like to propose that the Eclipse OMR project request to be moved from the Eclipse organization into its own eclipse-omr organization.

Pros:

1. The OMR project uses Travis and AppVeyor to complete some of the CI testing. These resources are shared between all projects in an organization. This means that sometimes PR testing waits for up to 24 hours to complete testing. If a change is required that could mean another 24 hours.
   1.1 Improved testing speed for OMR
   1.1.1 Travis provides 5 concurrent jobs per organization regularly the job queue for the Eclipse organization is > 200 jobs
   1.1.1.1 The OMR testing takes ~7mins per platform X 6 platforms for each PR that is opened (and every time a new change is pushed) and again when the PR is merged.
   1.1.2 AppVeyor provides a small number of concurrent builds per organization as well.
   1.2 Since the OMR project builds consume significantly more resources than most other Eclipse projects this will be a good community move.

1. GitHub provides automatic forwarding for projects that move so the transition would be easy. As our documentation gets updated users would naturally migrate to the new URL but the old one should continue to work.

2. This may provide the OMR project with the ability to host down stream consumers of the project in the OMR namespace on GitHub. This may be a huge benefit to getting exposure for OMR. I am not sure about how the project would go about this but it is something I think we should consider in the future.

3. Other OMR repositories will no longer be required to be prefixed with omr.. An example would be the github.com/eclipse/omr.website repo as it would just become github.com/eclise-omr/website.

4. Since the OMR project would be in it's own organization we could likely create a read-only team for active contributors. Users in this team could be assigned Issues and PR reviews directly. I feel like this would be a great way recognize active contributors and it could be a first step to becoming a committer. We could use this same list to whitelist users for launching jenkins builds as well.

Cons:

1. We will be moving the location on GitHub which may cause build, testing, cloning, PR issues that I have not predicted.

[charliegracie]

I would like feedback from all of the committers and I would appreciate feedback from everyone else in the community as well. @0xdaryl , @mstoodle , @fjeremic , @vijaysun-omr , @youngar , @jduimovich

[youngar]

Overall I think that this move will help both OMR and other Eclipse projects. Point 2 alleviates my main fears of changing the repo address. Will the organization be managed by Eclipse?

[fjeremic]

Personally I'm not a big fan of changing the URL as it decouples us from Eclipse and "looks" like a satellite project not part of the organization. It seems to be a workaround for an issue which is really with Travis CI limiting resources to an organization rather than per repo. We seem to rely on Travis CI only for macOS testing. This is the only platform we're missing from the Eclipse OMR genie builds. Have we explored any "beefier" alternatives?

I know @dnakamura has already experimented with Azure Pipelines which says:

Get cloud-hosted pipelines for Linux, macOS, and Windows with unlimited minutes and 10 free parallel jobs for open source

Here is an example (all credits to @dnakamura - thanks!):
https://dev.azure.com/devinn/OMR/_build/results?buildId=13&view=ms.vss-test-web.test-result-details

Moving to a different URL and organization seems like an overkill for a problem which can be solved in other ways.

_Edit:_

Alternatively what would it take to get macOS on our Eclipse OMR genie CI builds? Is this within the realm of possibilities? Personally I wouldn't mind if we decouple ourselves from Travis and AppVeyor and rely on Eclipse testing given our builds take ~7 min a piece and we can fully control which builds to launch and when to launch them.

[dnakamura]

The azure limitation may also be per-org rather than per-repo so we would potentially hit the same issue later if more eclipse projects start using azure

[charliegracie]

I am not sure how moving into our own organization makes it look like the OMR project is not part of the Eclipse organization. The OMR project would not be the only project like this and it still has "Eclipse" in the organization name and the original github.com/eclipse/omr will forward directly to github.com/eclise-omr/omr.

Reducing the pressure on the public CIs is only 1 of a few reasons why I am recommending we move the OMR project into it's own repo.

[charliegracie]

Here is a Bugzilla discussing the ability to have a top-level organization:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=488119

Some of the text in this comment is quite appealing to me:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=488119#c19

I am going to look into the EE4J organization to see if I can get more details.

[fjeremic]

The OMR project would not be the only project like this and it still has "Eclipse" in the organization name and the original github.com/eclipse/omr will forward directly to github.com/eclise-omr/omr.

Ah right, forgot about that.

Here is a Bugzilla discussing the ability to have a top-level organization:
bugs.eclipse.org/bugs/show_bug.cgi?id=488119

Some interesting points in there. Didn't know there was precedent for other teams doing this. The _github.com/eclise-omr/website_ mentioned in your point 4. is definitely an advantage then.

The azure limitation may also be per-org rather than per-repo so we would potentially hit the same issue later if more eclipse projects start using azure

Good point. And even if not we have no control over whether this will be changed in the future. Still an interesting option for additional testing if we need it. If our builds are short (which they are ~7min.) I see no reason why we shouldn't scrap AppVeyor and just test on Azure given it can do Windows, macOS, and Linux.

Having read over the above I agree that we should move forward with the proposal. @charliegracie added my +1 to the description.

[kaylangan]

I'm a Program Manager on Azure Pipelines.

The 10 parallel pipelines is per Azure DevOps org (which is different from a GitHub org). You can link a GitHub organization to multiple Azure DevOps orgs. So in the event another Eclipse project chooses to use Azure DevOps, they can create their own Azure DevOps org and get their own 10 pipelines. We're also happy to work with you if you think you might need more resources!

[vijaysun-omr]

Based on the large list of advantages and the above discussion, it looks like having a separate github organization might be the way to go. Are there any actual advantages of being part of the Eclipse organization that we would be losing ? If so, that's to be added to the list of Cons and discussed, but if there are no such advantages, then I think the productivity benefits seem to be worth making the change to me.

[AdamBrousseau]

Will we have Admin access on the org and/or repositories?

[mstoodle]

I like #3 on Charlie's list, especially given that we have been the ones creating a lot of the porting projects that use OMR. Moving those repositories into an OMR organization would have the advantage that the forks from the main repositories would point more obviously at the OMR project itself. I also think it's a way to build a true ecosystem around the porting projects. Presumably we have control over the committers within an individual repository, so it again gives us more flexibility in growing roles at the project for people who are specifically focused on one or two languages.

I think the main cons will be that we'll now have to manage some things that the Eclipse Foundation team is managing for us as well as the list of one-off "separation" pains Charlie mentioned. But the list of advantages for an ecosystem project like ours makes the decision pretty clear to me. I've added my +1. Thanks for bringing this proposal forward, @charliegracie .

[DanHeidinga]

I like #3 on Charlie's list, especially given that we have been the ones creating a lot of the porting projects that use OMR. Moving those repositories into an OMR organization would have the advantage that the forks from the main repositories would point more obviously at the OMR project itself.

@mstoodle This sounds really good to me as well but I think there may be some road blocks on that path as the ports (typically) aren't EPL licensed.

The https://bugs.eclipse.org/bugs/show_bug.cgi?id=488119 also mentions the idea of a "labs" organization that could contain projects that aren't part of the foundation, though I'm not sure how that would work.

I'd suggest confirming the ecosystem / porting projects plans work with the IP policy with the Foundation.

[mstoodle]

That's a good point @DanHeidinga and thanks for pointing out that bug. I guess I was assuming that such a github repository wouldn't be very different than us bringing in another project via a CQ: we would just house it in a separate repo rather than in (say) a submodule or pulling the source in directly. And none of those port repositories would "ship" with Eclipse OMR which makes the IP question a different one.

[mstoodle]

hm, but we may want to create binaries of the ports, so then they do constitute a binary release.....interesting...

[aarongraham9]

We seem to rely on Travis CI only for macOS testing. This is the only platform we're missing from the Eclipse OMR genie builds.

@fjeremic As a note, I'd add that currently, we are relying on the Travis CI builds for AArch64 (ARM 64-Bit) and ARM (32-Bit) testing.

@charliegracie, @0xdaryl and I have been working on setting up some hardware for AArch64 and ARM testing at @CAS-Atlantic that can be incorporated into the Eclipse OMR genie builds. Within the next couple of weeks we should have some x86_64, ppc64 and MacOS hardware up and running; but it is likely going to be some time before we get aarch64 and arm hardware up and running in the genie/Jenkins builds.

I'd also like to add in my support for this idea; for what it's worth. :-)

[fjeremic]

@fjeremic As a note, I'd add that currently, we are relying on the Travis CI builds for AArch64 (ARM 64-Bit) and ARM (32-Bit) testing.

Right. Good point!

@charliegracie I see a lot of thumbs up and no real objections left. I would say we set a deadline for further comments to sometime next week and move forward with the proposal?