From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23006 invoked by alias); 2 Sep 2008 21:37:56 -0000 Received: (qmail 22987 invoked by uid 22791); 2 Sep 2008 21:37:55 -0000 X-Spam-Check-By: sourceware.org Received: from mtagate6.de.ibm.com (HELO mtagate6.de.ibm.com) (195.212.29.155) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 02 Sep 2008 21:37:12 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate6.de.ibm.com (8.13.8/8.13.8) with ESMTP id m82LaYQC297170 for ; Tue, 2 Sep 2008 21:36:34 GMT Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.13.8/8.13.8/NCO v9.0) with ESMTP id m82LaYOu3219706 for ; Tue, 2 Sep 2008 23:36:34 +0200 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id m82LaYtQ006198 for ; Tue, 2 Sep 2008 23:36:34 +0200 Received: from tuxmaker.boeblingen.de.ibm.com (tuxmaker.boeblingen.de.ibm.com [9.152.85.9]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with SMTP id m82LaYOQ006195; Tue, 2 Sep 2008 23:36:34 +0200 Message-Id: <200809022136.m82LaYOQ006195@d12av02.megacenter.de.ibm.com> Received: by tuxmaker.boeblingen.de.ibm.com (sSMTP sendmail emulation); Tue, 2 Sep 2008 23:36:34 +0200 Subject: Re: [rfc][00/37] Eliminate builtin_type_ macros To: mark.kettenis@xs4all.nl (Mark Kettenis) Date: Tue, 02 Sep 2008 21:37:00 -0000 From: "Ulrich Weigand" Cc: gdb-patches@sourceware.org In-Reply-To: <200809021020.m82AKiN8013408@brahms.sibelius.xs4all.nl> from "Mark Kettenis" at Sep 02, 2008 12:20:44 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2008-09/txt/msg00025.txt.bz2 Mark Kettenis wrote: > > As to *testing*, I agree that having to apply 37 patches in sequence > > is a pain, which is why I sent -in addition to the broken-out series- > > a single cumulative patch as well. > > Yes, that was a good thing to do. I apologize for sending the message > I sent yesterday evening before reading all my mail. No problem -- I appreciate the feedback. > > In the end, this is simply a large set of changes (the cumulative patch > > is 8000 lines, the broken-out patches total 10000 lines) spread out > > across many parts of GDB (the patch set touches 97 files) -- if you have > > suggestions how to present a change like this in a way that's easier to > > review, those would certainly be welcome. > > I don't think there is much you can do about it. A large set of > fairly mechanical changes is simply a large set of mechanical changes. > It's probably good if people have a look at part of the diff, but in > the end we'll just have to trust that the job was done properly and > that it gets committed (preferably after people have tested it). The thing is, parts of the patch set (e.g. the -tdep.c changes) are indeed completely mechanical changes. However, in other places I am making definite design choices (e.g. should an expression really be something architecture-neutral, or explicitly platform-specific?). One important reason for splitting the patch set up is in fact to avoid such design choices being swamped and overlooked within a single large, mostly mechanical patch ... Bye, Ulrich -- Dr. Ulrich Weigand GNU Toolchain for Linux on System z and Cell BE Ulrich.Weigand@de.ibm.com