* Avi Kivity <avi@xxxxxxxxxx> wrote: > On 03/18/2010 11:22 AM, Ingo Molnar wrote: > >* 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. > > 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. My own experience and everyone i've talked about such topics (developers and distro people) about feature contribution tells the exact opposite: it's much harder to contribute features to multiple packages than to a single project. kernel+library+app features take forever to propagate, and there's constant fear of version friction, productization deadlines are uncertain and ABI messups are frequent as well due to disjoint testing. Also, each component has essential veto power: so if the proposed API or approach is opposed or changed in a later stage then that affects (sometimes already committed) changes. If you've ever done it you'll know how tedious it is. This very thread and recent threads about KVM usability demonstrate the same complications. 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
