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.

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.

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.

Goals

The "packager workflow" is described in these wiki 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.

Interested People

• Ben Rosser

Objective Lead

TBD

History

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