Daniel, thank you for sharing your experience! More comments inline. On Wed, Apr 14, 2021 at 5:26 PM Daniel P. Berrangé <berrange@xxxxxxxxxx> 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: https://gitlab.com/cki-project/kernel-ark > > 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 describe. > > 3. Rebase problem. Maintainers will need do a manual rebase on every > > 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: https://github.com/rebase-helper/rebase-helper > > 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 > version primarily. > > 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 > them in. 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 upstream release. > > > 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) > Regards, > Daniel > -- > |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| > |: https://libvirt.org -o- https://fstop138.berrange.com :| > |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :| > _______________________________________________ > devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx > Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx > Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
