From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1C2btW-0002iA-Bo for qemu-devel@nongnu.org; Wed, 01 Sep 2004 16:39:50 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1C2btV-0002hU-KT for qemu-devel@nongnu.org; Wed, 01 Sep 2004 16:39:50 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1C2btV-0002hC-IT for qemu-devel@nongnu.org; Wed, 01 Sep 2004 16:39:49 -0400 Received: from [64.233.170.205] (helo=mproxy.gmail.com) by monty-python.gnu.org with esmtp (Exim 4.34) id 1C2boD-00034h-8o for qemu-devel@nongnu.org; Wed, 01 Sep 2004 16:34:21 -0400 Received: by mproxy.gmail.com with SMTP id v18so80250rnb for ; Wed, 01 Sep 2004 13:34:20 -0700 (PDT) Message-ID: <5640213304090113344f9608d4@mail.gmail.com> Date: Wed, 1 Sep 2004 15:34:20 -0500 From: Mike Tremoulet Subject: Re: [Qemu-devel] Qemu development schedule? In-Reply-To: <1094067968.6164.11.camel@fred.soliddesign.net> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <000501c48eda$a026ab40$20649c3f@computername> <1093903154.26682.44.camel@aragorn> <002001c48ee5$456d6a30$20389c3f@computername> <000601c48f73$752b00a0$03389c3f@computername> <1093969628.2835.98.camel@fred.soliddesign.net> <005301c48f82$067c5af0$82389c3f@computername> <1094067968.6164.11.camel@fred.soliddesign.net> Reply-To: Mike Tremoulet , 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 If I may, I'd like to make some suggestions to keep this discussion productive. Some good points have been raised and discussed about the mode of development for qemu. At this point, it does become a "religious debate", where two sides both believe they are right and no correct answer is actually called for - it's just two different styles of working. I can't see much more productive coming from that discussion, so I respectfully suggest we let that rest. The idea of a front-end, or minimally a "configurator" to generate the command line, is interesting. I'd happily welcome something that gave me some check boxes and text fields to select from, and set up the command line switches for me to save for use. I suspect that, unless it is built in to the application window (see the OSD part of the thread, or something like PearPC's choice of boot device), the graphic form will be platform specific. Work is already being done in this area, but I'm not holding my breath for the all-in-one GUI. However, the real reason I was writing was to gauge interest in some of the ideas this thread gave me: - Would there be interest in a bugtrack of sorts for qemu? My suspicion is that the platform isn't quite so stable to warrant this, but it is something I could help set up. Or promote the use of the tracker on the Savannah project page? - Similarly, what about a feature list/request tracker? Something a little more focused to capture the wishlist items? - Finally, a request. One of the more daunting tasks for me as a new-to-qemu developer is to read and discover the design of the system. What I'd like to do is prepare a brief catalog of each of the pieces of code, so interested people can more quickly find where to tie in with the existing code. In order to produce this quickly, then, I'm asking that list members please email either myself or the list with a quick one or two sentence description of each code file that they touch. This should only take a couple of seconds, but would greatly help me compile a table of contents, if you will, of the code. An example that I *think* is correct (let me know if I'm off): NE2000.c - Emulates an NE 2000 NIC in the guest OS. Sends packets to/from the QEMU engine. [Also, if there's a list to be compiled of configure or make options, or of existing command line switches, I'll be happy to pull those together as you present them to me.] Thanks, -- Mike