On Thu, Dec 6, 2018 at 6:12 AM Florian Weimer <fweimer@xxxxxxxxxx> wrote: > I'm worried that this kind of pointless work makes it hard to attract > talent. Florian, you might want to check out rdopkg. https://github.com/softwarefactory-project/rdopkg . It's a bit like fedpkg, in that it's a CLI with sub-commands. The idea is that you have three Git remotes: origin ssh://ktdreyer@xxxxxxxxxxxxxxxxxxxxxx/rpms/remctl patches git@xxxxxxxxxxx:ktdreyer/remctl upstream https://git.eyrie.org/git/kerberos/remctl.git The "origin" is dist-git, the "upstream" is obviously the upstream project, and the "patches" remote is a fork of upstream. You can maintain all your backports and cherry-picks in the "patches" remote, in "-patches" branches. So for rawhide, the dist-git branch is "master", so the patches branch would be "master-patches". This branch is the upstream point release tag, plus any downstream cherry-picks. The "rdopkg patch" command will automatically run git-format-patch with the proper commit range and inject the patch series into the .spec file. It will update the %changelog and dist-git commit message as well. We use that to maintain several hundred cherry-picks across many different releases of Ceph. The RDO teams use it to help maintain over 800 packages. (I have "rdopkg patch" running in Jenkins also, so the rest of my team can just do "git cherry-pick -x" for their backports and not have to touch packaging or dist-git.) We get the strong history preservation guarantees that dist-git always gives us, along with the flexibility to rebase or edit patch series quickly. The patches remote can live anywhere. It is similar to Debian's patch-queue concept from git-buildpackage. Even if you maintain a package in Fedora that has just one or two patches, it is really handy to use rdopkg to manage that. You can jump back and forth between the "-patches" branch and the dist-git branch. The ability to quickly rebase or amend patches makes packaging fun again (for me anyway :) - Ken _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
