From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14137 invoked by alias); 19 Nov 2010 22:16:29 -0000 Received: (qmail 14128 invoked by uid 22791); 19 Nov 2010 22:16:29 -0000 X-SWARE-Spam-Status: No, hits=-2.1 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 19 Nov 2010 22:16:20 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 3115C2BACE3; Fri, 19 Nov 2010 17:16:19 -0500 (EST) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id GoD3pW200EXi; Fri, 19 Nov 2010 17:16:19 -0500 (EST) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id F21B32BACCC; Fri, 19 Nov 2010 17:16:18 -0500 (EST) Received: by joel.gnat.com (Postfix, from userid 1000) id 6D7101457E0; Fri, 19 Nov 2010 14:16:15 -0800 (PST) Date: Fri, 19 Nov 2010 22:16:00 -0000 From: Joel Brobecker To: Tom Tromey Cc: gdb-patches@sourceware.org Subject: Re: Ping: unconditionally print detaching message Message-ID: <20101119221615.GK2634@adacore.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) 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: 2010-11/txt/msg00273.txt.bz2 > While going through the Fedora patch backlog I ran into this: > > http://sources.redhat.com/ml/gdb-patches/2007-12/msg00087.html > > This has just one reply, from Daniel, asking Jan to see what the other > maintainers think. FWIW: I don't really have an opinion either way. Some people are going to find it annoying if they are too many forks going on (unlikely?), while some others might have their life saved by it (but that's provided we keep the number of warnings small). > It occurred to me that perhaps we could instead have a setting for this. > I am ambivalent about that but if that is what people want, I will > implement it. We could introduce message without a setting for now - the fewer, the better (IMO). And if people complain about it, then introduce one to prevent from being printed if the user so wishes... -- Joel