From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20831 invoked by alias); 31 Oct 2004 22:28:52 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 20784 invoked from network); 31 Oct 2004 22:28:51 -0000 Received: from unknown (HELO walton.sibelius.xs4all.nl) (82.92.89.47) by sourceware.org with SMTP; 31 Oct 2004 22:28:51 -0000 Received: from elgar.sibelius.xs4all.nl (elgar.sibelius.xs4all.nl [192.168.0.2]) by walton.sibelius.xs4all.nl (8.13.0/8.13.0) with ESMTP id i9VMSk7j011279; Sun, 31 Oct 2004 23:28:46 +0100 (CET) Received: from elgar.sibelius.xs4all.nl (localhost [127.0.0.1]) by elgar.sibelius.xs4all.nl (8.12.6p3/8.12.6) with ESMTP id i9VMSkSq003134; Sun, 31 Oct 2004 23:28:46 +0100 (CET) (envelope-from kettenis@elgar.sibelius.xs4all.nl) Received: (from kettenis@localhost) by elgar.sibelius.xs4all.nl (8.12.6p3/8.12.6/Submit) id i9VMSfcQ003129; Sun, 31 Oct 2004 23:28:41 +0100 (CET) Date: Sun, 31 Oct 2004 22:28:00 -0000 Message-Id: <200410312228.i9VMSfcQ003129@elgar.sibelius.xs4all.nl> From: Mark Kettenis To: cagney@gnu.org CC: drow@false.org, gdb-patches@sources.redhat.com In-reply-to: <418545F4.8060401@gnu.org> (message from Andrew Cagney on Sun, 31 Oct 2004 15:07:16 -0500) Subject: Re: [COMMIT] OpenBSD/mips64 target and native support References: <200410231216.i9NCG6YK023827@elgar.sibelius.xs4all.nl> <417D1A69.2070904@gnu.org> <20041025152912.GA28110@nevyn.them.org> <417D4D56.80003@gnu.org> <4185314C.7020307@gnu.org> <200410311945.i9VJjMoG002666@elgar.sibelius.xs4all.nl> <418545F4.8060401@gnu.org> X-SW-Source: 2004-10/txt/msg00561.txt.bz2 Date: Sun, 31 Oct 2004 15:07:16 -0500 From: Andrew Cagney > Scaring away contributors by making unreasonable demands isn't a > sensible thing to do. Our situtation here is identical to what we encountered with basic multi-arch, the frame code, the regcace code, the function call code. There, with our help and co-operation, people not just stepped up to, but also exceeded the challenge. I strongly disagree. The shared library code touches core parts of GDB. There's no way an outsider is going to be able to fix that properly, especially since changes will have to be tested on a multitude of platforms. There is also absolutely no visible benefit from making the required changes. This is something the shared library maintainer and core maintainers have to sort out. It's going to take quite a bit of time to do so. In the mean time it is unfair to contributors to simply refuse contribution of any new code. Mark