From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MImxV-0006nL-Vv for qemu-devel@nongnu.org; Mon, 22 Jun 2009 13:05:30 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MImxQ-0006la-Jr for qemu-devel@nongnu.org; Mon, 22 Jun 2009 13:05:29 -0400 Received: from [199.232.76.173] (port=55757 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MImxQ-0006lX-Dk for qemu-devel@nongnu.org; Mon, 22 Jun 2009 13:05:24 -0400 Received: from mtaout03-winn.ispmail.ntl.com ([81.103.221.49]:48371) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MImxP-000766-MG for qemu-devel@nongnu.org; Mon, 22 Jun 2009 13:05:24 -0400 Received: from aamtaout03-winn.ispmail.ntl.com ([81.103.221.35]) by mtaout03-winn.ispmail.ntl.com (InterMail vM.7.08.04.00 201-2186-134-20080326) with ESMTP id <20090622170518.MAHV5579.mtaout03-winn.ispmail.ntl.com@aamtaout03-winn.ispmail.ntl.com> for ; Mon, 22 Jun 2009 18:05:18 +0100 Received: from miranda.arrow ([213.107.24.213]) by aamtaout03-winn.ispmail.ntl.com (InterMail vG.2.02.00.01 201-2161-120-102-20060912) with ESMTP id <20090622170518.SSGK2093.aamtaout03-winn.ispmail.ntl.com@miranda.arrow> for ; Mon, 22 Jun 2009 18:05:18 +0100 Received: from sdb by miranda.arrow with local (Exim 4.63) (envelope-from ) id 1MImxI-0000pW-1U for qemu-devel@nongnu.org; Mon, 22 Jun 2009 18:05:16 +0100 Date: Mon, 22 Jun 2009 18:05:15 +0100 From: Stuart Brady Subject: Re: [Qemu-devel] [PATCH] cocoa.m issues fixed Message-ID: <20090622170515.GA29636@miranda.arrow> References: <61E57A9F-6D9A-4DF3-9CE6-0B8056DD1C60@web.de> <4A3E5071.7080407@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org On Sun, Jun 21, 2009 at 09:07:06PM +0300, Blue Swirl wrote: > On 6/21/09, Avi Kivity wrote: > > It's standard operating procedure. Suppose in addition to the two birds > > you mention the patch also kills an innocent kitten. Since it's one patch, > > if a fix is not immediately forthcoming, the maintainer has to revert the > > patch, bringing both birds back to life. > > How nasty for you to forget the poor little kitten, who should be > entitled to get her life back. Why are the birds being brought back to life, anyway? I thouht they idea was to kill two birds with one stone? Also, what have people got against bird all of a sudden? Consider the lily?! He's having a go at the flowers, now! ;-) > > With one patch per bird, the maintainer can revert just the patch which > > killed the kitten, leaving the other bird dead. > > Also here, do you really hate kittens that much? ;-) Or birds, for that matter... BTW, other reasons to apply one fix per patch, in no particular order: * Makes resolving merge conflicts more straightforward in certain cases, as it's easier to see why different lines were modified. (I.e. multiple changes with a long description weakens the tie between the description and the individual fixes that were applied.) * Means that when looking at commits, people can see the changes that they're interested in, instead of having to manually skip past all the cosmetic stuff that they're not interested in. * Means that the fix can be cherry picked for a distribution easily, without forcing maintainers to filter out cosmetic changes that shouldn't be made to stable release. * Increases the chance of cleanups being made in all cases, rather than just the one-or-two that you happened to spot in whatever file or function you were dealing with at the time. * Means that if there's a problem with only one change out of many, it's likely that you'll only need to resubmit the change that was incorrect. (This also eliminates/reduces the chance of any sneaky or even unintended changes being made regarding the other fixes.) * Makes changes stand out better in the shortlog. * Improves the likelihood that maintainers will consider your patch to be reviewable, and then actually review it and apply it, if those maintainers lack the time to review all patches that are submitted. I'm sure there are many more reasons. For one simple patch, it may not seem like a big deal, but for several hundred simple patches, it is. Cheers, -- Stuart Brady