From 9ac01b9839d7e90324a86645fa32439919c5f017 Mon Sep 17 00:00:00 2001 From: Akashdeep Dhar Date: Tue, 19 Dec 2023 15:28:38 +0530 Subject: [PATCH] Expand the Roadmap, Estimate and Technologies sections Signed-off-by: Akashdeep Dhar --- docs/dist-git-move/index.rst | 62 ++++++++++++++++++++++++++++-------- 1 file changed, 49 insertions(+), 13 deletions(-) diff --git a/docs/dist-git-move/index.rst b/docs/dist-git-move/index.rst index d9e51e8..0d2cd12 100644 --- a/docs/dist-git-move/index.rst +++ b/docs/dist-git-move/index.rst @@ -70,21 +70,57 @@ Index summary solution -Conclusions ------------ -To adequately complete the proposed work, 3-4 engineers for approximately -2 quarters is recommended. +Estimate +-------- +To adequately complete the proposed work, 3-4 engineers for approximately 2 quarters is +recommended. 2-3 developers and 1 sysadmin should suffice the need of both building the +said solution as well as creating the deployment. -Proposed Roadmap ----------------- +Roadmap +------- -- **Step 1** - Deploy to staging -- **Step 2** - Community testing -- **Step 3** - Deploy to production +- **Step 1** - Discussing on the Git Forge and deciding on a specific one to use +- **Step 2** - Introducing the *newer API compatibility* to the + *internally maintained applications* +- **Step 3** - Adding Git Large File System support for the source tarballs and binary + files +- **Step 4** - Developing the compatibility metaservice for the chosen Git Forge API +- **Step 5** - Making a staging deployment for the Git Forge on a subdomain (say, + ``SUBDOMAIN A``) +- **Step 6** - Pointing the Dist Git's staging URL (say, ``SUBDOMAIN B``) to the + compatibility metaservice +- **Step 7** - Following up for the *externally maintained applications* to switch over + to the newer API +- **Step 8** - Improving the project on the community feedback received on the staging + deployment tests +- **Step 9** - Making a production deployment for the Git Forge on a subdomain (say, + ``SUBDOMAIN C``) +- **Step 10** - Pointing the Dist Git's production URL (say, ``SUBDOMAIN D``) to the + compatibility metaservice +- **Step 11** - Announcing a time limit for the planned obsolescence for the + compatibility metaservice +- **Step 12** - Confirming that all the applications have switched over to the newer API +- **Step 13** - Decommissioning of the compatibility metaservice after its utility is + outlived +- **Step 14** - PROFIT? -Proposed Technologies ---------------------- -- `Git LFS `_ Large File Storage for lookaside cache -- +Appendix +^^^^^^^^ +- **Internally maintained applications** - Projects maintained by the Red Hat CPE team + (eg. Monitor Gating, The New Hotness, Releng Scripts, Toddlers, Notifications and + Datanommer) +- **Externally maintained applications** - Projects maintained by other teams (eg. + Fedpkg, COPR, Fedora CI, Bodhi and Packit) +- **Newer API compatibility** - Making pre-releases with the compatibility changes + included as the said Git Forge is not yet deployed + +Technologies +------------ + +- `Git `_ - For Source Code Management +- `Git LFS `_ - For source tarballs and binary files in lookaside + cache +- `FastAPI `_ - For the compatibility metaservice backend +- `Vue `_ - For the Git Forge frontend