One GitHub organization per project (for projects hosted at GitHub)

We currently have 434 repositories under https://github.com/eclipse and over 1,300 members in the organization.

We have mandated that all new projects be created in a dedicated organization for some time now, and we should begin enforcing a division of this large eclipse organization.

Using separate GitHub organizations for different projects offers several benefits:

• Clarity and separation: Each organization focuses on a singular project (or working group). This clarity makes it easier to comprehend the purpose and scope of each organization instantly.
• Branding: Each organization can establish its unique identity, logo, and description.
• Notifications: Members can manage notifications more easily on a per-organization basis.
• Avoiding repository clutter: A single organization with numerous repositories can become messy. Distributing projects across different organizations ensures each has a manageable and easily searchable number of repositories.
• Default policies and workflows: Default policies and workflows can be defined in the .github repository of each organization. This differentiation is unfeasible in the shared eclipse organization, as policies would need to cater to all hosted projects universally.
• Self-service: with a dedicated organization, a project can have self-service enabled. This captures the existing configuration as code in a separate repo (.eclipsefdn) and committers can then create PRs against this repo to change the organization/repositories configuration to fit their needs.

There are also several security advantages:

• Limit blast radius: If an attacker compromises an account or infiltrates one organization, they won't necessarily gain access to projects in other organizations. The potential damage is constrained to a single entity.
• Isolation: Mistakes or misconfigurations in one organization won't jeopardize projects in separate organizations. Moreover, permissions for GitHub apps are restricted to the specific organization they are installed in.
• Audit and monitoring: Activity is easier to audit when confined to a single organization. Detecting anomalies or suspicious behaviors might become more straightforward.

Certainly, there are instances where a GitHub organization hosts repositories for multiple projects, such as LocationTech, JakartaEE, Eclipse EE4J, or Adoptium. In such cases, there is a strong motivation to consolidate related projects within a single organization, and we do not intend to change this.

added prioritymedium ~16280 severitynormal team:infra team:releng team:security labels

changed the description

mentioned in issue #2979 (closed)

We should focus on projects that have a lot of repos, e.g.:

• Titan (62 repos )
• Keyple (34 repos)
• Microprofile (27 repos)
• Capella (18 repos)
• Paho (17 repos)
• Lyo (17 repos)
• etc

Titan seems to have been moved to gitlab already: https://gitlab.eclipse.org/eclipse/titan/

Good point. Then we should follow up to remove the GitHub repos.

at least archive them

Created a ticket to ask the project about the GitHub repos: #3604 (closed)

Titan GitHub repos have been removed after PL confirmation.

Current number of repositories in the Eclipse org: 375

IMO if the main eclipse org becomes an empty shell (or close to it), that would make #1904 all the more relevant :)

marked this issue as related to #3604 (closed)

mentioned in issue #3625 (closed)

mentioned in issue #4340 (closed)

mentioned in issue #4348 (closed)

assigned to @mward

changed due date to June 12, 2024

As we near the completion of the Gerrit->Gitlab/Github transition I'd like to start this work in September(Q3 2024), with an accelerated transition timeline(30 days, rather than 90), supported by Githubs built in redirections. As noted by @fgurr we can start by focusing on the projects with the most repos.

So here's the timeline:

Q2 2024 (Apr-Jun)

• Send a notice to committers about this change, and that it will start in September.

Q3 2024 (Jul-Sep)

• Identify projects with the most repos and file issues here to move them to their own Github organization. Set the due date 30 days into the future.
• Create a 'landing page'(readme) for the Eclipse organisation on Github to list all of the current 'official' orgs for projects

Q4 2024 - Q1 2025

• Complete all moves.

Sound reasonable?

Sound reasonable?

SGTM

mentioned in issue #4584 (closed)

Notice sent to the committers mailing list.

Does this affect groups like https://github.com/locationtech/ ? Thanks,

That is a great question, and my answer is no and yes.

This specific issue is really about the Eclipse organisation, so no it doesn't affect LocationTech.

But the same security concerns that apply to the Eclipse organisation, also apply to our other 'container' organisations, so extending the idea of improving their security by better isolating projects seems pretty reasonable to me at least.

At this time I don't have any ideas about 'when' we'd start talking with teams about such moves, but probably not until Q2-Q3 2025 at the earliest.

However if LocationTech(or other organisations) are looking at this and thinking 'How do we get in on this now?' then I'm certainly willing to either include those projects as part of this, or to open another issue so we can discuss it separately.

ECF already has/has had a github organization of it's own at: https://github.com/ECF

I would prefer that the ECF EF repo at eclipse/ecf be moved to https://github.com/ECF rather than creating a new ECF project github organization as planned by this issue. What would have to happen to do that?

Since eclipsewebmaster doesn't currently control that organisation, we'd need to be added as admins, after which there would be some time required to make sure everything is configured per our general standards and that our sync tooling is controlling access.

I don't think there would be any IP questions given that most of the current people are committers or have an ECA on file, but that's not strictly my call(paging @wbeaton).

Depending on your time frame, you can wait until we start reaching out in August/September, or we can create a separate issue to try and resolve this 'now-ish'

No need to resolve 'now-ish'.

I should make it clear though: I'm not going to be able to continue to support eclipse/ecf filetransfer codebase if it continues to require two project orgs. Resources you see.

mentioned in issue #4652 (closed)

mentioned in issue #4678 (closed)

Just wanted to flag that moving Go libraries (e.g. github.com/eclipse/paho.mqtt.golang and github.com/eclipse/paho.golang) may be a bit more complicated because Go is fairly tightly integrated with source control; for example:

• To use a library you import using the repo path, e.g. import "github.com/eclipse/paho.golang/autopaho", and the tooling handles downloading the required files (often via a proxy).
• Changing the import path is a breaking change (because a variable of type github.com/eclipse/paho.golang/autopaho.ConnectionManager is not the same as github.com/paho/paho.golang/autopaho.ConnectionManager)
• Docs use the same path e.g. https://pkg.go.dev/github.com/eclipse/paho.golang/autopaho

I suspect (but would like to test) that everything will continue to work with the redirect in place. However if we start changing the URL used in the library, then this will force all users to make the same update across their code bases. As such I'm keen to understand if the redirects will be permanent, or you foresee a time limit to these?. I did a quick search and suspect these might be the only two Go Repos.

there is some feedback in the community forum of GitHub wrt redirects after a repo has been transferred / moved: https://github.com/orgs/community/discussions/22669