From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1K3UOP-0002cJ-SP for qemu-devel@nongnu.org; Tue, 03 Jun 2008 07:09:29 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1K3UOO-0002ag-S4 for qemu-devel@nongnu.org; Tue, 03 Jun 2008 07:09:29 -0400 Received: from [199.232.76.173] (port=50461 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1K3UOO-0002aG-9N for qemu-devel@nongnu.org; Tue, 03 Jun 2008 07:09:28 -0400 Received: from lizzard.sbs.de ([194.138.37.39]:18363) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1K3UOO-0001Tt-1O for qemu-devel@nongnu.org; Tue, 03 Jun 2008 07:09:28 -0400 Received: from mail1.sbs.de (localhost [127.0.0.1]) by lizzard.sbs.de (8.12.11.20060308/8.12.11) with ESMTP id m53B9OWO031211 for ; Tue, 3 Jun 2008 13:09:24 +0200 Received: from [139.25.109.167] (mchn012c.mchp.siemens.de [139.25.109.167] (may be forged)) by mail1.sbs.de (8.12.11.20060308/8.12.11) with ESMTP id m53B9OJH018205 for ; Tue, 3 Jun 2008 13:09:24 +0200 Message-ID: <48452663.8090506@siemens.com> Date: Tue, 03 Jun 2008 13:09:23 +0200 From: Jan Kiszka MIME-Version: 1.0 References: <193307.64140.qm@web57014.mail.re3.yahoo.com> <18501.3725.422151.796839@mariner.uk.xensource.com> <20080603100036.GA25740@shareable.org> <87F66ED9-C3F7-4E2F-BA75-2522B03A1E00@web.de> In-Reply-To: <87F66ED9-C3F7-4E2F-BA75-2522B03A1E00@web.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [Qemu-devel] Re: An organizational suggestion Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Andreas F=E4rber wrote: >=20 > Am 03.06.2008 um 12:00 schrieb Jamie Lokier: >=20 >> 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. >=20 > The advantage of a patch tracking system such as Bugzilla would still b= e > 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. >=20 > 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 --=20 Siemens AG, Corporate Technology, CT SE 2 Corporate Competence Center Embedded Linux