From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:57620) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XSMUM-0002xi-EU for qemu-devel@nongnu.org; Fri, 12 Sep 2014 04:45:59 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XSMUD-0004DD-Nf for qemu-devel@nongnu.org; Fri, 12 Sep 2014 04:45:54 -0400 Received: from mx1.redhat.com ([209.132.183.28]:21284) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XSMUD-0004D7-Fu for qemu-devel@nongnu.org; Fri, 12 Sep 2014 04:45:45 -0400 Date: Fri, 12 Sep 2014 10:45:35 +0200 From: Kevin Wolf Message-ID: <20140912084535.GC5076@noname.redhat.com> References: <20140911201821.GA26751@stefanha-thinkpad.redhat.com> <20140911212243.GA16487@irqsave.net> <8761gt2vcn.fsf@blackfin.pond.sub.org> <33183CC9F5247A488A2544077AF1902086DC9EBE@SZXEMA503-MBS.china.huawei.com> <20140912081401.GA5076@noname.redhat.com> <33183CC9F5247A488A2544077AF1902086DC9F4D@SZXEMA503-MBS.china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <33183CC9F5247A488A2544077AF1902086DC9F4D@SZXEMA503-MBS.china.huawei.com> Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] New requirement for getting block layer patches merged List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Gonglei (Arei)" Cc: =?iso-8859-1?Q?Beno=EEt?= Canet , Markus Armbruster , Stefan Hajnoczi , "qemu-devel@nongnu.org" Am 12.09.2014 um 10:32 hat Gonglei (Arei) geschrieben: > > From: Kevin Wolf [mailto:kwolf@redhat.com] > > Sent: Friday, September 12, 2014 4:14 PM > > Subject: Re: [Qemu-devel] New requirement for getting block layer pat= ches > > merged > >=20 > > Am 12.09.2014 um 09:02 hat Gonglei (Arei) geschrieben: > > > Hi, > > > > > > > Subject: Re: [Qemu-devel] New requirement for getting block layer= patches > > > > merged > > > > > > > > Beno=EEt Canet writes: > > > > > > > > >> EOF > > > > >> --- > > > > >> If you have feedback or questions, let us know. The process c= an be > > > > >> tweaked as time goes on so we can continue to improve. > > > > > > > > > > Great mail. > > > > > > > > Yup. Let's see how it works out. > > > > > > > > > > Yes. I can't agree more with you. > > > > > > Recently I posted some patch series, but I can't get maintainer's f= eedback in > > time. > > > That make me feel soulless TBH. I know maintainers are very busy us= ually. > > They > > > need to develop their own code and also need review the contributor= s' code. > > > If some other peoples can spread the load of patch review, that's a= great > > thing IMHO. > >=20 > > This is what Stefan's mail was actually for in some way: Letting you > > know that you should get a Reviewed-by first. > >=20 > > At least for me, to be honest, this isn't a truly new process. I have= n't > > been consistently requiring a Reviewed-by, but when I see someone els= e > > discuss a patch series and I don't have much time, I may scan the > > discussion to chime in if there is something fundamentally wrong, but > > otherwise let the author and the reviewer sort it out and wait until = the > > discussion has settled. If I don't see a discussion, I might wait a f= ew > > days for one. > >=20 > Good method. :) >=20 > > I'll probably keep reviewing paches without an R-b when they are simp= le > > or in my area of expertise (like qcow2), like any other reviewer shou= ld. > > The point is just that when I don't, before you ping us maintainers > > about a patch, try to get a good review from some other contributor. > >=20 > But there's a problem that a patch may have not get a review > from other contributors in some areas, maybe only few people worked on = it. > After a few weeks, maintainers can give some response to author if=20 > the author is pinging...? If you try and still fail to get review after a few weeks, sure, talk to us and we'll find a solution. But keep in mind that if only few people have worked on the code, Stefan and I probably haven't either. So automatically delegating all such cases for us to review isn't going to be helpful, because reviewing patches to code that you don't know is one of the most time consuming activities. Spreading them over more contributors is the goal of this change. Kevin