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

[Blue Swirl]

On 6/22/09, Stuart Brady <address@hidden> wrote:
> 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?

Yes, but since the maintainer reversed the patch, the birds and the
kitten were magically resurrected.

>  Also, what have people got against bird all of a sudden?

I'm afraid you must consult with your ancestors, who invited this bird
killing talk and other monstrosities.

>  Consider the lily?!  He's having a go at the flowers, now! ;-)

ENOPARSE

>  > >  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.

+1 for this one.

>  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.

Yes, imagine a Beowulf cluster of... Nevermind.