From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:42357)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <arei.gonglei@huawei.com>) id 1Z1wQ8-0001JZ-9p
	for qemu-devel@nongnu.org; Mon, 08 Jun 2015 08:44:53 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <arei.gonglei@huawei.com>) id 1Z1wQ4-0005av-4o
	for qemu-devel@nongnu.org; Mon, 08 Jun 2015 08:44:52 -0400
Received: from szxga03-in.huawei.com ([119.145.14.66]:62572)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <arei.gonglei@huawei.com>) id 1Z1wQ3-0005Zv-Is
	for qemu-devel@nongnu.org; Mon, 08 Jun 2015 08:44:48 -0400
Message-ID: <55758E29.5050902@huawei.com>
Date: Mon, 8 Jun 2015 20:44:25 +0800
From: Gonglei <arei.gonglei@huawei.com>
MIME-Version: 1.0
References: <55721FBE.2010304@redhat.com>
In-Reply-To: <55721FBE.2010304@redhat.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] QEMU's CVE Procedures
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: John Snow <jsnow@redhat.com>, qemu-devel <qemu-devel@nongnu.org>
Cc: Peter Maydell <peter.maydell@linaro.org>, "Michael S. Tsirkin" <mst@redhat.com>, Stefano Stabellini <stefano.stabellini@eu.citrix.com>, Michael Roth <mdroth@linux.vnet.ibm.com>, Markus Armbruster <armbru@redhat.com>, Paolo Bonzini <pbonzini@redhat.com>

On 2015/6/6 6:16, John Snow wrote:
> (6) What about qemu-stable?
> 
> Our stable process is somewhat lacking with respect to the CVE
> process. It is good that we occasionally publish stable fix roundups
> that downstream maintainers can base their work off of, but it would
> be good to have a branch where we can have CVE fixes posted promptly.
> 
Good point.

In our team, when a CVE fix posted in upstream, we should fix all other Qemu
versions manually. Sometimes, the involved files are quite different between
different Qemu branches. It's too expensive when you have so many different
branches need to maintain. :(

> 
> (7) How long should we support a stable branch?
> 
> We should figure out how many stable release trees we actually intend
> to support: The last two releases? The last three?
> 
> My initial guess is "Any stable branch should be managed for at least
> a year after initial release."
> 
> This would put our current supported releases as 2.1, 2.2 and 2.3, so
> about ~3 managed releases seems sane as an initial effort.

Regards,
-Gonglei