From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:50959) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dZeoo-00008L-0r for qemu-devel@nongnu.org; Mon, 24 Jul 2017 10:58:46 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dZeoj-000075-S4 for qemu-devel@nongnu.org; Mon, 24 Jul 2017 10:58:46 -0400 Received: from mx1.redhat.com ([209.132.183.28]:36618) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1dZeoj-00006q-LR for qemu-devel@nongnu.org; Mon, 24 Jul 2017 10:58:41 -0400 References: <20170719100802.14094-1-berrange@redhat.com> <20170719100802.14094-2-berrange@redhat.com> <20170724141108.GA11443@redhat.com> <20170724144759.GD11443@redhat.com> From: Paolo Bonzini Message-ID: <20569a41-8017-f977-aec6-6a7ad8ff7229@redhat.com> Date: Mon, 24 Jul 2017 16:58:35 +0200 MIME-Version: 1.0 In-Reply-To: <20170724144759.GD11443@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v5 1/2 (for 2.10)] docs: document support lifetime for features List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Daniel P. Berrange" Cc: Thomas Huth , qemu-devel@nongnu.org, Peter Maydell , Stefan Hajnoczi , Markus Armbruster , Eduardo Habkost On 24/07/2017 16:47, Daniel P. Berrange wrote: > If it takes more work downstream to undelete & maintain machine > types in the downstream fork, that means downstream maintainers > less free time to improve QEMU upstream. From that POV, deleting > machine types & props upstream is actually counterproductive to > upstream on balance. The rational thing would thus be to stick > with status quo, and explicitly cdeclare that upstream will *never* > delete machine types, or make their lifetime long enough for the > longest lived downstream (10 years min & by the time we get to > 10 years, it might even be 15 years). Yeah, that makes sense. At the moment at least Red Hat and Canonical create custom machine types. As soon as neither Red Hat nor Canonical contribute to upstream QEMU, the policy can change. But honestly, even though I have an obvious conflict of interest, I see no reason to make things more complicated for downstreams that are active contributors to QEMU... Paolo