Using git for patch management in Fedora

[Richard W.M. Jones]

On Tue, Nov 19, 2013 at 07:27:20PM +0200, Alek Paunov wrote:
> On 19.11.2013 16:20, Daniel P. Berrange wrote:
> >On Tue, Nov 19, 2013 at 01:29:06PM +0000, Richard W.M. Jones wrote:
> >>On Tue, Nov 19, 2013 at 01:39:50PM +0100, Karel Zak wrote:
> >>>We have to learn fedpkg to do all the magic ;-) Something like
> >>>
> >>>add remote git tree with exploded tree:
> >>>
> >>>   fedpkg exploded-tree add ssh://git.fedorahosted.org/git/foo.git
> >>
> >>This is all great, but the problem is that co-maintainers and
> >>provenpackagers need to be (automatically if possible) added to the
> >>fedorahosted tree.  Otherwise there's a big extra step for them if
> >>they want to follow the package owner's preferred patching system.
> >
> >Ideally the GIT SCM request added to bugzilla when reviews are
> >approved would have a "Upstream GIT URL" option and would setup
> >a clone of this, and create branches for the fedora releases,
> >and apply the same permissioning model from dist-git branches
> >of the same names.
> >
> 
> What about intermediate step: optional "fNN-upstream" branch in
> addition to fNN, containing relevant upstream revision as git
> submodule (preferably referencing fedorahosted mirror, but initially
> also allowing "external" clones)?

The real issue is still access control.  The "upstream" repo should be
accessible read/write by the same people who are permitted to commit
to the dist-git repo.  It's my understanding that git submodules don't
necessarily help with that.

It's a shame that git can't reference an external repo (for history).
That would massively reduce the amount of storage needed.  [AFAIK ...]

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 KVM guests.
http://libguestfs.org/virt-v2v