Using git for patch management in Fedora

[Daniel P. Berrange]

On Tue, Nov 19, 2013 at 10:22:42AM +0000, Richard W.M. Jones wrote:
> Several packages are using git for patch management.  eg:
> 
> http://pkgs.fedoraproject.org/cgit/erlang.git/tree/erlang.spec#n46
> http://pkgs.fedoraproject.org/cgit/libguestfs.git/tree/libguestfs.spec?h=f20#n22
> http://pkgs.fedoraproject.org/cgit/qemu.git/tree/
> http://pkgs.fedoraproject.org/cgit/ocaml.git/tree/ocaml.spec#n16
> 
> Some of these packages have invented home-brewed methods to generate
> the Patch lines in the spec file, eg:
> 
> http://pkgs.fedoraproject.org/cgit/erlang.git/tree/otp-get-patches.sh
> http://pkgs.fedoraproject.org/cgit/libguestfs.git/tree/copy-patches.sh?h=f20
> 
> More importantly, all are using random git repositories to store the
> exploded tree.  This makes it difficult for co-maintainers and proven
> packagers to fit in with the patch management chosen by the
> maintainer.  Usually they won't have access to the git repository for
> these patches, making it difficult to add patches and near impossible
> to upgrade to a new version.

Yep, I've done the same thing for all the packages I maintain in Fedora
and RHEL too. It makes maintaining RPMs soo much easier, particularly
when you have lots of patches to manage. The script I use is 

  http://pkgs.fedoraproject.org/cgit/libvirt-sandbox.git/tree/update-patches.pl



> I think that git is an excellent way to manage patches, but we ought
> to think about formalizing this process.  I think the goals should be:
> 
> (1) A git repository is used that co-maintainers and proven packagers
> automatically have access to.
> 
> (2) A single method & script is used to update the patches in the spec file.
> 
> Although there is already a git repository satisfying (1) above,
> namely dist-git, it isn't suitable for storing the exploded tree since
> commits to the spec file would conflict with commits (patches) to the
> tree.  So either a separate side repository which packages could
> opt-in to, or perhaps a separate branch of the same git repo could be
> used.  I think using a branch would require no additional
> infrastructure.
> 
> For (2) I would suggest a lightweight technique where git-managed
> patches are marked in the spec file using:
> 
>   ### GIT-MANAGED-PATCHES ###
>   ### END-GIT-MANGED-PATCHES ###
> 
> and a simple script that replaces everything between those marks with
> PatchXXXX lines.  The script could be adapted from copy-patches.sh
> (see above).
> 
> To apply the patches, a standard RPM macro could be created:
> 
>   %prep
>   %setup -q
>   %{git_apply_patches}
> 
> which would expand to something like:
> 
>   git init
>   git config user.email "%{name}-owner at fedoraproject.org"
>   git config user.name "%{name}"
>   git add .
>   git commit -a -q -m "%{version} baseline"
>   git am %{patches}
> 
> Thoughts on this?

It would certainly be nice to formalize things in this area given that
so many people are re-inventing the wheel here.

I agree that I wouldn't want to have the upstream GIT repo merged into
the Fedora dist-git repos, since that would increase their size by
many orders of magnitude.

It seems like we'd want to have a Fedora hosted parallel GIT repos for
tracking upstream GIT repos that are relevant to the Fedora RPMs.
Preferrably something that could be automated so it auto-synchronizes
the upstream branches, so Fedora maintainers just need to create a new
branch and then cherry-pick -x the patches they need.

Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|