Re: [RFC] Unify KVM kernel-space and user-space code into a single project

[Avi Kivity <avi@redhat.com>]

On 03/18/2010 11:22 AM, Ingo Molnar wrote:
> * Avi Kivity<avi@redhat.com>  wrote:
>
>    
>>>   - move a clean (and minimal) version of the Qemu code base to tools/kvm/,
>>>     in the upstream kernel repo, and work on that from that point on.
>>>        
>> I'll ignore the repository location which should be immaterial to a serious
>> developer and concentrate on the 'clean and minimal' aspect, since it has
>> some merit.  [...]
>>      
> To the contrary, experience shows that repository location, and in particular
> a shared repository for closely related bits is very much material!
>
> It matters because when there are two separate projects, even a "serious
> developer" is finding it double and triple difficult to contribute even
> trivial changes.
>
> It becomes literally a nightmare if you have to touch 3 packages: kernel, a
> library and an app codebase. It takes _forever_ to get anything useful done.
>    

You can't be serious.  I find that the difficulty in contributing a 
patch has mostly to do with writing the patch, and less with figuring 
out which email address to send it to.

> Also, 'focus on a single thing' is a very basic aspect of humans, especially
> those who do computer programming. Working on two code bases in two
> repositories at once can be very challenging physically and psychically.
>    

Indeed, working simultaneously on two different projects is difficult.  
I usually work for a while on one, and then 'cd', physically and 
psychically, to the other.  Then switch back.  Sort of like the 
scheduler on a uniprocessor machine.

> So what i've seen is that OSS programmers tend to pick a side, pretty much
> randomly, and then rationalize it in hindsight why they prefer that side ;-)
>
> Most of them become either a kernel developer or a user-space package
> developer - and then they specialize on that field and shy away from changes
> that involve both. It's a basic human thing to avoid the hassle that comes
> with multi-package changes. (One really has to be outright stupid, fanatic or
> desperate to even attempt such changes these days - such are the difficulties
> for a comparatively low return.)
>    

We have a large number of such stupid, fanatic, desperate developers in 
the qemu and kvm communities.

> The solution is to tear down such artificial walls of contribution where
> possible. And tearing down the wall between KVM and qemu-kvm seems very much
> possible and the advantages would be numerous.
>
> Unless by "serious developer" you meant: "developer willing to [or forced to]
> waste time and effort on illogically structured technology".
>    

By "serious developer" I mean

  - someone who is interested in contributing, not in getting their name 
into the kernel commits list
  - someone who is willing to read the wiki page and find out where the 
repository and mailing list for a project is
  - someone who will spend enough time on the project so that the time 
to clone two repositories will not be a factor in their contributions
  - someone who will work on the uncool stuff like fixing bugs and 
providing interfaces to other tools

>> [...]
>>
>> Do you really think the echo'n'cat school of usability wants to write a GUI?
>> In linux-2.6.git?
>>      
> Then you'll be surprised to hear that it's happening as we speak and the
> commits are there in linux-2.6.git. Both a TUI and GUI is in the works.
>
> Furthermore, the numbers show that half of the usability fixes to tools/perf/
> came not from regular perf contributors but from random kernel developers and
> testers who when they build the latest kernel and try out perf at the same
> time (it's very easy because you already have it in the kernel repository - no
> separate download, no installation, etc. necessary).
>
> I had literally zero such contributions when (the precursor to) 'perf' was
> still a separate user-space project.
>
> You could have the same effect for Qemu: the latest bits in tools/kvm/ would
> be built by regular kernel testers and developers. The integration benefits
> dont just extend to developers, a unified project is vastly easier to test as
> well.
>
>    

Let's wait and see then.  If the tools/perf/ experience has really good 
results, we can reconsider this at a later date.

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