# Packager UX improvement - Requirement document

###### tags: `Requirements Document` `Fedora`

[toc]

## Point of contacts

**CPE Appointed Owner**: pingou
**CPE Appointed Manager**: To help unblock
**CPE Collaborators**: mkonecny
**Key Stakeholder**: Miro, nirik? Mohan?
**IRC Channel**: #fedora-apps
**Taiga Link**:
**hackmd Link**: https://hackmd.io/s/HyBmoE3hN

## Document History

It is important to keep track of the evolution of the requirements document. Here, we can track key changes and milestones.

**Version**: 1.0 - 2019-05-14
**Authors**: pingou
**Details**: First initial Draft for review

**Version**: 1.1 - 2019-05-16
**Authors**: Miro Hrončok - Clément Verna - pingou
**Details**: Added some user stories

## Requirements Guidelines

When writing a requirements document intended for the CPE team, a number of key items need to be included in order to help with initial reviews and later prioritization and scheduling.

The following sections are required before this doc is ready for the team to consume. An example spec for reference is the Rawhide Gating [spec](https://fedoraproject.org/wiki/Infrastructure_2020/Rawhide_Gating). The sections below are not exhaustive, and the CPE team should evolve them based on their domain knowledge. The principle of each heading in this Template should be used to guide the requirements. If a heading is omitted, the spirit of what it is trying to achieve should be included in other sections.

## Goals

The goal of this work is to improve the Fedora packager workflow to match or even surpass the user experience packagers had when we were using pkgdb.

## Value Proposition & Background

The packager workflow has suffered a little by the move from pkgdb to pagure and pagure now has some ways to enable some of the functionality that pkgdb had.

### Get rid of the git repository from https://pagure.io/releng/fedora-scm-requests/

That project hosts in its git repository a few things:
- Whether a project is to be monitored by anitya
- The bugzilla overrides when the point of contact in bugzilla should be different than the one in dist-git

Using this project means that a packager has to fork the project, clone the git repository, update it and open a PR to it. The merging of the PR is not automated making the process not self-service.
The size of the repository (over 100MB) has also raised a few complaints, the latest of which can be read at:
https://lists.fedoraproject.org/archives/list/[e-mail]/thread/RNUBMEG6GOY3V2LNXV7PX4P56CE4NSEN/#RNUBMEG6GOY3V2LNXV7PX4P56CE4NSEN

### Improving adopting packages

Currently, to adopt orphaned packages, packagers have to open a releng ticket and wait for it to be processed. We could improve this situation by making adoption easier and only let people open a releng ticket when the package is retired (which requires a releng action on koji).

### Improve the new-branch process

Currently to request a new-branch on an existing project one has to open a ticket at https://pagure.io/releng/fedora-scm-requests/ and wait for a releng admin to process it.
We could automate this process mimicking the logic used in the old pkgdb:
- If the request is for a Fedora branch: grant it automatically
- If the request is for an EPEL branch:
- Check if the package is present in RHEL, if it is, block the request
- Otherwise, notify the current POC
- If the current POC says “ok”, put the ticket on the pile to be processed by a releng person
- After a week, if the current POC did not reply, assume it is “ok”

It should be easy to automate granting Fedora branches on demand.
For EPEL branches, we may leave this in the hands of releng.

## Who is requesting this

Fedora packagers in general.
This can be seen in this thread on the fedora devel list:
https://lists.fedoraproject.org/archives/list/[e-mail]/thread/6HUAWQA35ZBUGPVNLCGGP5H5HFOUHNUZ/#6HUAWQA35ZBUGPVNLCGGP5H5HFOUHNUZ

## Assumptions

We want to avoid surprises to the development team in the middle of working on a request. At best a surprise can add more time to a project, at worst, it can lead to it failing. A big part of protecting both the team and indeed the feature being requested is calling out any Assumptions that the requester is making while putting together the spec.

| Assumption | Raised By | Plan of Action |
|:------ |:----------- |:----------- |
| Pagure and pagure-dist-git are the ones that will require the most attention | pingou | Work there
| Anitya can be adjusted to use dist-git as source of information | pingou | Tracked in: https://github.com/fedora-infra/the-new-hotness/issues/233|
| Bugzilla overrides can be moved away from this repository | pingou | Tracked in: https://pagure.io/fedora-infrastructure/issue/7690 |

## User Stories

### Actors

* Packager
* Release engineer
* Power user (mostly other packagers, but not necessarily)

### User Stories

| Story Number | Group | User Story | Importance | Acceptance Criteria
|:------------ |:----- |:---------- |:-----------|:-------------------|
|1| Pagure-dist-git https://pagure.io/pagure-dist-git/ Anitya | As a packager I want to set the monitoring status of my package in dist-git via a button in the UI | Must Have | The monitoring status is shown in the UI of the package with a drop-down to update it|
|2| Pagure-dist-git https://pagure.io/pagure-dist-git/ | As a packager I want to be able to adopt orphaned (and not retired) packages in dist-git via a button in the UI | Must Have | For orphaned packages, there is a button in the UI to adopt it. If the package is retired, the action will fail with an actionable error message.|
|3| Pagure-dist-git https://pagure.io/pagure-dist-git/ Pagure <-> bz sync script | As a Packager I want to set bugzilla overrides in dist-git via a button in the UI | Must Have | The bugzilla assignee / POC can be set/updated in the UI of the package page. In the rpms namespace, it will distinguish Fedora and Fedora EPEL|
|3.1| Pagure-dist-git https://pagure.io/pagure-dist-git/ | As a Power user I want to see bugzilla assignee in dist-git | Must Have | The bugzilla POC should be clearly presented in the UI. In the rpms namespace, it will distinguish Fedora and Fedora EPEL |
|4| loopabull | As a Packager I do not want to wait when asking to create a new Fedora branch for a package | Must Have | Requests for a new Fedora branch will be granted automatically in a reasonable amount of time |
|5| Pagure-dist-git https://pagure.io/pagure-dist-git/ | As a Packager I want to request adapting a retired package from dist-git | Nice To Have | On retired packages there is a button to open a releng ticket asking to unretire the package (pre-filing the form if possible).|
|6| Fedscm-admin https://pagure.io/fedscm-admin/ | As a Packager I want to get actionable feedback on failed repository creation request or a human to talk to. | **Very** Nice To Have | When the request fails, the requester should be redirected to the proper communication channels.|

> [name=Pierre-Yves Chibon Planned/Tracked in https://pagure.io/fedora-infrastructure/issue/7690]
Story 3
> [name=Pierre-Yves Chibon loopabull is an option here, not set in stone]
Story 4
> [name=Pierre-Yves Chibon Ideas: -- Improve the message returned when the process fail to include instructions on how to continue -- Figure out a way to see that the ticket has been re-opened and make it prominent to the person running the tool -- Show the last (1, 2?) Comments on the ticket to the person running the tool]
Story 6

## Open Questions

Please log and track any Open Questions here

## Risks Identified

Have we identified any risks for this work that we need to be aware of?

## Descoped

We don’t throw things away. The User Story list above should be our Minimum Viable Product (MVP), anything descoped should be copied from the Table above to the Table here so we can potentially have a Phase II.

| Story Number | Group | User Story | Importance | Acceptance Criteria
|:------------ |:----- |:---------- |:-----------|:-------------------|
|?| Pagure-dist-git https://pagure.io/pagure-dist-git/ | As a Power user or a Packager I want to be able to see who is the POC for a stream branch. | Nice To Have | |
> [name=Miro Hroncok but hard to implement and the definition of stream branch POC is fuzzy still]
Nice To Have

## Decision Log

* None at this time

## Next Steps

* 2019-05-14: Share this document with the CPE team
* 2019-05-14: Share this document with Miro (churchyard)
* 2019-05-16: Meeting with Miro who opened a FESCO ticket on the same subject: https://pagure.io/fesco/issue/2115

* 2019-05: Move this document to a public space for the community to be able to see it
* 2019-05: Bring this proposal to the team and figure out how to make a decision on it

If accepted:
* 2019-05: Create an epic in taiga for this proposal
* 2019-05: Create user stories associated to this epic in taiga

If declined:
* 2019-05: Report to Miro
* 2019-06: Find out good tomato-based recipes to use all the rotten tomatoes received.