Infrastructure/WhatHappenedToPkgdb

Why PkgDB Is Being Decommissioned

In general, PkgDB works well for the current workflow of a package’s lifecycle. Currently, a package has several branches that are tied to Fedora releases such as “f24” or “f25”. These branches have implied service level agreements (SLAs) and end of life (EOL) dates based on the Fedora release itself. Although the implied SLAs and EOLs in these branches have worked well for Fedora in the past, it’s becoming increasingly difficult to juggle different application lifecycles and their dependencies’ lifecycles under the umbrella of these limited number of SLAs and EOLs, especially when trying to keep up with upstream. In the past, we have not been able to have different package lifecycles within a Fedora release due to the nature of it's design. With Modularity, that will become a reality, and Fedora packagers and module maintainers will need a new way of branching in dist-git to enable this functionality.

Since PkgDB was written with the old way of branching in mind, there ended up being two logical paths forward. We could significantly rewrite PkgDB to work with the new branching methodology, or we could migrate PkgDB's existing functionality to other tooling. After talking with some folks in the Fedora community, the latter seemed to be the right approach because Fedora was moving to "Pagure over Dist-Git", and that was going to duplicate and clash with a lot of PkgDB's functionality anyways.

How Is PkgDB's Functionality Being Replaced?

PkgDB has two primary functions. It provides package repo ACLs, and package related "admin requests" and "admin actions". After PkgDB will be replaced, ACLs will be handled in Pagure over Dist-Git (placeholder link) at the package level like you would handle a traditional code repository on pagure.io. As for "admin requests" and "admin actions", those will be replaced by a CLI tool called fedrepo-req that will submit JSON formatted tickets on your behalf to a ticket queue in a specific Pagure project monitored by the Fedora Release Engineering group.

For more information on this or information on how other features in PkgDB are being replaced, please read the "How To Make This Change" section of the Arbitrary Branching Focus Document written by the Factory 2.0 team.

Help/FAQs

How do I give a user commit access to a dist-git repo?

1. Browse to your project on Pagure over Dist-Git (placeholder link)
2. Click on "Settings"
3. Scroll down to "Users and Groups"
4. Click on "add user"
5. Type the username in the form
6. Select "commit" instead of the default of "ticket" to set the level of access
7. Click "Add"

How do I request commit access to a dist-git repo?

Email the PACKAGENAME-owner@fedoraproject.org alias asking to be given access, or file a bugzilla bug on the package asking for access.

How do I request a new package, a new branch, or to unretire a package?

The ticketing functionality of PkgDB was replaced by a CLI tool called fedrepo-req. Please review the read me for instructions on how to install and use the tool.

How do I find out who owns a package?

1. Browse to the project on Pagure over Dist-Git (placeholder link) you are interested in
2. On the right side of the page, there is a heading called "Contributors". Under that heading, there will be a username with "(main admin)" displayed next to it. That is the owner of the package.

How do I find out the list of orphaned packages?

All orphaned packages will be owned by the "orphan" FAS user account in Pagure over Dist-Git (placeholder link).

You may use the user interface to view all the projects owned by the "orphan" user, but this will include repos other than just packages (like containers or modules): [1]

You may use the REST API to view only the orphaned RPM repos by visiting: https://src.fedoraproject.org/pagure//api/0/projects?namespace=rpms&owner=orphan

How do I find the list of retired packages/branches? (incomplete)

Retired branches are tracked in PDC by setting the "active" flag to "false" on a branch.

To view all packages with a master branch that is retired, you can visit the following: https://pdc.fedoraproject.org/rest_api/v1/component-branches/?active=false&type=rpms&name=master

To view all retired package branches, you can visit the following: https://pdc.fedoraproject.org/rest_api/v1/component-branches/?active=false&type=rpms

To view all retired packages, a script will need to be written to query PDC and perform a process of elimination.

How do I find a branch's SLAs?

A branch's SLA is stored in the Product Definition Center (PDC). An entry in PDC is required for a package to be used in a module. As an example, if wanted to view the Python package's SLAs for the 2.7 branch, you can visit the link below. You'll notice that the URL contains three parameters to the request. The "type" is set to "rpms", which filters the request down to just RPM packages. The "global_component" is set to "python", which filters it down to only branches belonging to any "python" component (e.g. an RPM, container, module, etc). Lastly, the "name" is set to "2.7, which filters it down to only "2.7" branches of components. All these filters together give you a unique result of the Python 2.7 RPM branch. https://pdc.fedoraproject.org/rest_api/v1/component-branches/?type=rpms&global_component=python&name=2.7

How do I find what SLAs are available for use?

All available SLAs are defined in the Product Definition Center (PDC) at: https://pdc.fedoraproject.org/rest_api/v1/component-branch-slas/

How do I set an SLA on my branch? (TODO)

TODO

Will there be an "f27" branch? (unofficial response; needs confirmation)

Yes, there will be an "f27" branch that will in general act like the "f26" branch with SLAs that match the Fedora 27 release. This means packagers don't have to change their branching strategy if they don't want to. With that being said, if one branch is suitable for multiple Fedora releases, it may be less work for the packager to create a single branch that is used by all those releases instead of maintaining a branch per release.

In what circumstances should I request a new-style branch?

There could be many reasons to request a new-style branch. The primary reason is if you'd like a branch that doesn't have an SLA of a traditional Fedora release. If for instance, you create a branch that can serve multiple Fedora releases, that would end up being less work for you as the packager since you only maintain one branch instead of many with the same code base. Another instance is if your package needs to have breaking changes that are frequent and violate the lifecycle of a traditional Fedora release. The latter example could not, however, be included in a Fedora release since it's SLA is lower than the SLA of a release.

How should I name my branch? (unofficial response; needs confirmation)

At this time, there are no restrictions on how you name your branches except that they may not be derogatory or offensive in any way. Try to use branch names that best describe the SLA you are trying to provide. For instance, if you maintain a package that that is at version 2.7 for a while, you could create a branch called "2.7" which would be updated with every 2.7.x release upstream. Another example is if you are always trying to package the latest upstream version, you could call your branch "latest". It's really up to you, but just try to be helpful and considerate when choosing names.