Infrastructure/arc
1
0
Fork 0
Code Issues 1 Pull requests Projects Releases Packages Wiki Activity Actions

Expand the Roadmap, Estimate and Technologies sections

Browse source 
Signed-off-by: Akashdeep Dhar <akashdeep.dhar@gmail.com>
This commit is contained in:
Akashdeep Dhar 2023-12-19 15:28:38 +05:30
parent a5ac25b777
commit 9ac01b9839
1 changed files with 49 additions and 13 deletions
Download patch file Download diff file Expand all files Collapse all files

62
docs/dist-git-move/index.rst
View file

@ -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 <https://git-lfs.com/>`_ 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 <https://git-scm.com/>`_ - For Source Code Management
- `Git LFS <https://git-lfs.com/>`_ - For source tarballs and binary files in lookaside
cache
- `FastAPI <https://fastapi.tiangolo.com/>`_ - For the compatibility metaservice backend
- `Vue <https://vuejs.org/>`_ - For the Git Forge frontend