OK, I've got a basic initial port of the xen package up to 4.4.0. But before I post that, I wanted to get comments on a new method of managing the Xen part of the patchqueue. You can find the RFC branch here:
repo: http://github.com/gwd/sig-virt-xen branch: out/git-am-patchqueue-RFC-v1
The basic idea is to put as much as possible into a 'git am' file. This file can easily be imported into git on top of a Xen git repository with "git am [filename]", rebased / edited like any branch, and the exported again with "git format-patch -N --stdout [release-tag]".
I've got a copy of the Xen repo with the patchqueue applied as a branch here:
repo: http://github.com/gwd/xen branch: centos/pq/4.2.4-v1
Unfortunately this only works for patches to things in the core Xen repo; patches to qemu, or the out-of-tree blktap will need to be managed separately still. However, at the moment those patches are kind of small.
Having the patchqueue in this format made rebasing to 4.4 a *lot* easier.
Any thoughts?
-George
On 05/15/2014 07:05 PM, George Dunlap wrote:
OK, I've got a basic initial port of the xen package up to 4.4.0. But before I post that, I wanted to get comments on a new method of managing the Xen part of the patchqueue. You can find the RFC branch here:
repo: http://github.com/gwd/sig-virt-xen branch: out/git-am-patchqueue-RFC-v1
The basic idea is to put as much as possible into a 'git am' file. This file can easily be imported into git on top of a Xen git repository with "git am [filename]", rebased / edited like any branch, and the exported again with "git format-patch -N --stdout [release-tag]".
I've got a copy of the Xen repo with the patchqueue applied as a branch here:
repo: http://github.com/gwd/xen branch: centos/pq/4.2.4-v1
Unfortunately this only works for patches to things in the core Xen repo; patches to qemu, or the out-of-tree blktap will need to be managed separately still. However, at the moment those patches are kind of small.
Having the patchqueue in this format made rebasing to 4.4 a *lot* easier.
assume that we have a git repo per package, then the deps ( like qemu ?pxe etc ) could also use the same process ?
Also, would it make sense to consolidate this queue under the github.com/CentOS/<package> repo ?
I'm also thinking that we might need a process like this for pretty much everyone else - there isnt a precidence for the SIG's in this regard as yet ( and anecdotally, we use a more manual version of exactly the same process for handling branding/blacklists in the centos distro rpms queue as well ).
- KB
On Tue, May 20, 2014 at 9:42 AM, Karanbir Singh mail-lists@karan.org wrote:
On 05/15/2014 07:05 PM, George Dunlap wrote:
OK, I've got a basic initial port of the xen package up to 4.4.0. But before I post that, I wanted to get comments on a new method of managing the Xen part of the patchqueue. You can find the RFC branch here:
repo: http://github.com/gwd/sig-virt-xen branch: out/git-am-patchqueue-RFC-v1
The basic idea is to put as much as possible into a 'git am' file. This file can easily be imported into git on top of a Xen git repository with "git am [filename]", rebased / edited like any branch, and the exported again with "git format-patch -N --stdout [release-tag]".
I've got a copy of the Xen repo with the patchqueue applied as a branch here:
repo: http://github.com/gwd/xen branch: centos/pq/4.2.4-v1
Unfortunately this only works for patches to things in the core Xen repo; patches to qemu, or the out-of-tree blktap will need to be managed separately still. However, at the moment those patches are kind of small.
Having the patchqueue in this format made rebasing to 4.4 a *lot* easier.
assume that we have a git repo per package, then the deps ( like qemu ?pxe etc ) could also use the same process ?
I don't see why not -- although we could just "fault them in" lazily as-needed.
Also, would it make sense to consolidate this queue under the github.com/CentOS/<package> repo ?
I don't really understand the question. I was assuming the workflow would be:
* George something on github.com/gwd/sig-virt-xen * George sends pull request to github.com/CentOS/sig-virt-xen (possibly cc'ing centos-virt mailing list) * Opportunity for discussion, review, objections, suggestions, &c * Eventually it gets pulled into CentOS/sig-virt-xen * ...then pulled into git.centos.org for testing.
Did you mean something else?
I'm also thinking that we might need a process like this for pretty much everyone else - there isnt a precidence for the SIG's in this regard as yet ( and anecdotally, we use a more manual version of exactly the same process for handling branding/blacklists in the centos distro rpms queue as well ).
Well each SIG can come up with a method of managing patches that works for them; but feel free to suggest this to people. :-)
-George
-
George Dunlap -
Karanbir Singh