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. > > 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. > 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). > 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. > 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. > > 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. 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
