Re: [PATCH] send-email: handle multiple Cc addresses when reading mbox message

From: Jeff King <peff@peff.net>
Date: Feb 14, 2009, 03:37 UTC
Message-ID: <20090214033749.GA24545@coredump.intra.peff.net>
In-Reply-To: <76718490902131642y62b81bfat129cfbeda7957ff8@mail.gmail.com>

On Fri, Feb 13, 2009 at 07:42:16PM -0500, Jay Soffian wrote:

Show 10 quoted lines

> On Fri, Feb 13, 2009 at 7:31 PM, Jeff King <peff@peff.net> wrote:
> > I don't know what the right solution is. I am certainly not volunteering
> > to rewrite; I am very happy just using my actual MUA to send patches. :)
> 
> It is quite ugly, and I have thought about rewriting it.
> 
> But to be quite honest, I have become very discouraged over the last
> two weeks about submitting patches. What seems at first to be a simple
> change has required multiple revisions over frankly what feels to me
> like nit-picking.

I hope it wasn't my message in this thread that sent you over the edge. I really did mean the "this isn't a comment on your patch" but was just musing out loud over what the right direction for send-email is in general.

Show 9 quoted lines

> Me: Notice wart
> Me: Cut wart off (i.e. submit patch)
> Reviewer: Sorry, you didn't cut that wart off to my standards, unless
> you can do it better, I'd rather have the wart.
> 
> I dunno, maybe I'm too sensitive and don't have the fortitude for
> contributing to git.
> 
> Or maybe I'm just venting on a Friday.

I hope just venting. I think the warts you've been cutting off have been improving git.

One of the things I have seen happening with your patches is something like:

  Jay: Here's a patch.
  Reviewer: Good, but it should also do X to be complete.
              or
            Good, but there is one corner case where the correct
            behavior is unclear [queue endless discussion, production of
            several versions of the patch doing different behavior, or
            realization that some of the behavior would be an order of
            magnitude more work to implement]

Those sorts of reviews are good for helping git in the long run, and I think reviewers are often thinking in terms of git's overall progression. But I think it is also OK sometimes as a patch submitter to say "This series scratches my itch, and I am done for now." And maybe somebody else picks it up and builds on it. Or maybe you do, but weeks or months later. Or maybe nobody does, because it turns out that nobody really cares about that corner case in practice.

Which is really just "perfect is the enemy of the good" in another form, and recognizing that git's development is incremental.

And all of that isn't to say there aren't plenty of patches that should be rejected for incompleteness or lack of handling corner cases. Many times an incomplete solution is worse than no solution at all. So there is some judgement required about whether the changes are a net positive and a net negative.

But I think it is up to the submitter to decide how far he wants to take a given topic (and at what rate), and to say "OK, I'll go implement that", "This behavior doesn't go all the way, but we're better off than before", or even to just take a week off and come back to it later.

So if you're feeling burned out on submitting patches, maybe that helps.

Of course, there are also just plain nitpicks. We try to keep them to a minimum, but they do creep in. :)

-Peff