From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 945 invoked by alias); 11 Oct 2008 02:43:21 -0000 Received: (qmail 30319 invoked by uid 22791); 10 Oct 2008 18:58:52 -0000 X-Spam-Check-By: sourceware.org Received: from NaN.false.org (HELO nan.false.org) (208.75.86.248) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 10 Oct 2008 18:58:12 +0000 Received: from nan.false.org (localhost [127.0.0.1]) by nan.false.org (Postfix) with ESMTP id 4FE7B10194; Fri, 10 Oct 2008 18:58:09 +0000 (GMT) Received: from caradoc.them.org (22.svnf5.xdsl.nauticom.net [209.195.183.55]) by nan.false.org (Postfix) with ESMTP id EFA0A1018D; Fri, 10 Oct 2008 18:58:08 +0000 (GMT) Received: from drow by caradoc.them.org with local (Exim 4.69) (envelope-from ) id 1KoNBg-0003Kj-3n; Fri, 10 Oct 2008 14:58:08 -0400 Date: Sat, 11 Oct 2008 02:43:00 -0000 From: Daniel Jacobowitz To: Michael Snyder Cc: "gdb-patches@sourceware.org" Subject: Re: [RFA] Resubmit, reverse debugging [0/5] Message-ID: <20081010185808.GA12193@caradoc.them.org> Mail-Followup-To: Michael Snyder , "gdb-patches@sourceware.org" References: <48EC1781.2030005@vmware.com> <48EF93A5.7060808@vmware.com> <20081010175332.GA9028@caradoc.them.org> <48EFA065.5070108@vmware.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <48EFA065.5070108@vmware.com> User-Agent: Mutt/1.5.17 (2008-05-11) X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2008-10/txt/msg00328.txt.bz2 On Fri, Oct 10, 2008 at 11:35:17AM -0700, Michael Snyder wrote: > OK, I agree -- but it's in use, in the field. > > Wouldn't the practice be to deprecate it, and announce > the intention of removing it at some future time, rather > than just suddenly take it away? Sorry, but it's hard to be sympathetic to this. I go through this on a regular basis, so do other GDB contributors: it's the risk you take for deploying things before they're merged. If you don't get at least the protocol documentation committed to the master repository, then this is what happens. Speaking of documentation, is there a documentation part for the remote protocol changes? I haven't seen one in the most recent patch set, and I don't want any new protocol extensions without docs (for the obvious reason). -- Daniel Jacobowitz CodeSourcery