kvm repository unification

Quoted 1 line

Quoted 1 line

On Tue, Mar 20, 2007 at 8:13 AM, in message <45FFCFD7.5000107-atKUWr5tajBWk0Htik3J/[email protected]>,

Managing userspace in subversion and the kernel in git is proving to be quite a pain. Branches have to be maintained in parallel, tagging is awkward, and bisection is fairly impossible.

What do people think about putting libkvm and qemu into the usr directory of the kernel repo? It's slightly wierd but will make life generally easier.

Quoted 4 lines · Avi Kivity

Managing userspace in subversion and the kernel in git is proving to be quite a pain. Branches have to be maintained in parallel, tagging is awkward, and bisection is fairly impossible.

Quoted 4 lines

What do people think about putting libkvm and qemu into the usr directory of the kernel repo? It's slightly wierd but will make life generally easier.

That does sounds a little weird, though I know what you mean about managing the two disparate repos. I think having one repo makes sense, but I dont know if putting that in the kernel tree is the right direction. Is there another way? For instance, go back to using /kernel, /libkvm, and /qemu from SVN and submitting patches/drops to the kernel tree. I am not advocating SVN over GIT either...the new unified repo could be whatever. I think the most important thing is having it in one place.

Quoted 1 line

Quoted 1 line

On Tue, Mar 20, 2007 at 8:37 AM, in message <45FFD598.2050403-atKUWr5tajBWk0Htik3J/[email protected]>,

Quoted 6 lines · Gregory Haskins

Quoted 4 lines · Avi Kivity

Managing userspace in subversion and the kernel in git is proving to be quite a pain. Branches have to be maintained in parallel, tagging is awkward, and bisection is fairly impossible.

Quoted 7 lines

Quoted 4 lines

What do people think about putting libkvm and qemu into the usr directory of the kernel repo? It's slightly wierd but will make life generally easier.

That does sounds a little weird, though I know what you mean about managing

the two disparate repos. I think having one repo makes sense, but I dont know if putting that in the kernel tree is the right direction. Is there another way? For instance, go back to using /kernel, /libkvm, and /qemu from SVN and submitting patches/drops to the kernel tree. I am not advocating SVN over GIT either...the new unified repo could be whatever. I think the most important thing is having it in one place.

Quoted 1 line

With the paravirt stuff we are placing things all over the kernel, and tighter integration with the scheduler and mm infrastructure will make having a kernel/ directory impossible.

So if you can make the integration with the kernel tree work from a political standpoint, I'd say go for it.

Quoted 1 line

Quoted 1 line

On Tue, Mar 20, 2007 at 9:02 AM, in message <45FFDB50.7050105-atKUWr5tajBWk0Htik3J/[email protected]>,

Quoted 1 line · Gregory Haskins

So if you can make the integration with the kernel tree work from a

political standpoint, I'd say go for it.

Quoted 1 line

There's really no political issue, as it's completely internal to kvm development. It just seemed wierd and wrong so I thought I'd see if someone has a better idea.

Managing userspace in subversion and the kernel in git is proving to be quite a pain.  Branches have to be maintained in parallel, tagging is awkward, and bisection is fairly impossible.

What do people think about putting libkvm and qemu into the usr directory of the kernel repo?  It's slightly wierd but will make life generally easier.

Quoted 7 lines

Managing userspace in subversion and the kernel in git is proving to be quite a pain.  Branches have to be maintained in parallel, tagging is awkward, and bisection is fairly impossible.

What do people think about putting libkvm and qemu into the usr directory of the kernel repo?  It's slightly wierd but will make life generally easier.

In my projects, I tend to never have a complete kernel tree under revision control, only patches in a form suitable for 'quilt mail'. This makes it a lot easier to see how the patches will look when they get merged upstream.

If you like, I can give you a copy of the scripts that I use to maintain the quilt tree I maintain for the cell kernel.

	Arnd <><

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
kvm-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Quoted 8 lines · Avi Kivity

Managing userspace in subversion and the kernel in git is proving to be quite a pain. Branches have to be maintained in parallel, tagging is awkward, and bisection is fairly impossible.

What do people think about putting libkvm and qemu into the usr directory of the kernel repo? It's slightly wierd but will make life generally easier.

In my projects, I tend to never have a complete kernel tree under revision control, only patches in a form suitable for 'quilt mail'. This makes it a lot easier to see how the patches will look when they get merged upstream.

Quoted 12 lines · Arnd Bergmann

Quoted 9 lines · Avi Kivity

Managing userspace in subversion and the kernel in git is proving to be quite a pain. Branches have to be maintained in parallel, tagging is awkward, and bisection is fairly impossible.

What do people think about putting libkvm and qemu into the usr directory of the kernel repo? It's slightly wierd but will make life generally easier.

Quoted 7 lines

In my projects, I tend to never have a complete kernel tree under revision control, only patches in a form suitable for 'quilt mail'. This makes it a lot easier to see how the patches will look when they get merged upstream.

How does that work with multiple developers?

I find that git's cherry-pick and history editing features to be almost as easy to use as quilt when it comes to managing patches; added to the ease of distributed development I think it has a clear edge over quilt.

[I used to use quilt to cherry pick out of the subversion tree. Nowadays I just cherry pick what I want to send upstream and put it on a branch]

Quoted 1 line

I think a single repository with libkvm and a QEMU and kernel patch queue (quilt or mq, it doesn't matter to me) would be best.

Patches in the main queue would get folded upstream quickly (hopefully). Devs would submit new patches that you may choose to either add to the queue or fold an existing patch.

I actually find that it's easier to do merging with a patch queue than by directly committing.

How does that work with multiple developers?

I find that git's cherry-pick and history editing features to be almost as easy to use as quilt when it comes to managing patches; added to the ease of distributed development I think it has a clear edge over quilt.

[I used to use quilt to cherry pick out of the subversion tree. Nowadays I just cherry pick what I want to send upstream and put it on a branch]

Quoted 2 lines · Avi Kivity

How does that work with multiple developers?

You need a set of well-understood rules if more than one person has commit access to the repository.

The most simple rule would be that everyone just adds patches at the end of the quilt series. When you submit something upstream, you can then still decide to fold multiple patches.

As an extension, it is possible to allow changing a previous patch by replacing it with a forked one. E.g. kvm-add-foo.patch can get replaced by kvm-add-foo-2.patch, when that contains an improved version.

I've never tried the cherry pick approach, since my team for historic reasons still uses CVS, which doesn't have changesets. If it works well for you, I guess you shouldn't change.

Quoted 9 lines · Arnd Bergmann

Quoted 3 lines · Avi Kivity

How does that work with multiple developers?

You need a set of well-understood rules if more than one person has commit access to the repository.

Quoted 5 lines

The most simple rule would be that everyone just adds patches at the end of the quilt series. When you submit something upstream, you can then still decide to fold multiple patches.

That essentially mimics the subversion workflow, where a commit is equivalent to appending a patch.

Quoted 6 lines

As an extension, it is possible to allow changing a previous patch by replacing it with a forked one. E.g. kvm-add-foo.patch can get replaced by kvm-add-foo-2.patch, when that contains an improved version.

Ewww, diffs of patches! Better to have separate 'add cleanup patch' and 'fold-with-no-change' steps.

Quoted 5 lines

I've never tried the cherry pick approach, since my team for historic reasons still uses CVS, which doesn't have changesets. If it works well for you, I guess you shouldn't change.

I'm mostly comfortable by now with git, but there are others here who are sweating blood over it, so I'm interested in alternatives.

I find using a patch queue useful though for submitting things upstream. A good example is our QEMU changes. It's a real pain to break apart the SVN history into individual patches.

I tend to keep the patches in revision control too.

In the paravirt_ops queue, they keep a file that contains the changeset ID of whatever the patches are based off of. That tends to help with respect to going backwards in history.

Mercurial is *much* friendlier than git. Linus' tree is available via mercurial too.

It should be pretty easy to maintain the KVM changes as a patch queue against Linus' tree.

We could have Makefile magic too to clone a kernel/qemu tree and apply the patch queue that a top level "make" still did the right thing.

Quoted 3 lines

I find using a patch queue useful though for submitting things upstream.  A good example is our QEMU changes.  It's a real pain to break apart the SVN history into individual patches.

Why not just extract diffs with 'svn diff'?  That's what I did/do.

Quoted 4 lines · Avi Kivity

Quoted 4 lines

I find using a patch queue useful though for submitting things upstream. A good example is our QEMU changes. It's a real pain to break apart the SVN history into individual patches.

Quoted 2 lines

Why not just extract diffs with 'svn diff'? That's what I did/do.

Just a few random thoughts on this:

- if you have multiple changesets in svn that you want to submit as a single patch, it's useful to only have to do the folding once.

- Having the changeset as a patch means that multiple developers can add their Acked-by: and Signed-off-by: by editing the description in the patch file, while you can't easily change an existing changeset comment. E.g. I require everyone with write access to add their own Signed-off-by:, while I add mine when I look at the patches I want to send out.

- When a developer checks in a new changeset, I found that often there are formal problems in it, e.g. the comment doesn't follow the rules for kernel commits, or there is some coding style problem. In a patch file, you can trivially fix that.

Managing userspace in subversion and the kernel in git is proving to be quite a pain. Branches have to be maintained in parallel, tagging is awkward, and bisection is fairly impossible.

What do people think about putting libkvm and qemu into the usr directory of the kernel repo? It's slightly wierd but will make life generally easier.