On Tue, May 12, 2020 at 1:45 AM clime <clime(a)fedoraproject.org> wrote:
>
> Ken, would it be, please, possible to provide links to the patch
> branches and mentioned dist-git repos. I would like to have a closer
> look.
Sure. I can't share the links to the RH Ceph Storage dist-git repos,
so I will give one example where I used rdopkg in Fedora recently.
Here is an example where I bumped the version of a Python package and
included some cherry-picked patches:
https://src.fedoraproject.org/rpms/python-jenkins-job-builder/c/78b70d24c...
At first glance, the two new patches I included there look like the
output from "git-format-patch", and that is because rdopkg wraps
git-format-patch for some operations. rdopkg automatically inserted
those into the .spec file, and it also formats them with some
compatibility options to preserve the .patch file formats between RHEL
7's Git 1.8.3.1 + RHEL 8's Git 2.18.2 + Fedora's Git, so that it does
not matter what OS the packager is running.
So that's the change in "master" (dist-git's rawhide branch), and
there is a corresponding "master-patches" branch to go along with
that:
https://fedorapeople.org/cgit/ktdreyer/public_git/python-jenkins-job-buil...
In my dist-git clone on my laptop, I have three remotes, set up like this:
$ git remote -v
origin ssh://ktdreyer@pkgs.fedoraproject.org/rpms/python-jenkins-job-builder
(fetch)
origin ssh://ktdreyer@pkgs.fedoraproject.org/rpms/python-jenkins-job-builder
(push)
patches
ssh://fedorapeople.org/home/fedora/ktdreyer/public_git/python-jenkins-job...
(fetch)
patches
ssh://fedorapeople.org/home/fedora/ktdreyer/public_git/python-jenkins-job...
(push)
upstream
https://opendev.org/jjb/jenkins-job-builder.git (fetch)
upstream
https://opendev.org/jjb/jenkins-job-builder.git (push)
"rdopkg new-version" will update to the latest upstream version for
me. Specifically it looks at the upstream repo, finds the latest Git
tag, parses that tag string into a number, writes that number into the
.spec file, downloads and uploads the new upstream tarball, etc. It
will also rebase my "patches" branch for me and edit the Patch entries
as necessary.
I haven't done that today for the sake of this example, but at some
point in the future I will run "rdopkg new-version", and it will pull
in 3.3.0 and eliminate those two patches, since they're both included
in version 3.3.0 upstream.
In fact, you can try it on your computer if you set up the Git clones
like I've done above. If you run "rdopkg new-version", then rdopkg
will rewrite the "master-patches" branch, and then prompt you to
force-push this to the "patches" remote. You won't have SSH access to
push to my
fedorapeople.org repo, so just imagine that is a team repo
where many people on my team can push :) This just a really simple
example with two patches in one small package.
Ceph we do this at a slightly different point of time. We use
"rdopkg tag-patches" to save each of the "patches" refs that
we've
translated into patch series in dist-git. Each Git tag is the NVR of
the package.
When you do rdopkg new-version and you are asked to force push, is
also the current master-patches HEAD tagged with the current package
NVR?
Somewhere I was expecting to see a lot of NVR tags for past sate of
master-patches (i assume, you could have also f32-patches,
f31-patches, epel8-patches, ... ?) but I don't see those tags :) that
would form the mentioned "history of histories".
Thanks again
clime
>
> - Ken
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct: