This is a source-only change; it will not require an image release to close the issue.

Problem description

The OpenJDK container sources are currently in the "jboss-container-images" GItHub organisation with the repository name "openjdk". Problems:

1. org was created in the Cloud Enablement era (<2018) and is not actively managed or maintained or owned by any particular team anymore.
2. org name including "jboss" has caused confusion for some customers
3. repo name "openjdk" is not descriptive enough – ­particularly when forked (e.g. jmtd/openjdk)
4. corresponding GitHub pages URI has the same problems: https://jboss-container-images.github.io/openjdk/

Proposed solution

Migrate to the rh-openjdk GitHub organisation. This is managed by mtorre@redhat.com and should reflect the current team composition at all times. We can better audit and manage access control.

Rename the repository to "redhat-openjdk-containers". This is a much less ambigious name for new forks of the repository.

The correspondong Github Pages URI would be <https://rh-openjdk.github.io/redhat-openjdk-containers>
which is much clearer.

Migration considerations

The main things to consider when renaming the repository are

1. what happens to open issues (not many of these)
2. what happens to open pull requests (not many of these)
3. will github forks remain associated with the right repo?
4. what will openshift/library do when trying to pull ImageStream metadata
5. what will cekit do when cloning the repo for modules (wildfly, eap, others?)
6. what will happen to the old github pages URI (referenced in slides etc)

Note: this will have no impact on building existing container versions in Red Hat, automatic respins, etc.

Proposed process

Two-phase process: Perform a GitHub Transfer, then Fork the repository back to the older name.

The GitHub transfer would address points 1-3 directly. GitHub will serve up HTTP redirects from the old location to the new which should address points 4-5.

Point 6 would not be fixed by the GitHub transfer alone. However, by performing a clone back to the old location:

1. the HTTP redirection would stop. openshift/library, cekit etc would pull from the fork. Consumers of our cekit modules would need to update the URI to get newer content.
2. the GitHub pages URI would be retained. We would be free to replace the old site with a graceful redirect to the new location.