From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10803 invoked by alias); 13 Dec 2003 19:40:20 -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 10789 invoked from network); 13 Dec 2003 19:40:18 -0000 Received: from unknown (HELO localhost.redhat.com) (65.49.0.121) by sources.redhat.com with SMTP; 13 Dec 2003 19:40:18 -0000 Received: from gnu.org (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 996EC2B8F; Sat, 13 Dec 2003 14:40:13 -0500 (EST) Message-ID: <3FDB6B1D.9000104@gnu.org> Date: Sat, 13 Dec 2003 19:40:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.2) Gecko/20030820 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eli Zaretskii , Michael Elizabeth Chastain Cc: gdb@sources.redhat.com Subject: Re: [commit] Deprecate remaining STREQ uses References: <20031213152356.AFC9E4B412@berman.michael-chastain.com> <1190-Sat13Dec2003182933+0200-eliz@elta.co.il> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-12/txt/msg00192.txt.bz2 > Hi Eli, > > >> If you are proposing a change in the current strategy, this issue >> should be discussed (on gdb@, I guess). > > > Okay. > > >> For startesr, please define the ``long time'' after which it is okay, in >> your opinion, to deprecate a platform. > > > Three minor releases. That would be ~18 months which is significantly longer than the current process. But then again, the current process starts several (like 10) years later than I suspect is being suggested here. > Supporting untested code costs resources because we can't upgrade the > code to use new interfaces. If we drop untested code, it will be easier > to do work on the tested code. By testing, you mean run through the testsuite? Yes. We're caught between a rock and a hard place. Do a blind rewrite of the old code (which is effectively guarenteed to be wrong but will let us fool ourselves into thinking its "fixed"); retain backward compatibility until it gets updated (which is guarenteed to suffer bitrot but hopefully less likely to immediatly break - presumably at the time of the change both the old and new ways were tested); remove the relevant code. At present, by doing a combination of the latter two, we're able to extract an extra year or so out of the unmaintained code with not too much effort. > If we want to drop a platform, and a user wants to keep it supported, > then they can volunteer to run the gdb test suite on it occasionally. We already have the occasional but steady updates/fixes that are made to architectures by architecture maintainers (and others). Andrew