clattner at apple.com
Fri Jul 29 12:06:34 PDT 2011
On Jul 29, 2011, at 11:26 AM, David A. Greene wrote:
>> Disagreed. The point is that I should not see a stream of 20
>> decomposed patches from you. When I get to one that is "wrong" or
>> needs changes (e.g. patch 6), then all the other patches after it get
>> ignored. This is silly.
> It is silly. I see no reason to simply ignore the later patches unless
> patch 6 needs a substantial rework.
Again, I value reviewer time (which is scarce if you haven't noticed) more than patch submitter time.
If patch 6 needs rework, it can cause ripple effects through the rest of the patch series. I believe that your recent tblgen changes are a perfect example of this.
>> Instead, what I should see are (for example) and be asked to review
> Oops, I think something got botched here. I can't parse the above. :)
Yeah, parse error for me too. :)
>> No. The fundamental disagreement/misunderstanding here is that you
>> are optimizing for an out-of-tree maintainer pushing "batches" of work
>> upstream. This is not what I'm at all interesting in optimizing for,
>> and if you're irritated about the turn-around time that it takes to
>> get review, then you shouldn't be optimizing for this either.
> Thanks, that clarifies things. So you don't so much demand individual
> cherry-picks to master as you demand that merges to master be smallish
> and incremental. I think that is entirely reasonable.
> With my most recent patch, I submitted something I considered logically
> connected. I was asked to rework it and break it up. I did that and
> submitted the resulting patch stream for review. No one seemed to
> complain about that so I wasn't grokking your dislike of that apporoach.
> Now I am much more clear about how to use this git thing with LLVM. :)
More information about the llvm-dev