So, PkgDB now comes with a big fat warning saying:
"Attention! PkgDB will be replaced during the week of July 10th, 2017.
Please read the following for migration instructions:
If I go there I find no "migration instructions" whatsoever, the
pararagraph on "How Is PkgDB's Functionality Being Replaced" is
ridiculously short and points to a "Pagure over Dist-Git (placeholder
link)" which obviously points to nowhere. All these "to be written" in
the timeline for June (!) don't make me overly confident in that agenda.
Saying "Do something or else" without telling us "what" nor "what
is a really good way to put off contributors, but no good way to get
everyone in the boat for the move.
Really, I'm all in for weeding out the git branch madness that we have
now in dist-git (too many cherry-picks, insane merge directions) and I
do hope that entanglich branches from releases will help that purpose.
But please, take a step back and think about how and what you
communicate to packagers, that is "infra-users".
Adam Samalik venit, vidit, dixit 04.06.2017 12:43:
This enables us to have branches that make more sense for individual
packages - so we can save work by having just one branch for one version
acrsoss releases, or to offer more versions or "streams". A slide 
from my recent talk demonstrates the possibilities - and also shows why
branches are not always just versions. It talks about modules, but it's
the same for packages, too.
I like your work, guys! If you want to use any of the graphic from my
slides in a documentation or anywhere else, please feel free to do so. I
can even tweak it if you like.
On Fri, May 26, 2017 at 9:42 PM, Ralph Bean <rbean(a)redhat.com
As part of the Factory 2.0 and Modularity efforts, we’ve been
developing a plan to migrate to an “arbitrary” branching model from
our current model of one branch per release (as had been discussed at
Flock and DevConf).
The main motivation behind this is to enable functionality required by
Modularity and to ultimately reduce some package maintenance
burden. For some packages, it makes sense to have only a single branch
that feeds into multiple releases. For other packages, it makes sense
to have multiple branches which correlate with multiple upstream minor
releases. Today, our source branches are tied to the distro release,
via PkgDB. We want to decouple that and use modules to put it all
back together again.
To make this happen requires significant infrastructure changes. Our
proposed plan is to decommission PkgDB entirely and to replace it
with a combination of PDC and pagure over dist-git. (Tangentially,
getting pagure over dist-git to play nicely with PkgDB was a
challenge. This route gets us to a pull-request interface for spec
We have brought this Change to FESCo who expressed general
agreement on the project but also concern that the community may be
caught by off guard by the removal of PkgDB. As part of this change,
we have proposed a timeline that outlines the steps we plan to take
to actually proceed with the migration. Please review that if you have
time and provide feedback. We are most concerned with missing
scripts/tools that may rely on PkgDB’s API. If you can think of any
that we may have overlooked, please let us know and we will add it to
We are meeting again with FESCo next Friday, June 2nd, where a
decision will be made on the Change. Any feedback before that would be
Ralph and Matt,
From the so-called Factory 2.0 team
devel-announce mailing list --
To unsubscribe send an email to
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org