From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29134 invoked by alias); 9 Oct 2013 16:45:38 -0000 Mailing-List: contact binutils-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sourceware.org Received: (qmail 29124 invoked by uid 89); 9 Oct 2013 16:45:38 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.3 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-ob0-f169.google.com Received: from mail-ob0-f169.google.com (HELO mail-ob0-f169.google.com) (209.85.214.169) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Wed, 09 Oct 2013 16:45:37 +0000 Received: by mail-ob0-f169.google.com with SMTP id wp4so819939obc.14 for ; Wed, 09 Oct 2013 09:45:35 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.60.142.8 with SMTP id rs8mr6654182oeb.34.1381337135431; Wed, 09 Oct 2013 09:45:35 -0700 (PDT) Received: by 10.76.110.15 with HTTP; Wed, 9 Oct 2013 09:45:35 -0700 (PDT) In-Reply-To: <52551EA202000078000F9D92@nat28.tlf.novell.com> References: <5254349502000078000F9A3D@nat28.tlf.novell.com> <525435E002000078000F9A55@nat28.tlf.novell.com> <52543F7202000078000F9B07@nat28.tlf.novell.com> <5254485102000078000F9B47@nat28.tlf.novell.com> <52551EA202000078000F9D92@nat28.tlf.novell.com> Date: Wed, 09 Oct 2013 16:45:00 -0000 Message-ID: Subject: Re: acceptance rules (was: Re: [PATCH 3/6] x86/MPX: suppress base/index swapping ...) From: "H.J. Lu" To: Jan Beulich Cc: Alan Modra , Ian Taylor , Nick Clifton , Richard Henderson , kirill.yukhin@intel.com, Binutils Content-Type: text/plain; charset=ISO-8859-1 X-IsSubscribed: yes X-SW-Source: 2013-10/txt/msg00120.txt.bz2 On Wed, Oct 9, 2013 at 12:15 AM, Jan Beulich wrote: >>>> On 08.10.13 at 18:19, "H.J. Lu" wrote: >> I prefer a testcase together with the corresponding change, >> instead of a jumbo testcase patch. I also don't agree every >> MPX change you proposed. If it makes it easier to write >> testcases, you can use a separate testcase file for each >> change. > > Okay, so then I'll submit a monolithic patch combined with the > testcase changes (once we sorted out eventual adjustments). > Separate testcase files is not a desirable approach imo - what > belongs together should stay together. As additional context: > Getting the existing test case straightened took me significantly > more time than fixing the actual bugs here, and I simply don't You can open a bug report to report the issue against the existing testcase. > see myself wasting more time on this unless there's a _good_ > reason. > > And just to repeat - I'm very opposed to the idea of rejecting > bug fixes just because of controversy about test cases. This > isn't happening the first time (and is also not isolated to you as > the x86 maintainer). I very much think that bug fixes ought to > be acceptable in any case, and test cases ought to be optional. > I can see this being more strict for enhancements, and even a > requirement for new feature additions. If a patch changes the assembler behavior, it should be verified via a testcase to make sure that it does what it is intended and stays that way. > Yet in no case should - imo - badly written test cases be > accepted just because this is better than no test case at all. > But of course I realize that there's no guideline (or at least I'm > unaware of there being any) on how a good test case would > look like (my main requirements would be that they (a) don't > test things to be valid that aren't and (b) use patterns instead > of exact matches where precise values don't matter so that > they can be extended without having to entirely replace them). If a testcase, which is supposed to pass, contains invalid instructions, we should just fix it. If you notice any issue within binutils, including testcases, just open a bug report against it. At least, there is a trail. Thanks for your contribution. -- H.J.