Re: [Qemu-devel] [PATCH] cocoa.m issues fixed

[Stuart Brady]

On Sun, Jun 21, 2009 at 09:07:06PM +0300, Blue Swirl wrote:
> On 6/21/09, Avi Kivity <address@hidden> 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