From Fedora Project Wiki

(→‎General User: add sample entries)
mNo edit summary
 
(13 intermediate revisions by 2 users not shown)
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  


== Requirements ==
== Updates as of 2020-05-15 ==
 
The CPE team have filed a [https://gitlab.com/gitlab-org/gitlab/-/issues/217350 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 [https://hackmd.io/0ftzXRIRQwamoNrFgIfNeQ >>here<<].
FESCo also have closed their [https://pagure.io/fesco/issue/2383 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 [https://meetbot.fedoraproject.org/fedora-meeting-1/2020-05-14/cpe_project_owner_office_hours.2020-05-14-13.01.log.html >>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 [https://hackmd.io/@fedorainfra2020/Sy0V7s6OU 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 ===
=== Infosec ===
{| class="wikitable"
{| class="wikitable"
Line 9: Line 48:
| Associates must be able to use SSO to sign in || So that RH as a business is protected against harmful activity from its employees
| Associates must be able to use SSO to sign in || So that RH as a business is protected against harmful activity from its employees
|-
|-
| Example || Example
|}
|}


=== RHEL Engineer ===
=== RHEL Engineer ===
* I want to be able to create branches via an API
{| class="wikitable"
** So that git branch management can be automated
|-
 
! What !! Why
* 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 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
|-
|}


* I want a modern git workflow
=== Community Users ===
** So that I can use upstream practices in RHEL development for quicker delivery of features & fixes
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.


=== General User ===
{| class="wikitable"
{| class="wikitable"
|-
|-
Line 45: Line 88:
| 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 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 ===
{| class="wikitable"
|-
! 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 ===
{| class="wikitable"
|-
! 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 ===
{| class="wikitable"
|-
! 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
|}
|}

Latest revision as of 18:12, 15 May 2020

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