From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:59945) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T6PQv-0006Qo-It for qemu-devel@nongnu.org; Tue, 28 Aug 2012 13:18:38 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1T6PQs-0005p0-Tb for qemu-devel@nongnu.org; Tue, 28 Aug 2012 13:18:33 -0400 Received: from cantor2.suse.de ([195.135.220.15]:32882 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T6PQs-0005oM-Mo for qemu-devel@nongnu.org; Tue, 28 Aug 2012 13:18:30 -0400 Message-ID: <503CFD5D.2010801@suse.de> Date: Tue, 28 Aug 2012 19:18:21 +0200 From: =?UTF-8?B?QW5kcmVhcyBGw6RyYmVy?= MIME-Version: 1.0 References: <1343201734-12062-1-git-send-email-yeongkyoon.lee@samsung.com> <1343201734-12062-4-git-send-email-yeongkyoon.lee@samsung.com> <500FFBE0.70700@twiddle.net> <50140795.5030209@samsung.com> <503B208D.2020407@samsung.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [RFC][PATCH v4 3/3] tcg: Optimize qemu_ld/st by generating slow paths at the end of a block List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Yeongkyoon Lee Cc: Peter Maydell , sw@weilnetz.de, qemu-devel@nongnu.org, blauwirbel@gmail.com, laurent.desnogues@gmail.com, Richard Henderson Am 27.08.2012 20:31, schrieb Peter Maydell: > On 27 August 2012 08:23, Yeongkyoon Lee wr= ote: >> BTW, who will finally confirm my patches? >> I have sent four version of my patches in which I have applied all the >> reasonable feedbacks from this community. >=20 > If you'd like your patches committed you should not use the "[RFC]" tag > in the Subject, because "RFC" means "I would like feedback on this > patch but do not intend it to be committed to master". Literally, RFC means request for comments. Personally I differentiate between [RFC n/m] and [PATCH RFC n/m], where the lack of PATCH means "don't commit this version" and the latter indicating "I'm not so sure if this is how we want to do it, but if people agree it can go in". ;) Not sure how [RFC][PATCH n/m] is intended here? If everyone adds RFC to a regular PATCH, it looses meaning. In the course of review when you feel the patches are okay to be committed, RFC should disappear as you may well get comments without asking for them anyway. :) HTE, Andreas --=20 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N=C3=BCrnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imend=C3=B6rffer; HRB 16746 AG N=C3=BC= rnberg