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 levels (SLs) and end of life (EOL) dates based on the Fedora release itself. Although the implied SLs 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 SLs 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 its 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 (see: a demo) 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?
- Browse to your project on Pagure over Dist-Git (Top Level link)
- Click 'browse' in the top right, to open a search box
- Enter the package name and select the proper package from the results
- Click on "Settings"
- Scroll down to "Users and Groups"
- Click on "add user"
- Type the username in the form
- Select "commit" instead of the default of "ticket" to set the level of access
- 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 or a new branch
The ticketing functionality of PkgDB was replaced by a set of command line tools called fedrepo-req, and then the functionnality have been merged in fedpkg. See the fedpkg request-branch help.
How do I orphan a package?
Visit the package's repo in pagure and navigate to the settings for that repo. I.e.
https://src.fedoraproject.org/rpms/PACKAGE_NAME/settings
Navigate down to the Give Project section and "give" the project to the "orphan" user.
For completeness, under the Users and Groups section, remove yourself from the list.
How do I retire a package?
Run fedpkg retire in a local git checkout of the package's repo.
How can I watch a package's commits?
Navigate to the project's repo:
https://src.fedoraproject.org/rpms/PACKAGE_NAME
- There should be a little icon with an eyeball in the top right.
- Click it.
- There should be a drop-down with various options for different kinds of "watch" activity.
- The one you want should say "watch commits".
How can I get added to the CC list of a package bug reports?
This used to be called "watchbugs" in pkgdb. Similar to "watchcommits", which is addressed in the question above this one...
Navigate to the project's repo:
https://src.fedoraproject.org/rpms/PACKAGE_NAME
- There should be a little icon with an eyeball in the top right.
- Click it.
- There should be a drop-down with various options for different kinds of "watch" activity.
- The one you want is "watch issues and PRs".
How do I become the default assignee of a branch in bugzilla?
File a pull-request on the releng/fedora-scm-requests repo to add your FAS username.
How do I change the upstream-monitoring/anitya flag for my packages?
File a pull-request on the releng/fedora-scm-requests repo to tweak the monitoring setting for your packages.
How do I transfer ownership of a package to someone else?
Navigate to the project's repo's settings page:
https://src.fedoraproject.org/rpms/PACKAGE_NAME/settings
Scroll down to the "give project" section. There you can give the package to someone else.
How do I adopt an orphaned package or unretire a package?
For now, file a release engineering ticket with the name of the package, what you need done and in the case of unretirement, the re-review of the package (if required).
In the case of adopting an orphaned package, they should be able to give it to you with the give-package.py script.
In the case of unretiring a package, they should follow the SOP for unretiring a package.
How do I find out who owns a package?
- Browse to the project on Pagure over Dist-Git (placeholder link) you are interested in
- 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): https://src.fedoraproject.org/user/orphan (placeholder link)
You may use the REST API to view only the orphaned RPM repos by visiting: https://src.fedoraproject.org/api/0/projects?namespace=rpms&owner=orphan (placeholder link)
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 SLs?
A branch's SLs (termed SLA in PDC) are 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 you wanted to view the Python package's SLs 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 SLs are available for use?
All available SLs are defined in the Product Definition Center (PDC) at: https://pdc.fedoraproject.org/rest_api/v1/component-branch-slas/
How do I set an SL on my branch?
The SL of your branch is set when you request your branch. For more information on requesting a branch, please review the How do I request a new package, a new branch, or to unretire a package? section of this FAQ.
Will there be an "f27" branch?
Yes, we will automatically create an "f27" branch that will in general act like the "f26" branch but with explicit SLs that match what we would expect from the implicit SLs of a traditional Fedora 27 release. This means packagers don't have to change their branching strategy if they don't want to. For f28, we intend to propose to FESCo that we do not create global "f28" branches for all packages.
(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. To arrive at this scenario, at some point we have to stop automatically creating new branches for new distro releases.)
In what circumstances should I request a new-style branch?
For context, go back to review Changes/ArbitraryBranching. Traditional Fedora dist-git branches are named in correspondence with a release of the distro. "New-style" branches allow packagers to name a branch "arbitrarily". See advice on choose a name in the next subsection.
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 SL 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 SL is lower than the SL of a release.
How should I name my branch?
At this time, there are no restrictions on how you name your branches except that they may not be derogatory or offensive; they may not violate the Fedora Community Code of Conduct.
Try to use branch names that best describe the SL you are trying to provide. For instance, if you maintain a package 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 informative and considerate when choosing names.
Requests for new branches will still pass through a member of the 'cvsadmin' group for approval. They may adopt more specific policy over time.
How do I pick an SL for my branch?
See this section of the Module guidelines for information on selecting the appropriate SLs.
How do I find the list of modules that pull in my branch?
Try this script.