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. 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@xxxxxxxxxxxxxxxxx" git config user.name "%{name}" git add . git commit -a -q -m "%{version} baseline" git am %{patches} Thoughts on this? Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://people.redhat.com/~rjones/virt-top -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
