On Thu, Dec 6, 2018 at 3:54 PM Ken Dreyer <ktdreyer@xxxxxxxxxxxx> wrote: > > 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 :) > I consider rdopkg a nice compromise between the differing models. It's a shame that rdopkg is behind the terrible contribution process that is RDO/OpenStack (gerrit, though at least that's better than mail queues), otherwise it'd replace my existing tooling for maintaining my more complex packages. I also quibble a bit about it being licensed ASL 2.0 (as that makes it tricky to integrate with the rest of my tooling), but meh. The rdopkg model also permits working with the native VCS, whatever it may be (Git, Mercurial, etc.), while still exporting cleanly to Dist-Git. It also doesn't require us to actually support all the necessary Git features for Git repos in Pagure today. In fact, I had been discussing with the rdopkg author the idea of using it for Mageia a couple years ago to replace mgarepo, though unfortunately he disappeared off the face of the earth after our first conversations, so that never went anywhere. -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ 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
