From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32359 invoked by alias); 16 Aug 2004 19:33:35 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 32349 invoked from network); 16 Aug 2004 19:33:35 -0000 Received: from unknown (HELO mail.codesourcery.com) (65.74.133.9) by sourceware.org with SMTP; 16 Aug 2004 19:33:35 -0000 Received: (qmail 18152 invoked from network); 16 Aug 2004 19:33:33 -0000 Received: from taltos.codesourcery.com (zack@66.92.218.83) by mail.codesourcery.com with DES-CBC3-SHA encrypted SMTP; 16 Aug 2004 19:33:33 -0000 Received: by taltos.codesourcery.com (sSMTP sendmail emulation); Mon, 16 Aug 2004 12:33:33 -0700 To: Ziemowit Laski Cc: Mark Mitchell , GCC Patches Subject: Re: References: <918394DF-EFB7-11D8-8323-000393673036@apple.com> From: Zack Weinberg Date: Mon, 16 Aug 2004 19:43:00 -0000 In-Reply-To: <918394DF-EFB7-11D8-8323-000393673036@apple.com> (Ziemowit Laski's message of "Mon, 16 Aug 2004 12:07:50 -0700") Message-ID: <878yce7u9e.fsf@codesourcery.com> User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2004-08/txt/msg01101.txt.bz2 Ziemowit Laski 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