From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18575 invoked by alias); 16 Jan 2003 19:35:21 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 18561 invoked from network); 16 Jan 2003 19:35:15 -0000 Received: from unknown (HELO localhost.redhat.com) (216.138.202.10) by sources.redhat.com with SMTP; 16 Jan 2003 19:35:15 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 0533F3DF3 for ; Thu, 16 Jan 2003 14:35:16 -0500 (EST) Message-ID: <3E270973.9020702@redhat.com> Date: Thu, 16 Jan 2003 19:35:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.1) Gecko/20021211 X-Accept-Language: en-us, en MIME-Version: 1.0 To: gdb@sources.redhat.com Subject: GDB `cannotfix' pr state, require PR with xfail `moving forward'. Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-01/txt/msg00296.txt.bz2 Hello, There is currently a long thread (Remove all setup_xfail...)'s on gdb-patches@. Several proposals, I think, can already be identified at this point in the discussion. - yank the existing xfail PR markings (but not the actual xfails) (they apply to old internal Red Hat and HP bug databases and hence are meaningless). - `moving forward' all new xfails, and all modifications to existing xfail's should include a bug report (this way, new analyzed vs old unanalized xfail's can easily be differentiated). - GDB have a new closed state `cannotfix'; or a new class `xfail' or `notabug' or ...; or even reuse the class `mistaken' that can be used to categorize xfail bug reports (not sure which is better here). thoughts, Andrew PS: The state `willnotfix' was suggested. I think that is wrong. GDB shouldn't refuse to fix a real problem (just drop the priority to low), and here the problem is one of cannot fix.