Initiatives/Packager Experience

This page is a draft only
It is still under construction and content may change. Do not rely on the information on this page.

In a recent thread on the thread on the devel list, it was suggested we consider pursuing a "Packager Experience" or "Packager Quality of Life" to focus on some short/medium term improvements to the packaging workflow. This page is a draft proposal for such an objective.

Objective: Packager Experience

There are lots of exciting new technologies and initiatives being developed in Fedora at present. However, as we devote resources to projects like Modularity, and consider sweeping changes to the Fedora lifecycle and build process, we should be careful to make sure the experience of packaging software-- the workflow of creating and maintaining packages-- remains a positive one.

Recently, Fedora deprecated pkgdb in favor of Pagure. While Pagure offers lots of new, powerful features for package management (such as the ability to create pull requests, or arbitrary branches), we've lost several other nice management features provided by pkgdb-- such as a central web interface for requesting new branches and repos, or to enable Koschei and Release Monitoring for packages. Individually, these lost features or issues might only qualify as minor annoyances-- meaning that infrastructure and release engineering time is spent on other, higher priority tasks. But the combined effect is to make the packager experience more frustrating and more tedious than it was before.

To improve the situation, we need to work on identifying pain points in the current packager workflow, figure out ways to fix them, and organize the work necessary to actually implement the solutions. The purpose of this Objective would be to create a SIG or WG dedicated to doing just that.

Current Issues

Here's a list of initial packager workflow issues in Fedora that this Objective aims to improve. This list is a DRAFT; it is not complete.

Pkgdb/Pagure

Requesting Repositories and Branches

The fedpkg request-repo and fedpkg request-branch workflow has several problems:

• To submit a request, a Pagure API key is necessary-- but there is no automated process to fetch these API keys, and they expire automatically.
• A short term improvement would be to make Pagure support Kerberos authentication-- like Koji-- or to get fedpkg to manage the API keys somehow.
• A longer term improvement might be to develop a web interface capable of submitting the SCM request tickets.

Unorphaning and unretiring packages

Currently unorphaning or unretirin a package requires a ticket in the releng issue tracker and awaits manual action by a human. This should be automated via a click / command.

Branch ownership

Currently, it is not possible to own a branch in the package repository. This is bad for bugzilla assignment etc.. Currently it is possible to override bugzilla owner for EPEL branches via manually reviewed Pull Request to a specific Pagure repom however the information is not visible on src.fp.o.

Configuring Release Monitoring

It used to be possible to configure release monitoring for a package from pkgdb. Now, I believe it can only be done through submitting a SCM request (i.e. using the same fedpkg request-repo workflow described above). It would be more convenient if it were possible to configure release monitoring through a web interface-- whether some part of Pagure, or through some other central page for managing packages.

Configuring Koschei

It used to be possible to configure Koschei for a package through the pkgdb interface. Now, as far as I know, it can only be done through the Koschei interface. It would be nice to add this to some other central package management page-- be it Pagure or somewhere else.

Package Review

The package review process is critical to getting new packages into Fedora. The process has not changed much for a while, however, and requires a fair amount of manual intervention that could be automated.

The "fedora-review" script automates a lot of the package review process, but it's been lagging behind the packaging guidelines for some time now. For example, as of Fedora 28, fedora-review has not been updated to be aware of recent debuginfo packaging changes. This causes erroneous, false-positive complaints about the ownership of /usr/lib/.build-id (because nearly every package in the distribution owns this directory. Bringing fedora-review up to date with recent guideline changes, and also adding new checks, would reduce the amount of work human reviewers need to do.

An additional improvement would be to design a service that automatically runs fedora-review on every package submission. The first thing many reviewers do is to run fedora-review themselves; but there is no reason this couldn't be automated. A service which automatically runs fedora-review and posts the results would help identify many common problems before a human reviewer even gets involved. Perhaps the automatic reviews could also be invoked in response to setting a flag on the review ticket.

It would also be nice to move away from Bugzilla for package reviews, and to design a new web interface for them. This could be a long term goal.

Goals

The "packager workflow" is described in these pages:

• Package Maintenance Guide
• New Package Process for Existing Contributors

The initial goal of this Objective would be to create a SIG or WG dedicated to packager quality of life issues. This SIG/WG would consist of interested packagers who are willing to contribute to projects such as fedpkg, Koji, Bodhi, Pagure and who want to improve the workflow.

We would start attempting to resolve the issues listed on this page, and then try to identify other problems or pain points with the workflow as well.

Timeframe

TBD, but we would aim to organize a SIG/WG within the next few months and try to resolve several initial problems by F31 or F32. The SIG/WG's efforts would then continue into the future.

Our initial goal would likely be to resolve issues pending from the pkgdb/pagure migration.

Interested People

• Ben Rosser

Objective Lead

TBD

History

This objective is a draft, and has not yet been approved.