Daniel, thank you for sharing your experience!
More comments inline.
On Wed, Apr 14, 2021 at 5:26 PM Daniel P. Berrangé <berrange(a)redhat.com> wrote:
On Wed, Apr 14, 2021 at 04:53:06PM +0200, Vitaly Zaitsev via devel wrote:
> On 14.04.2021 16:27, Tomas Tomecek wrote:
> > Could you, please, be more constructive and say what the actual
> > problems are for you with such repositories?
> 1. Some upstream repositories (Qt, Chromium, Linux kernel) are very huge
> (more than 100 GiB). I don't want to download them from upstream and then
> upload to Fedora.
Fedora kernel is already being maintained like this:
> 2. Keeping such huge repositories will take up a lot of disk
space on the
> maintainer's computers.
Bear in mind that many maintainers already use a source-git workflow with
Fedora, and are also involved in the upstream project. IOW, they already
have these upstream repos present locally, and also be hosting it in some
remote git server outside normal Fedora dist-git.
source-git isn't proposed to be forced on all packages, and drive-by
contributors can also take a shallow clone instead of fetching all
history. Any possible "fedpkg" integration could potentially default
to a shallow clone.
Agreed, dist-git isn't going anywhere and with the source-git
workflow, we still want to preserve the rel-eng/proven-packager
workflow in dist-git. The source-git repos should make it way more
convenient for maintainers to track downstream patches, as you
> 3. Rebase problem. Maintainers will need do a manual rebase on
> upstream release/commit. Rebasing to the next major version will be a
> serious problem for the projects with a lot of of downstream patches.
That's not my experiance. The cases where I know of maintainers are
using a source-git model with Fedora / RHEL already, are doing so
precisely because it makes ongoing maint and rebasing waaaaay easier
than with dist-git, especially when there are alot of downstream
patches (100's or even 1000's).
+1, `git pull --rebase upstream $ref` is more convenient than trying
to fix downstream patches in whatever obscure way.
Shout out to rebase-helper which is trying to automate the patch files
rebase problem via a CLI utility:
> 4. Some project have a weird git workflow between minor
releases. I know at
> least one project that uses Git tags with cherry-picked and manually
> backported commits. Such detached tags cannot be merged into master branch
> without resolving merge conflicts.
I woudn't expect Fedora to track the git-master in most cases. You
generally still want Fedora to be base off releases, so you'd want
to track starting fron a release tag or branch.
Correct, the branches are meant to use upstream release git-tags as a base.
> 5. Force pushes must be enabled, which is too dangerous IMO.
There are several ways you can do source git and they don't all
imply force pushes, so I think this is probably inventing a
problem where none yet exists.
One example approach to source-git I've used...
Rather than having source-git branch names matching dist-git,
use a different naming convention that is based off the upstream
eg if upstream has v1.0 and v1.2 tags, I might have a 'v1.0-f33'
branch, and if I rebase Fedora to v1.2, then I'd just switch to
using a v1.2-f33 branch instead. The v1.0-f33 history remains
intact forever, no force push required to rebase to new version.
If upstream has stable branches v1.0-maint and v1.2-maint, then
v1.0-f33 branch might be initialized with v1.0-maint content.
If upstream adds more commits to v1.0-maint branch, then you
wouldn't force push v1.0-f33, you'd just do a git merge to pull
That's interesting: merge commits make it hard to work with the
git-history - how do you solve that? Daniel, does your tooling account
for a merge commit and is it able to still pick up commits and turn
them into patch files correctly?
Our current solution to rebases is to create new branches for every
> > I understand that upstream repositories can have a long
history - we
> > could optimize and have shallow copies or only fetch recent upstream
> > history if needed. Also, one would ideally only clone once and kept
> > fetching new changes.
> Do you want to force switch all Fedora packages to a new workflow?
There's no mention of forcing everyone to switch to source-git. Some
upstreams don't even use git.
100%, the workflow is optional, dist-git is staying and both workflows
should be compatible (to some extent, synchronizing downstream patches
b/w the two would be tricky to figure out)