On Thu, 2020-05-14 at 14:30 +0200, Ondřej Lysoněk wrote:
I was originally excited about source-git, however currently I
an approach to source-git that would work for me and I don't think I'd
use it if it became available. And frankly, I think I wouldn't want
other people using it either because it would make understanding their
So, another way that could work, with minimal tooling is that we keep
the master branch strictly mirroring whatever upstream branch we
follow, and then for each fedora release you have a fedora branch where
you add the downstream stuff (spec file, patches, etc..).
Whenever you want to bring in a new upstream release you would update
the master tree to the release as tagged in the upstream master branch,
then you branch off a new fedora branch, say fedora33, and then you
cherry-pick on top of it whatever donwstream patches you had in the
The downside of this is that you cannot rebase mid-release. But then
you can always cherry-pick patches from a rebase master or from
upstream if you want.
And the branching, including cherry-picking of downstream patches can
be done automatically for the most part.
Some issues we normally have can also be handled with some discipline:
- upstream has code we cannot ship
- upstream does not use git
- other issues preventing mirroring
For all of these what we do is just use tarballs to create a diff from
current master and then do megacommits with the diff on the master
branch, and use the fedora branches just for the downstream patches and
Ideally the tarballs are referenced somehow in the master commit via
sha256 ids so that you can reconstruct exactly what was layered on top.
Those tarballs could also still be stored in the lookaside as a audit
trail as well if preferred.
The critical thing is how to ensure the master branch is sane, or
alternatively how to enable tooling that can switch around the master
branch should surgery be required such that the previous one is
preserved as a historical branch. (for example if upstream force
pushes, we still should have an audited command that saves the previous
master as a branch and then allows a rebase).
RHEL Crypto Team
Red Hat, Inc