On Wed, Sep 08, 2010 at 10:44:27AM +0200, Andreas Schwab wrote: > "Richard W.M. Jones" <rjo...@redhat.com> writes: > > > For libguestfs I'm doing it manually. I have my own git repo which is > > a clone of the upstream libguestfs git repo. In that git repo I have > > the base stable version (eg. 1.4.3) plus cherry-picked patches on top > > of that. I use 'git rebase' when a new stable version comes out, and > > 'git format-patch' to generate the actual patches which go into Fedora > > git. At the moment I hand-edit the spec file to update the list of > > patches, but eventually the plan would be to generate the list of > > patches in the spec file too. > > glibc takes a slightly different approach. The fedora-specific changes > are maintained in a branch. When I prepare a new fedora build I merge > master into the fedora branch, run "make srpm" to build an srpm that > contains the fedora changes in a single patch, and "fedpkg import" it > into fedora git.
Yes, there is the question about whether to squash the patches, either into a single patch, or into fewer logical changes. In libvirt & libguestfs we took the decision to keep a 1-1 mapping with upstream git patches. The advantage is it is easy to see if a particular commit has gone into the SRPM. The disadvantage is you end up with a lot of patches in the SRPM ... In libguestfs I have tried to reduce the problem by documenting what logical changes have been backported (where "logical change" ~~ "group of patches implementing a feature or fix"). Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into Xen guests. http://et.redhat.com/~rjones/virt-p2v -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
