From Fedora Project Wiki
| Line 10: | Line 10: | ||
The actors represented here have been categorized into the following groups: | The actors represented here have been categorized into the following groups: | ||
RHEL Package Maintainer: This group represents users who currently maintain packages in dist-git and Pagure for RHEL 8 & higher | RHEL Package Maintainer: This group represents users who currently maintain packages in dist-git and Pagure for RHEL 8 & higher | ||
RH Legal Rep: This group represents users who are concerned with decisions that Red Hat could face legal implications for | |||
RH Security Rep: This group represents those within RH who monitor bad code and embargoed content and suspicious activity both internally and externally | * RH Legal Rep: This group represents users who are concerned with decisions that Red Hat could face legal implications for | ||
Community Package Maintainer: This group represents users who currently maintain packages in dist-git and Pagure in the Fedora & CentOS communities | * RH Security Rep: This group represents those within RH who monitor bad code and embargoed content and suspicious activity both internally and externally | ||
Community Package admin: This group represents users who have admin access on some packages in dist-git and Pagure in the Fedora & CentOS communities | * Community Package Maintainer: This group represents users who currently maintain packages in dist-git and Pagure in the Fedora & CentOS communities | ||
Community Provenpackager: This group represents users trusted with commit rights to all packages in the dist-git except for a defined list (defined by FESCo/Legal) and for retired packages | * Community Package admin: This group represents users who have admin access on some packages in dist-git and Pagure in the Fedora & CentOS communities | ||
Release Engineer: This represents a group of users who have commit rights to all packages within the dist-git rep including the ones provenpackager cannot access and retired packages | * Community Provenpackager: This group represents users trusted with commit rights to all packages in the dist-git except for a defined list (defined by FESCo/Legal) and for retired packages | ||
Project Contributor: This represents the people having some access to a project on the forge (regardless of their access level) | * Release Engineer: This represents a group of users who have commit rights to all packages within the dist-git rep including the ones provenpackager cannot access and retired packages | ||
Special Interest Group (SIGs): These are groups of packagers sharing the maintenance of a group of packages, often based on a common interest/goal (can be a project: Openstack, or a field: scientific applications, or a language: rust, nodejs...) | * Project Contributor: This represents the people having some access to a project on the forge (regardless of their access level) | ||
General User: This represents common requirements that come from multiple groups and whom have no specific scenario or use case outside of regular usage and expectations | * Special Interest Group (SIGs): These are groups of packagers sharing the maintenance of a group of packages, often based on a common interest/goal (can be a project: Openstack, or a field: scientific applications, or a language: rust, nodejs...) | ||
Purpose & Plan | * General User: This represents common requirements that come from multiple groups and whom have no specific scenario or use case outside of regular usage and expectations | ||
== Purpose & Plan == | |||
The purpose of this document is to capture all user requirements, and the benefit these requirements bring to the user. | The purpose of this document is to capture all user requirements, and the benefit these requirements bring to the user. | ||
We will mark each feature/function against its availability in each of the three git offerings to better understand what offering meets the needs of all users. | We will mark each feature/function against its availability in each of the three git offerings to better understand what offering meets the needs of all users. | ||
Once this service comparison is complete, the results will be sent to the CPE team management for further review with the Technical leads of the team to estimate the amount of work will be required to facilitate this initiative. | Once this service comparison is complete, the results will be sent to the CPE team management for further review with the Technical leads of the team to estimate the amount of work will be required to facilitate this initiative. | ||
Once a technical scope of the offering that best suits requirements provided has been completed and a decision reached, the results and a preliminary project plan will be released to the community via blog posts, email blasts and IRC postings. | Once a technical scope of the offering that best suits requirements provided has been completed and a decision reached, the results and a preliminary project plan will be released to the community via blog posts, email blasts and IRC postings. | ||
== Requirements == | == Requirements == | ||
Revision as of 13:47, 17 April 2020
This page is to track requirements and progress on Fedora Git Forge change decision
Introduction
Between January 2020 - February 2020, the CPE team released an ODF document outlining the teams intention to Internal and external user groups were invited to contribute their requirements for a git-forge before 10th Feb 2020. A collection of requirements have now been compiled from multiple sources based on the replies and submissions the CPE team received from Fedora, CentOS, RHEL, Red Hat Legal, INFOSEC, Platform Engineering & the Community Platform Engineering Team. The below table illustrates a grouping of the various actors/users of the proposed git-forge unification, their wants and why this is beneficial to them.
Actors/Users
The actors represented here have been categorized into the following groups: RHEL Package Maintainer: This group represents users who currently maintain packages in dist-git and Pagure for RHEL 8 & higher
- RH Legal Rep: This group represents users who are concerned with decisions that Red Hat could face legal implications for
- RH Security Rep: This group represents those within RH who monitor bad code and embargoed content and suspicious activity both internally and externally
- Community Package Maintainer: This group represents users who currently maintain packages in dist-git and Pagure in the Fedora & CentOS communities
- Community Package admin: This group represents users who have admin access on some packages in dist-git and Pagure in the Fedora & CentOS communities
- Community Provenpackager: This group represents users trusted with commit rights to all packages in the dist-git except for a defined list (defined by FESCo/Legal) and for retired packages
- Release Engineer: This represents a group of users who have commit rights to all packages within the dist-git rep including the ones provenpackager cannot access and retired packages
- Project Contributor: This represents the people having some access to a project on the forge (regardless of their access level)
- Special Interest Group (SIGs): These are groups of packagers sharing the maintenance of a group of packages, often based on a common interest/goal (can be a project: Openstack, or a field: scientific applications, or a language: rust, nodejs...)
- General User: This represents common requirements that come from multiple groups and whom have no specific scenario or use case outside of regular usage and expectations
Purpose & Plan
The purpose of this document is to capture all user requirements, and the benefit these requirements bring to the user. We will mark each feature/function against its availability in each of the three git offerings to better understand what offering meets the needs of all users. Once this service comparison is complete, the results will be sent to the CPE team management for further review with the Technical leads of the team to estimate the amount of work will be required to facilitate this initiative. Once a technical scope of the offering that best suits requirements provided has been completed and a decision reached, the results and a preliminary project plan will be released to the community via blog posts, email blasts and IRC postings.
Requirements
Infosec
| What | Why |
|---|---|
| Associates must be able to use SSO to sign in | So that RH as a business is protected against harmful activity from its employees |
RHEL Engineer
| What | Why |
|---|---|
| I want to be able to create branches via an API | So that git branch management can be automated |
| I want to know 6 months in advance if CPE move git forge | So that my team has time to adopt our dependant services to the new offering in a timely manner |
| I want a modern git workflow | So that I can use upstream practices in RHEL development for quicker delivery of features & fixes |
General User
| What | Why |
|---|---|
| I want to sign in using the SSO of my account system | So that I can access the git forge repos and contribute to RHEL |
| I want an API to interact programmatically with the forge | So that I can integrate any/my application with the gitforge |
| I need to be able to port patches between projects S | o that I can easily collaborate between projects |
| I need CentOS & Fedora to be integrated in gitforge | So I can push requests from one OS to the other |
| I need to be able to see SIG groups | So that I know what group to reach out to to ask for help |
| I will see inline images against comments | So that it is easier for me to see communications and status’s of issues |
| The gitforge supports a message bus | So that I can continue to create formatted messages and provide alerts and metrics |
| I want to be able to create a bot/service account | That integrates with the gitforge in the same way as a human does |
| I want to be able to make suggestions to fedora docs | Without having to set up an entire infrastructure for making low-friction contributions |
| I want to create projects and groups of projects | So that I can self organise my teams work |
| I want to create custom access levels | So that I can protect my projects but remain open by default |
| I want the ability to search across metadata | To easily search code, commits and issues within a project |
| I want to rebase without waiting for the submitter to rebase | So that I can proceed with accepting PRs |
| I want a unique URI to my code archive | So that I can have a point in time snapshot |
| I want to access repos fully over https | For environments where SSH is blocked |
| I want to see active branches prioritised | So that end of life branches do not clutter my view |
| I can request access rights to a repository | So that I can contribute in a low friction manner |
| I can file bugs and feature requests | So that I can provide feedback and track future work |
| I can vote on issues | To indicate my support or not for a particular issue |
| I want a mobile native app | To allow me contribute while away from my desk |
| I can reassign issues to another component | Where it can receive help and cooperation |
| I want the service to be reliable and available 24/7 to me | so that I can access the service in a CD manner at all times |
| I would like support to address a bug that I have logged in a timely manner | so that it does not unduly disrupt my workflow |
| I want the ability to use SSH and HTTP pulls | to give me optimal usage |
| I want branches and visualisations of the branching setup | to allow me track releases |
| I want the ability to have private and public repositories | to allow me work in private and publish it publicly |
| I want groups and group membership and management | to allow me create access control on a suite of repositories |
| I want a GUI to interface with the system as well as a CLI | so new users have an easier way to interface with it |
| I want an extensible git hook service to allow me integrate with popular services or create that binding | To allow a CI system evolve around my code |
| I want a temporary file (gist) | So that I can share code easily |
| I want to have interactive code reviews in my branches and PRs | to foster collaboration |
| I want to be notified of CVEs in my code | so that I can stay on top of critical vulnerabilities |
| I want integrated keyword support | to allow me automate a lot of my actions such as a rebuild / retest |
| I want integration with my git forge in my IDE | so I can stay focused in one spot |
| I want to gain analytics and insights from my code | so that I can have historic context to make decisions moving forward |
| I would like a static website as part of my git forge | to allow me advertise my projects and personal self |
| I would like to track my work in an Agile manner | allowing me centralise all my planning in my forge and gain insights into how I am working. |
| I would like merge protection on my PRs | to enable reviewers protect my code |
| I would like insights into the quality of my code | to allow for technical debt planning |
| I would like historical logs and audits of all actions | so that I can satisfy regulatory requirements |
| I would like a suite of templates, | to boostrap projects easier |
| I want registry integration | so that I can store dependencies |
| I want the ability to have a private branch | So that I do not need to leave the code tree I am already in |
| I want to have private repos | So that I can secure an entire repository for privacy reasons |
| I want protected branches | So that I do not accidentally cause any issue |
| I want email notifications | So that I am aware of changes on my PR |
| I want to have multiple PRs merge as a group | So that I can verify wider functionality as one |
| I want automerges when specific acceptance criteria are met | So that I do not need manual intervention |
| I want to set a filter for PRs of interest on a repo | So that I get notified when something triggers my filter |
Kernel Developer
| What | Why |
|---|---|
| I want to know why my kernel patch is on hold | so I know what needs to be done to get it merged |
| want to use git-push | so that I can take advantage of git forge tooling |
| I want to test TSC scenarios that take up to 31 days | so that I can still provide meaningful results for review discussion |
| I want to provide my test dependencies | so the right tests can be run on my patches |
| I need the ability to privately justify a PR | so that confidential information does not leak outside Red Hat |
| I need a place to run scratch builds through CI | so that I can test and verify things before I officially submit my pull-request |
| I want the tool to support email and gui based workflow | so that both the older developers and younger developers feel comfortable committing |
| I want to make sure a bugzilla is attached to every PR | because a bugzilla coordinates management approval |
| I want to follow the same process to submit a patch to z-stream | so I do not have to learn a new process |
| I should have the ability to block all merges until I review them | because I don’t trust the new processes and tools yet |
| I would like to run my own custom testing and not the default CI testing | so that I have control about what is tested based on the pushed patches |
| I need the ability to override a failed check and merge in a pull-request, | so that I have an emergency back-door in case policy or CI falsely fails |
| I must have the ability to point to the history of how a patch entered the git tree | so that I can have a verifiable audit trail of every change in the kernel |
Contributor
| What | Why |
|---|---|
| I want to be able to use kanban boards | So that my team can easily schedule and prioritize work in a visible way |
| I want to be able to apply custom labels to issues | So that I can specify issues on a per-repo basis |
| I want to be able to use custom fields | So that I can specify metadata that is unique to my teams workflow |
| I want to be able to track issues | So that I/my team can track work assigned to us and receive external work requests |
| Example | Example |
CPE member
| What | Why |
|---|---|
| I want the maintaining of a git forge to be more supported | So that I can focus on other projects that meet the mission statement |