Re:

[Zack Weinberg <zack@codesourcery.com>]

Ziemowit Laski <zlaski@apple.com> writes:

>> You need to explain, in detail, what each change does and why.
>>
>> You have broken up this patch along the wrong lines.  Never break a
>> patch into pieces which could not be committed independently.  Changes
>
> The reason I broke the patch up is simply to ease the review
> process, since I can take maintainer responsibility for a large
> chunk of it.  I apologize if this is confusing; this _is_ really all
> one giant patch.

I realize that it's one giant patch and you broke it up to ease the
review process.  However, you chose to break it along lines which made
it _harder_ to review, because they didn't divide the patch into
independently reviewable changes.  In fact, you separated components
of the same change, such that I would have had to read both part A and
part B in order to review part A completely.

...
> Therefore, I would kindly request that my ongoing work be treated as
> a branch integration project.  Breaking this patch up into numerous
> tiny pieces that when put together will reconstitute the original
> patch does not offer any benefits that I can think of, and does in
> fact have two major drawbacks: (1) it takes a lot more time and (2)
> it is more susceptible to pilot error due to its fragmented nature.

Being a branch integration project does _not_ excuse you from breaking
up the patch into independent least-change units.  Look at the way the
LNO branch merge is being handled.

I realize that this makes substantially more work for you, but please
understand that there is no way we can review the patch as you posted
it.  It's just too hard to understand.  The chance of pilot error goes
up, yes, but that is overshadowed by the reduced chance that we will
miss something in our review, and the increased easiness of correcting
a small patch if a problem is discovered after it's committed.

zw