From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=49604 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OlREX-0001CD-3F for qemu-devel@nongnu.org; Tue, 17 Aug 2010 14:50:03 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OlREV-0007Vl-0o for qemu-devel@nongnu.org; Tue, 17 Aug 2010 14:50:00 -0400 Received: from fe02x03-cgp.akado.ru ([77.232.31.165]:52911 helo=akado.ru) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OlREU-0007Tm-Lp for qemu-devel@nongnu.org; Tue, 17 Aug 2010 14:49:58 -0400 Date: Tue, 17 Aug 2010 22:49:30 +0400 (MSD) From: malc Subject: Re: [Qemu-devel] Unmaintained QEMU builds In-Reply-To: Message-ID: References: <4C62825A.6000903@mail.berlios.de> <4C685F5D.2090707@codemonkey.ws> <4C69A29F.5000606@codemonkey.ws> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="33734824-1416990408-1282070970=:1411" List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Blue Swirl Cc: QEMU Developers This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --33734824-1416990408-1282070970=:1411 Content-Type: TEXT/PLAIN; charset=UTF-8 Content-Transfer-Encoding: 8BIT On Tue, 17 Aug 2010, Blue Swirl wrote: > On Mon, Aug 16, 2010 at 8:42 PM, Anthony Liguori wrote: > > On 08/16/2010 01:51 PM, Blue Swirl wrote: > >> > >> On Sun, Aug 15, 2010 at 9:42 PM, Anthony Liguori > >>  wrote: > >> > >>> > >>> On 08/11/2010 11:34 AM, Blue Swirl wrote: > >>> > >>>> > >>>> On Wed, Aug 11, 2010 at 10:58 AM, Stefan Weil > >>>>  wrote: > >>>> > >>>> > >>>>> > >>>>> Hi, > >>>>> [..snip..] > > > TBH, I think dropping kqemu resulted in the last few win32 users moving on > > to something else. > > This would also apply to all x86 operating systems without KVM, like > *BSD, *Solaris and Darwin/x86 and it would also mean that TCG is > useless on x86. But nobody has stepped up as kqemu maintainer, which > supports your argument. > > > >> What about other uncommon and possibly already broken (or never > >> finished) features, like Parallels, VVFAT or VMDK support? What about > >> new features, do we know in advance that they will be actively > >> maintained? > >> > > > > We ought to separately consider features that are isolated and features that > > are invasive.  For something like VMDK or VVFAT, there's very little burden > > that the rest of the code base endures simply by the code existing. > > I haven't ever used them. Do they even work? VVFAT r/o does work and is useful (at least for me). > > Win32 seems to be a constant source of pain though. > > Similar pains come from any portability to non-Linux OS (or older GCCs > that don't support threads), although smaller. > > >> But I'm not completely against this. Maybe we should make a list of > >> features and check which of those work. Features which don't pass are > >> scheduled for deprecation or removal. > >> > > > > Yes, I think this is exactly what we need to do. > > Even better would be to check all features with for example autotest. > Automated testing would also benefit from narrowed feature set. > > At least major features should have a named maintainer as well. > > If nonfunctional features were also removed, QEMU would be feature > complete and bug-free so we could release a 1.0 version. ;-) > -- mailto:av1474@comtv.ru --33734824-1416990408-1282070970=:1411--