From 803d743eca6344bd3b02ada9a7718475a7bd2d31 Mon Sep 17 00:00:00 2001 From: Robert Cohn Date: Wed, 17 Apr 2024 08:31:49 -0500 Subject: [PATCH] RFC: Moving to UXL GitHub org --- rfc/001-changing-github-org.rst | 129 ++++++++++++++++++++++++++++++++ 1 file changed, 129 insertions(+) create mode 100644 rfc/001-changing-github-org.rst diff --git a/rfc/001-changing-github-org.rst b/rfc/001-changing-github-org.rst new file mode 100644 index 0000000..d72938b --- /dev/null +++ b/rfc/001-changing-github-org.rst @@ -0,0 +1,129 @@ +========================================== +Moving Projects to UXL GitHub Organization +========================================== + +Moving UXL projects from `oneapi-src`_ to an organization owned +by UXL. + +Background +========== + +All 6 of the original UXL projects are in the `oneapi-src`_ GitHub +organization. The org is owned by Intel and also contains projects that are not +part of UXL. We need to transfer ownership of the repos to UXL by moving them +to a new org. + +We considered various options: + +1. Move all the repos to the `uxlfoundation`_ org. +2. Move the oneapi-src org to UXL. +3. Move the repos to a project-specific org. + +We do not recommend (1) and (2) because they are a shared org. A shared org has +the following drawbacks: + +* Must share GitHub runners, permissions, and integrations +* Repo and team naming conflicts +* Community confusion. DPL and DNN have different communities and goals. +* Requires central management, and UXL does not have the resources to manage + the org + +Furthermore, (2) requires redefining the purpose of oneapi-src, which will lead +to confusion about the projects that go and stay. + +A shared org does have some advantages: + +* Central management can be more efficient and secure +* Sharing team definitions across projects when there are shared teams +* Provides more visibility for UXL as the host of the projects + +We recommend (3) because it is the common practice for large complex open +source projects. Projects will have the freedom to manage their org as they see +fit and not be affected by requirements or preferences of other projects. + +Proposed Org & Rep Names +======================== + +.. list-table:: + :header-rows: 1 + + * - Current Repo + - New Org + - New Repo + * - onednn + - onednn-project + - oneDNN + * - onedal + - onedal-project + - oneDAL + * - oneccl + - oneccl-project + - oneCCL + * - onemkl + - onemkl-project + - oneMKL-sycl-interfaces + * - onedpl + - onedpl-project + - oneDPL + * - onetbb + - onetbb-project + - oneTBB + +Org Administration +================== + +The projects will have ownership of their org. To ensure continuity, select at +least 2 people to have the org ``owner`` role. It is not recommended to broadly +share ownership permissions. Prepare a basic set of recommended configurations +(e.g. 2fa) for the org or perhaps the org can be configured before handover of +the project. Each org will be Linux Foundation and UXL admins who are there for +emergency maintenance only. Need to share some guides on how to manage an org. + +Process +======= + +This is a sketch of the activity. Each project should prepare its own schedule +and plan. Robert Dower, the maintainer of oneapi-src org will help with the +move by preparing the new org, transferring the teams, and moving the repos. + +Preparation: +1. Create the new org and teams +2. Prepare a project specific test plan +3. Prepare a project specific communication plan +4. Identify URLs that are not redirected and prepare PR's to update them. + +Execution: +1. Communicate the change to the community. +2. Move the repos to the new org. +3. Merge the PR's to update the URLs +4. Testing + +Cleanup: +1. Update URLs that are redirected + +Risks and Mitigations +===================== + +This section includes some generic risks. Each project should identify its own +risks. + +Community confusion + Communicate the change to the community and ensure that they understand the + new org structure and schedules. +Community disruption + Ensure that the new org has the same teams, permissions, and integrations as + the current org. Leverage GitHub repo URL redirect and provide website + redirects. +Maintainer disruption + Ensure that maintainers are aware of the change and have the necessary + permissions to continue their work. +CI/CD disruption + Test plan. Ensure the CI/CD maintainers are available to address problems. +Unexpected breakage + Test the new org before the move. Have a rollback plan in case of unexpected + breakage. Search the repos for references to the old org. +Release disruption + Schedule moves during a time when releases are not planned. + +.. _`uxlfoundation`: https://github.com/uxlfoundation +.. _`oneapi-src`: https://github.com/oneapi-src