From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19271 invoked by alias); 17 Jan 2003 19:40:48 -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 19255 invoked from network); 17 Jan 2003 19:40:45 -0000 Received: from unknown (HELO jackfruit.Stanford.EDU) (171.64.38.136) by sources.redhat.com with SMTP; 17 Jan 2003 19:40:45 -0000 Received: (from carlton@localhost) by jackfruit.Stanford.EDU (8.11.6/8.11.6) id h0HJecA17392; Fri, 17 Jan 2003 11:40:38 -0800 X-Authentication-Warning: jackfruit.Stanford.EDU: carlton set sender to carlton@math.stanford.edu using -f To: Andrew Cagney Cc: gdb@sources.redhat.com Subject: Re: GDB `cannotfix' pr state, require PR with xfail `moving forward'. References: <3E270973.9020702@redhat.com> <3E2858DC.4030405@redhat.com> From: David Carlton Date: Fri, 17 Jan 2003 19:40:00 -0000 In-Reply-To: <3E2858DC.4030405@redhat.com> Message-ID: User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Common Lisp) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2003-01/txt/msg00316.txt.bz2 On Fri, 17 Jan 2003 14:26:20 -0500, Andrew Cagney said: >> 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). > Still stands. That certainly makes sense. >> - `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). > Still stands. I'm not sure exactly what you mean by "moving forward", but if you mean that all new xfails should have a bug report associated with them, I think I agree with that. Should all xfail bug reports be with reference to GDB's database, or are references to external databases allowed? I kind of like the former (though, presumably, the bug report in GDB's database might well reference a bug in an external database). > GDB has a new category `external'. External bugs can either be > `suspended' (I guess that implies that the bug is waiting on the > external code to be fixed), or `closed' the external problem has been > fixed. The only categorization glitch that I'm worried about is: what if there are external issues that can't be fixed? (E.g. limitations in a certain debug format.) I suppose Michael Chastain's answer there would be to not run the test at all in that situation. David Carlton carlton@math.stanford.edu