From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15906 invoked by alias); 18 Nov 2005 21:10:20 -0000 Received: (qmail 15894 invoked by uid 22791); 18 Nov 2005 21:10:17 -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 21:10:17 +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 jAILAGnd007433 for ; Fri, 18 Nov 2005 16:10:16 -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 jAILAFV32208; Fri, 18 Nov 2005 16:10:15 -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 jAILADPe023844; Fri, 18 Nov 2005 16:10:14 -0500 Message-ID: <437E4335.2090509@redhat.com> Date: Fri, 18 Nov 2005 21:41: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> 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/msg00345.txt.bz2 Eli Zaretskii wrote: >>Date: Fri, 18 Nov 2005 12:25:46 -0800 >>From: Michael Snyder >> >>This is to add a new category of gdb commands, "experimental". >>These will be explicitly "use at your own risk", and gdb will >>tell you so. > > > 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. Still using the rcore command as the canonical example, it's highly experimental, nowhere near "finished", and we can't even characterize when it will work, and when it won't. I would not feel comfortable inviting an unsophisticated user to use it, and I wouldn't want to take on the task of explaining to an unsophisticated user the circumstances under which it might or might not be safe to use. I think of this as a compromise, to encourage collaborative development. Of course I'm willing to just leave the rcore command out there as a patch, but I figured there could easily be other features like it, that we might want to "try out" without implying that they are generally safe, stable, or "finished".