From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2344 invoked by alias); 22 Nov 2013 17:16:23 -0000 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 Received: (qmail 2333 invoked by uid 89); 22 Nov 2013 17:16:22 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.7 required=5.0 tests=AWL,BAYES_00,RDNS_NONE,SPF_HELO_PASS,SPF_PASS,URIBL_BLOCKED autolearn=no version=3.3.2 X-HELO: mx1.redhat.com Received: from Unknown (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 22 Nov 2013 17:16:21 +0000 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id rAMHG72h018837 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 22 Nov 2013 12:16:08 -0500 Received: from barimba (ovpn-113-124.phx2.redhat.com [10.3.113.124]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id rAMHG6iC017496 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 22 Nov 2013 12:16:06 -0500 From: Tom Tromey To: "Tedeschi\, Walfred" Cc: Pedro Alves , Yao Qi , "Mark Kettenis \(mark.kettenis\@xs4all.nl\)" , "gdb-patches\@sourceware.org" Subject: Re: [pushed] [PATCH V7 0/8] Intel(R) MPX register support References: <528E62B3.7080005@redhat.com> Date: Fri, 22 Nov 2013 17:23:00 -0000 In-Reply-To: (Walfred Tedeschi's message of "Fri, 22 Nov 2013 12:32:45 +0000") Message-ID: <87siuocq7e.fsf@fleche.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SW-Source: 2013-11/txt/msg00691.txt.bz2 >>>>> ">" == Tedeschi, Walfred writes: >> BTW: Next patch we will squash i386/amd64/gdbserver. Should this three >> patches also be send for review as a single commit? Usually it's best to make each patch work independently. This is the ideal because then one doesn't need to do anything special when submitting or merging. Of course, it isn't always possible. Sometimes a patch is easier to read when split, but the split means that some sub-patch doesn't build. In this case I think it is fine to note the issue in the email and then remember to squash the relevant patches at merge time. Tom