Git Forge Requirements ODF

Tuesday, 21, January 2020 Rich Bowen Uncategorized No Comments
  1. Home
  2. Blog
  3. Git Forge Requirements ODF

About this document

This document lays out a problem statement, requirements, and constraints according to the Open Decision Framework. The aim is to arrive at a transparent decision about the future of a git forge for the communities that represent the platforms that the Community Platform Engineering (CPE) team manages. Those communities are the CentOS and Fedora platforms and also include the Red Hat Enterprise Linux (RHEL) platform from a tooling and integration perspective. This document is the first in a series of documents capturing the conversation about the problems we face and driving the conversation to implement the decisions captured.

Problem

The problem statement for this ODF can be broken down into a number of disctinct problems. They are listed in no particular order or priority:

CPE Mission Statement

The Community Platform Engineering (CPE) team have a mission statement to support the infrastructure and services that build and deliver platform artifacts. The mission statement aims to focus the team’s work from overcommitting to work, running multiple projects in a disconnected manner and to ultimately provide focus and value for our Communities. The remit of the team needed to be defined to allow the team to both manage the workload and the expectations.
Using this definition, the current git forge, Pagure, does not align with what CPE can focus on from both a roadmap development perspective and the operational requirements that such a service demands long term. While Pagure was historically driven by the CPE team, developing a gitforge is outside of building and delivering platform artifacts. [See the later sections for more focus on this.] A self-hosted and self-developed git forge is not required to build and deliver platform artifacts.
While we can make exceptions to the mission statement, we first need to know why we should consider a specific exception. This helps justify the inclusion and subsequent prioritisation of work. We recognise that Pagure is deeply integrated into our daily workflows and is used extensively by the Community. This is the reason the CPE team has not re-examined this commitment, and is a primary driver to openly discuss the team’s and community’s requirements for a git forge.

Development work on Pagure

The CPE team has been unable to commit a development team to Pagure for several months now. This situation is unlikely to change based on our current known priorities.
Historically, Pagure was maintained by individuals (including members of the Fedora community who aren’t on the CPE team) where spare cycles allowed. However, CPE’s mode of working is now that of feature teams, removing the siloed contributions in favour of building sustainable team practices. The feature roadmap for Pagure, however, cannot be executed solely by the CPE team, since the feature requests need to be weighed against the team’s other priorities.
Pagure represents one app out of our current ownership of 100+ code bases. Therefore progression of the roadmap is not guaranteed and certainly not at the pace seen previously. Similarly, bug fixes and enhancements are currently on a best-effort basis. The code is therefore frozen from a functionality perspective pending the outcome of this ODF.

Operational considerations of Pagure

Every line of code and application CPE supports as a team has a cost burden for maintenance and uptime. Pagure is highly-connected to numerous services that are critical to successfully running services that CPE and the community need and support. Therefore, the team must look at long term maintenance including bug fixes and server maintenance as requirements.

At the same time, integrations that already exist in Pagure may need to be created for another git forge, which is a cost as well. This also needs to be fully considered by the team as part of the requirement gathering.

Another major consideration to operationally own an application is its performance and scalability. A git forge may have key requirements for uptime, availability and responsiveness for end users. The current scalability profile of Pagure is unlikely to substantially change as it is resourced today – while the consumption profile of the user base and interconnected applications is likely to increase.

History of gathering requirements

TThe original purpose of Pagure was to mirror the functionality of popular git forge solutions that were available at the time (when most were nascent). Pagure’s feature enhancements were driven by community needs and the team’s viewpoint of where a git forge should go. The team has not solicited requirements in a holistic way from its users and the community, and its internal customers have mainly consisted of the team itself.

However, we also recognize that the feature gap between Pagure and some other forges is substantial and growing. Without either a dedicated development team, or stealing resources from other priority initiatives, it will be almost impossible to close those gaps. Depending on the consumers’ requirements, we recognize this could put Pagure in an untenable situation versus other solutions.

This makes gathering a full set of requirements even more critical. If we fail to capture requirements completely, this discussion is very likely to happen again, only more urgently and with less time for the team to plan and react.

Problems we’re not trying to solve

Feature gap between various git forge solutions

This conversation does not focus on whether Feature X exists in Forge Y or Forge Z. Instead it focuses on functional and non functional requirements for a git forge in general.

CPE time and resourcing investment

This conversation does not focus on how the CPE team invest their time and limited resources. That is not a factor in this discussion.

CPE Mission Statement

This document does not focus on the CPE Mission Statement or whether a git forge should fit that Mission Statement.

Who is making the decision?

The decision will be made by the management of the CPE team with careful consideration of the requirements for both the Fedora and CentOS communities as well as the needs of the team. The CPE team is the group that manages the integration of services and tooling with a git forge solution on behalf of our communities, and will choose the most sustainable, functional, and scalable option to improve our workflows long term.

Choices Available

There exist three choices for such a solution. Github, Gitlab and Pagure. There are no other forges that we could find that had both the product maturity and standing in open source communities, therefore no other solutions are under consideration as the three choices here represent the main git forge solutions on the market. The team will use the requirements gathered to make an informed decision on which of the 3 to pursue.

Who has input into the decision?

Please see the section on Stakeholders below.

Objectives

Identify functional requirements of a git forge that end users and stakeholders need

The goal is to outline what is needed from the day to day perspective of:

Requirements are welcome from members of the CPE team and the groups identified as being impacted by such a decision.

Identify non-functional requirements of a git forge that end users and stakeholders need

Examples of non-functional requirements include but are not limited to performance, scalability, availability, reliability, maintability, and capacity. The goal here is to include considerations of this nature from any group impacted by this decision.

Make an informed decision on the future of our git forge solution

Upon gathering the requirements of a git forge solution, the intention is to:

To be clear, the outcome here may be a decision to invest heavily in Pagure to meet the requirements or it may be to opt for another git forge to meet the requirements. No option is off the table.

Who may be impacted

Who are the key stakeholders

While we apprecaited that all individual voices matter, for a more sane approach to gathering requirements we will identify key stakeholders to collate and present a singular view of their representation.

How will information be gathered and disseminated?

It is recommended that both Fedora Council and CentOS Board gather input and present their concerns in a manner that is consistent with how their communities work. The RHEL and CPE requirements will be gathered through Red Hat communication mechanisms and presented publicly via a HackMD file to ensure transparency in their source. This will be published and distributed in due course. Additionally, a live video call and associated IRC meetings will be held and advertised in advance to discuss the requirements, talk about concerns and address any questions. We want transparency to be at the heart of this decision.

Timeline of Phases

Leave a Reply

Your email address will not be published. Required fields are marked *