Hi,
For github-hosted upstreams, you can suffix some URLs with '.diff' or
'.patch'. I have used it for vcsh [1] (which btw is a tool I'd
recommend to anyone who keeps dotfiles in sync on several machines). I
did that on a pull request, but you can also do that on a commit (for
cherry-picking) [2] and github even allows you to use a shortened
sha-1 [3].
Of course this doesn't prevent you from putting the patch files in the
package's repository, which seems to be the main issue. But one could
write a script to fetch such patches at %prep time.
Dridi
[1]
http://pkgs.fedoraproject.org/cgit/vcsh.git/tree/vcsh.spec
[2]
https://github.com/RichiH/vcsh/commit/c0d0f80513f26e7b6a485bbd6239191a3fe...
[3]
https://github.com/RichiH/vcsh/commit/c0d0f80.diff
On Wed, Nov 20, 2013 at 10:19 AM, Richard W.M. Jones <rjones(a)redhat.com> wrote:
On Tue, Nov 19, 2013 at 03:36:54PM -0800, Toshio Kuratomi wrote:
> One note though, I think that in the past one of the discussion points we've
> foundered on is whether we want to be mirroring upstream's git repo or
> (approximately) upstream's releases. I think that's probably where we'd
> need to start discussion.
From the point of view of patch management, I have a strong view here:
We should be mirroring upstream's git, if they have one.
The reason is that it makes it trivial to cherry pick upstream patches
on top of the Fedora branch.
So I'd arrange it by having a straight mirror of upstream, then have
our own 'fNN-branch' branches which contain the upstream releases
(ideally from upstream tags if they are using git sensibly) + our
cherry picked patches.
Rich.
--
Richard Jones, Virtualization Group, Red Hat
http://people.redhat.com/~rjones
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW
--
devel mailing list
devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct:
http://fedoraproject.org/code-of-conduct