On 03/18/2010 12:50 PM, Ingo Molnar wrote:
* Avi Kivity<avi@xxxxxxxxxx> wrote:
The moment any change (be it as trivial as fixing a GUI detail or as
complex as a new feature) involves two or more packages, development speed
slows down to a crawl - while the complexity of the change might be very
low!
Why is that?
It's very simple: because the contribution latencies and overhead compound,
almost inevitably.
It's not inevitable, if the projects are badly run, you'll have high
latencies, but projects don't have to be badly run.
If you ever tried to implement a combo GCC+glibc+kernel feature you'll know
...
Even with the best-run projects in existence it takes forever and is very
painful - and here i talk about first hand experience over many years.
Try sending a patch to qemu-devel@, you may be pleasantly surprised.
I the maintainers of all packages are cooperative and responsive, then the
patches will get accepted quickly. If they aren't, development will be
slow. [...]
I'm afraid practice is different from the rosy ideal you paint there. Even
with assumed 'perfect projects' there's always random differences between
projects, causing doubled (tripled) overhead and compounded up overhead:
- random differences in release schedules
- random differences in contribution guidelines
- random differences in coding style
None of these matter for steady contributors.
[...] It isn't any different from contributing to two unrelated kernel
subsystems (which are in fact in different repositories until the next merge
window).
You mention a perfect example: contributing to multipe kernel subsystems. Even
_that_ is very noticeably harder than contributing to a single subsystem - due
to the inevitable buerocratic overhead, due to different development trees,
due to different merge criteria.
So you are underlining my point (perhaps without intending to): treating
closely related bits of technology as a single project is much better.
Obviously arch/x86/kvm/, virt/ and tools/kvm/ should live in a single
development repository (perhaps micro-differentiated by a few topical
branches), for exactly those reasons you mention.
How is a patch for the qemu GUI eject button and the kvm shadow mmu
related? Should a single maintainer deal with both?
--
error compiling committee.c: too many arguments to function
--
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
