* Avi Kivity <avi@xxxxxxxxxx> 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. 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. 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.) 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". > [...] > > 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. Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
