Why PkgDB Is Being Decommissioned
PkgDB in general 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 these 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 we need a new way of branching in dist-git to enable this functionality.
As mentioned above, since PkgDB was written with the old way of branching in mind, there ended up being two paths forward. We could significantly rewrite PkgDB to work the new way of branching, or we could decommission it and use other tooling that is easier to maintain. After talking with developers in the Fedora community, the latter seemed to require less support/maintenance work in the end.
How Is PkgDB's Functionality Being Replaced?
PkgDB has two primary functions: providing package ACLs, and package related ticketing. ACLs will now 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 ticketing, that 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 Release Engineering.
For more information 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.