Git forge update

This page is to track requirements and progress on Fedora Git Forge change decision 

Updates as of 2020-05-15

The CPE team have filed a ticket in GitLab to publically track our progress with this migration for transparency and collaboration. CPE management have also provided the considerations given to Pagure during their deliberations. This has been pulled from a google document and emailed to pagure-devel@lists.pagure.io by our product owner. Please feel free to read the hackmd note >>here<<. FESCo also have closed their ticket on pagure.io To improve on our comms even more during this project, amoloney1, our product owner holds office hours on #fedora-meeting-1 on IRC every Thursday @ 1300 UTC. Please feel free to engage with us here too with your questions and concerns. We had some great technical discussion on our most recent meeting, the log can be viewed >>here<< We will also endeavour to have weekly status updates on this wiki page, however this project is extensive and we are taking great care to ensure it is successful and beneficial to everyone so you may not see lots of activity here every week.

Phase Two Asks

The team have been gathering more technical requirements and questions to bring to GitLab in order to ensure that functionality as it exists today will continue to function within the new forge. To that end, we are soliciting more granular requirements from the communities. This effort is being led by cverna & amoloney and our deeper technical requirements can be read in our hackmd note.

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.

Phase One Requirements

For transparency, these were the sets of requirements gathered from the various actors which led to the decision to opt for GitLab as our Git Forge.

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

Community Users

This represents general user stories from both Fedora & CentOS communities, as well as general requirements that came from all user groups, who are in fact community members in our view.

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

General Contributor Users

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

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