From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2623 invoked by alias); 18 Nov 2005 22:19:59 -0000 Received: (qmail 2612 invoked by uid 22791); 18 Nov 2005 22:19:55 -0000 Received: from mx1.redhat.com (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Fri, 18 Nov 2005 22:19:55 +0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.11) with ESMTP id jAIMJsvL027727 for ; Fri, 18 Nov 2005 17:19:54 -0500 Received: from potter.sfbay.redhat.com (potter.sfbay.redhat.com [172.16.27.15]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id jAIMJqV22002; Fri, 18 Nov 2005 17:19:53 -0500 Received: from [172.16.24.50] (bluegiant.sfbay.redhat.com [172.16.24.50]) by potter.sfbay.redhat.com (8.12.8/8.12.8) with ESMTP id jAIMJkPe028302; Fri, 18 Nov 2005 17:19:48 -0500 Message-ID: <437E5380.2030703@redhat.com> Date: Sat, 19 Nov 2005 01:21:00 -0000 From: Michael Snyder User-Agent: Mozilla Thunderbird (X11/20050322) MIME-Version: 1.0 To: Eli Zaretskii CC: gdb-patches@sources.redhat.com Subject: Re: [RFA] Add new command class_experimental References: <437E38CA.1040300@redhat.com> <437E4335.2090509@redhat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2005-11/txt/msg00355.txt.bz2 Eli Zaretskii wrote: >>Date: Fri, 18 Nov 2005 13:10:13 -0800 >>From: Michael Snyder >>CC: gdb-patches@sources.redhat.com >> >> >>>Hmm... I'm not sure I like this idea. Why not add these as normal >>>commands? If it's useful and stable enough, people will use it. As >>>for possible bugs, the non-experimental stuff has those too. >> >>Well, because we *don't* regard it as stable. > > > If it is stable enough to go on HEAD (as opposed to a branch, which is > where we try out experimental ideas), it should be good enough to be > treated as a normal command, I think. That is, if someone reports a > bug that causes it to crash or produce badly incorrect results, we > will work to fix that, right? Yeah, but being 'experimental', we would not feel obligated to support it indefinitely, nor in particular to support its present user interface, should we decide to change or abandon it. However, I'll consider it a viable suggestion if you think we should just use a branch instead.