See my previous mail - what i see as the most healthy project model is to have
a full solution reference implementation, connected to a flexible halo of
plugins or sub-apps.
Firefox does that, KDE does that, and Gnome as well to a certain degree.
The 'halo' provides a constant feedback of new features, and it also provides
competition and pressure on the 'main' code to be top-notch.
The problem i see with KVM is that there's no reference implementation! There
is _only_ the KVM kernel part which is not functional in itself. Surrounded by
a 'halo' - where none of the entities is really 'the' reference implementation
we call 'KVM'.
This causes constant quality problems as the developers of the main project
dont have constant pressure towards good quality (it is not their
responsibility to care about user-space bits after all), plus it causes a lack
of focus as well: integration between (friendly) competing user-space
components is a lot harder than integration within a single framework such as
Firefox.
I hope this explains my points about modularization a bit better! I suggested
KVM to grow a user-space tool component in the kernel repo in tools/kvm/,
which would become the reference implementation for tooling. User-space
projects can still provide alternative tooling or can plug into this tooling,
just like they are doing it now. So the main effect isnt even on those
projects but on the kernel developers. The ABI remains and all the user-space
packages and projects remain.
Yes, i thought Qemu would be a prime candidate to be the baseline for
tools/kvm/, but i guess that has become socially impossible now after this
flamewar. It's not a big problem in the big scheme of things: tools/kvm/ is
best grown up from a small towards larger size anyway ...
Thanks,
Ingo
--
