From Fedora Project Wiki

Line 1: Line 1:
= This page is to track requirements and progress on Fedora Git Forge change decision =
= 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 ==
== Requirements ==

Revision as of 13:46, 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