kvm repository unification

kvm repository unification

[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.

-- 
error compiling committee.c: too many arguments to function


-------------------------------------------------------------------------
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

Re: kvm repository unification

[Gregory Haskins]

>>> On Tue, Mar 20, 2007 at  8:13 AM, in message <45FFCFD7.5000107-atKUWr5tajBWk0Htik3J/w@public.gmane.org>,
Avi Kivity <avi-atKUWr5tajBWk0Htik3J/w@public.gmane.org> wrote: 
> 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.


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.

-Greg

-------------------------------------------------------------------------
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

Re: kvm repository unification

[Avi Kivity]

Gregory Haskins wrote:
> Avi Kivity <avi-atKUWr5tajBWk0Htik3J/w@public.gmane.org> wrote: 
>   
>> 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.
>>     
>
>
> 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.
>   

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.


-- 
error compiling committee.c: too many arguments to function


-------------------------------------------------------------------------
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

Re: kvm repository unification

[Gregory Haskins]

>>> On Tue, Mar 20, 2007 at  8:37 AM, in message <45FFD598.2050403-atKUWr5tajBWk0Htik3J/w@public.gmane.org>,
Avi Kivity <avi-atKUWr5tajBWk0Htik3J/w@public.gmane.org> wrote: 
> Gregory Haskins wrote:
>> Avi Kivity <avi-atKUWr5tajBWk0Htik3J/w@public.gmane.org> wrote: 
>>   
>>> 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.
>>>     
>>
>>
>> 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.
>>   
> 
> 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.
> 


Thats a good point.  Note that having things sprinkled all over the kernel verses contained in one place (e.g. /drivers/kvm) doesnt preclude this model that I suggested per se.  But perhaps that is too messy to deal with.  I think getting them in one repo is more important than which repo.  So if you can make the integration with the kernel tree work from a political standpoint, I'd say go for it.

-Greg 

-------------------------------------------------------------------------
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

Re: kvm repository unification

[Avi Kivity]

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

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.


-- 
error compiling committee.c: too many arguments to function


-------------------------------------------------------------------------
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

Re: kvm repository unification

[Gregory Haskins]

>>> On Tue, Mar 20, 2007 at  9:02 AM, in message <45FFDB50.7050105-atKUWr5tajBWk0Htik3J/w@public.gmane.org>,
Avi Kivity <avi-atKUWr5tajBWk0Htik3J/w@public.gmane.org> wrote: 
> Gregory Haskins wrote:
>> So if you can make the integration with the kernel tree work from a 
> political standpoint, I'd say go for it.
>>   
> 
> 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.
> 


Ah, ok. I misunderstood, sorry.  I thought it was something that would get merged down.  Its a no brainer then.  I vote yes.

-Greg

-------------------------------------------------------------------------
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

Re: kvm repository unification

[Arnd Bergmann]

On Tuesday 20 March 2007, Avi Kivity wrote:
> 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

Re: kvm repository unification

[Dor Laor]

>On Tuesday 20 March 2007, Avi Kivity wrote:
>> 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 <><

So what you're suggesting is to use SVN as the primary source control tool.
All of the user space sources are kept in SVN. Kernel patches are kept in
SVN too; in quilt mail format. A set of scripts simplifies the job of getting the latest kernel git tree and applying the patches from the svn.

It sounds reasonable. Every developer has its git tree anyway, thus working 
With quilt can improve day to day merges.

>
>-------------------------------------------------------------------------
>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
>kvm-devel@lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/kvm-devel

-------------------------------------------------------------------------
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
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: kvm repository unification

[Avi Kivity]

Arnd Bergmann wrote:
> On Tuesday 20 March 2007, Avi Kivity wrote:
>   
>> 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.
>
>   

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]

-- 
error compiling committee.c: too many arguments to function


-------------------------------------------------------------------------
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

Re: kvm repository unification

[Anthony Liguori]

Avi Kivity wrote:
> Arnd Bergmann wrote:
>   
>> On Tuesday 20 March 2007, Avi Kivity wrote:
>>   
>>     
>>> 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.
>>
>>   
>>     
>
> 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]
>   

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.

Regards,

Anthony Liguori



-------------------------------------------------------------------------
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

Re: kvm repository unification

[Avi Kivity]

Anthony Liguori wrote:
>>  
>
> 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.
>

One issue I see with it is that it's impossible to go back in history, 
as the reference point to which patches are applied changes in time.  
Perhaps I could record the nearest git tag in a version controlled file, 
and the build scripts would checkout that tag from an associated kernel 
git repo.


-- 
error compiling committee.c: too many arguments to function


-------------------------------------------------------------------------
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

Re: kvm repository unification

[Arnd Bergmann]

On Tuesday 20 March 2007, Avi Kivity wrote:
> 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.

It is important though that you never change what a given patch does
without changing the name of the patch, otherwise you get into serious
trouble when merging changes done by someone else into the patch you
are working on.

> 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]

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.

	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

Re: kvm repository unification

[Avi Kivity]

Arnd Bergmann wrote:
> On Tuesday 20 March 2007, Avi Kivity wrote:
>   
>> 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.
>   

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

> 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.

> 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.


-- 
error compiling committee.c: too many arguments to function


-------------------------------------------------------------------------
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

Re: kvm repository unification

[Anthony Liguori]

Avi Kivity wrote:
> Arnd Bergmann wrote:
>   
>> On Tuesday 20 March 2007, Avi Kivity wrote:
>>   
>>     
>>> 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.
>>   
>>     
>
> That essentially mimics the subversion workflow, where a commit is 
> equivalent to appending a patch.
>   

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.

>> 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.
>
>   
>> 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.
>   

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.

Regards,

Anthony Liguori


-------------------------------------------------------------------------
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

Re: kvm repository unification

[Avi Kivity]

Anthony Liguori wrote:
>
> 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.

>
> 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.

Yeah.
 
>
> 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.

Okay.  I'll run it through the guys here and see what they think.


-- 
error compiling committee.c: too many arguments to function


-------------------------------------------------------------------------
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

Re: kvm repository unification

[Arnd Bergmann]

On Tuesday 20 March 2007, Avi Kivity wrote:
> > 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.

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.

	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

Re: kvm repository unification

[Avi Kivity]

Arnd Bergmann wrote:
> On Tuesday 20 March 2007, Avi Kivity wrote:
>   
>>> 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.
>>     
>
> 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.
>   

Well, one can do that with git too (on a separate branch).

> - 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.
>   

Again, you can with git.

> - 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.
>   

Unfortunately that happens a lot here, and it's definitely easier with 
quilt.

I'll hold off the decision and think about it some more.  Maybe the 
problem will go away, as Anthony suggests.


-- 
error compiling committee.c: too many arguments to function


-------------------------------------------------------------------------
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

Re: kvm repository unification

[David Beal]

Avi,

Should libc and a kernel be put into the same repository?  As far as I
have seen, the pain of migrating kvm into git was caused by interface
incompatibility between libkvm and kvm due to rapid interface flux.  I
think the interface should be well-defined, and boiled down, to the
point that libkvm as a userspace component could be replaced by another
userspace program without kvm noticing (and vice versa).  I think this
implies that integration between libkvm and kvm repositories is
unnecessary and possibly hindering potential stability.

As you suggest, storing a git reference to kvm along with libkvm
subversion code would be very handy during periods of rapid interface
development, in order to synchronize from libkvm to kvm, momentarily.
One might also create a subversion tag in libkvm repository that matches
a git reference or tag, to synchronize from kvm to libkvm.  Ultimately,
hammering out a written interface specification that keys on kernel
version numbers might work.

David Beal

On Tue, Mar 20, 2007 at 02:13:11PM +0200, Avi Kivity wrote:
> 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.


-------------------------------------------------------------------------
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