From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25808 invoked by alias); 15 Dec 2003 15:51:16 -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 25799 invoked from network); 15 Dec 2003 15:51:15 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sources.redhat.com with SMTP; 15 Dec 2003 15:51:15 -0000 Received: from drow by nevyn.them.org with local (Exim 4.24 #1 (Debian)) id 1AVv03-0003gt-T9; Mon, 15 Dec 2003 10:51:11 -0500 Date: Mon, 15 Dec 2003 15:51:00 -0000 From: Daniel Jacobowitz To: Eli Zaretskii Cc: Michael Elizabeth Chastain , cagney@gnu.org, gdb@sources.redhat.com Subject: Re: [commit] Deprecate remaining STREQ uses Message-ID: <20031215155111.GA13947@nevyn.them.org> Mail-Followup-To: Eli Zaretskii , Michael Elizabeth Chastain , cagney@gnu.org, gdb@sources.redhat.com References: <20031215062230.CD6E94B412@berman.michael-chastain.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.1i X-SW-Source: 2003-12/txt/msg00211.txt.bz2 On Mon, Dec 15, 2003 at 08:41:13AM +0200, Eli Zaretskii wrote: > I agree that your suggestion will probably leave us with less bugs. > But I'm concerned that we could inadvertently spill the baby, if we > assume that any port that hasn't seen official testing does not work > and should be obsoleted. ... > The constructive action that could come out of this, in my view, is if > we agree that hasty removal of support for platforms is potentially > destructive and should be used with great caution. > > What about others: am I the only one who thinks we shouldn't be > obsoleting platforms hastily for lack of officially-certified testing? This isn't a new issue, and it's not one with easy answers. I also think that Michael's stance is a little too harsh - good for an ideal world, where we had more resources than we do (despite his absolutely heroic efforts), but... I am more interested in the removal of _unmaintained_ targets than in the removal of _untested_ targets. Normally these coincide; if they don't for DJGPP then that's not a major problem to me. We have a couple of targets whose maintainers we haven't heard from in a while, but they are likely to still work. Looking at the list the only ones I'm immediately worried about are d10v, mcore, mn10300, ns32k, v850, vax. Some of the others (like m32r) have seen a lot of activity. I'd be terrified about sparc if Mark hadn't started to overhaul it. I remain worried about Solaris specifically. We get a lot of Solaris bug reports that go unanswered. > My comment to this is that we should sometimes think about users, not > only developers. Being overly harsh to the users by removing support > for their platforms too quickly is something I think we should avoid. The alternative is finding that the platform hasn't actually worked in three releases. By the way, is there any reason DJGPP couldn't be tested in Bochs, qemu, vmware, plex86, or some other new system emulator I haven't heard of yet? With qemu I suspect you could even make that scriptable, but it would take some serious hacking - use the qemu console like a telnet session. Now that would be cool. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer