[Qemu-devel] Re: An organizational suggestion

[Jan Kiszka <jan.kiszka@siemens.com>]

Andreas Färber wrote:
> 
> Am 03.06.2008 um 12:00 schrieb Jamie Lokier:
> 
>> From what I've seen elsewhere, patch
>> tracking doesn't help much if there's nobody actively working on
>> integration and setting overall vision/direction.
> 
> The advantage of a patch tracking system such as Bugzilla would still be
> to make the list of unapplied patches more easily accessible (rather
> than searching list archives) and to allow clearly obsoleting patches
> with newer versions, as well as modelling dependencies.
> 
> Savannah has bug tracking capability - can't this be activated and
> emails directed to this list? Having that possibility would still allow
> submission via mailing list for immediate fixes or those who prefer.

Would that tracker be able to pick up (via some CC?) review comments
that should likely continue to be sent to the list? However, this is
just a technical measure that may or may not improve some aspects. I
personally have no problems resending my patches after a while if they
were lost but are still relevant (patches bitrot quickly anyway). What
is more critical, IMHO, is that there are the resources (maintainer
time) to review and give concrete feedback on patches as long as they
are "fresh". Otherwise, a tracker will just shift the work around.

At this chance: I often see "silent merges" of patches, long after they
have been posted. Also in these cases, specifically but not only when
modifications were made to the original submission, I would appreciate a
short note to the patch submitter via the list. That gives direct, more
personal credits and, in case of modifications, can help to clarify what
should have been done differently.

Another remark: If potential new maintainers should be affiliated with
any of the, to some degree, competing QEMU "accelerators" Xen and KVM, I
would be happy to see a public agreement beforehand on the general
architectural roadmap to cover those two requirement domains (+ the one
of KQEMU) in the future QEMU design. It would be bad for this project if
one side overrules the other via the (non-technical) preference of a
maintainer. Really, that's nothing against Ian personally or against
Xen/Citrix, the same would apply to KVM/Qumranet!

Jan

-- 
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux