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 [1] 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 <> wrote:

As part of the Factory 2.0 and Modularity efforts[1], 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[2]).

The main motivation behind this is to enable functionality required by
Modularity[3] 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[4] is to decommission PkgDB entirely and to replace it
with a combination of PDC[5] 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
files quicker.)

We have brought this Change to FESCo[6][7][8] 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[9] 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
the timeline!

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
greatly appreciated.

Ralph and Matt,
From the so-called Factory 2.0 team


devel-announce mailing list --
To unsubscribe send an email to


Adam Šamalík
Software Engineer
Red Hat