From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2488 invoked by alias); 28 Sep 2003 07:29:38 -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 2474 invoked from network); 28 Sep 2003 07:29:35 -0000 Received: from unknown (HELO bilbo.inter.net.il) (192.114.186.18) by sources.redhat.com with SMTP; 28 Sep 2003 07:29:35 -0000 Received: from zaretski ([80.230.149.110]) by bilbo.inter.net.il (Mirapoint Messaging Server MOS 3.3.7-GR) with ESMTP id BNL05188; Sun, 28 Sep 2003 10:29:26 +0300 (IDT) Date: Sun, 28 Sep 2003 08:40:00 -0000 From: "Eli Zaretskii" To: Andrew Cagney Message-Id: <2427-Sun28Sep2003102631+0300-eliz@elta.co.il> CC: jimb@redhat.com, gdb@sources.redhat.com In-reply-to: <3F75D8D3.2090207@redhat.com> (message from Andrew Cagney on Sat, 27 Sep 2003 14:37:07 -0400) Subject: Re: Tracepoint support in Cygnus GDB ? Reply-to: Eli Zaretskii References: <3F717475.33E13BC4@india.hp.com> <6654-Wed24Sep2003201904+0300-eliz@elta.co.il> <3F72FF8C.3080104@redhat.com> <6654-Sat27Sep2003132618+0300-eliz@elta.co.il> <3F75A491.4010203@redhat.com> <1659-Sat27Sep2003204134+0300-eliz@elta.co.il> <3F75D8D3.2090207@redhat.com> X-SW-Source: 2003-09/txt/msg00343.txt.bz2 > Date: Sat, 27 Sep 2003 14:37:07 -0400 > From: Andrew Cagney > > > Still, it's disturbing, to put it mildly, that I hadn't seen any > > significant new features in a long while. > > That isn't correct. GDB 6.0 does contain a significant number of user > visible features: hosted file I/O (which is embedded), TLS, NPTL, > separate debug info (which will help embedded), useable java, follow > fork, ... Sorry, this doesn't refute what I said: TLS, NPTL, separate debug info, and follow-fork features work on GNU/Linux only. Hosted I/O is only useful for embedded targets, and Java is only useful for Java programmers. I did say in my original message that GNU/Linux was an exception: most of the new features work only on that system. Your list supports what I said. What I was after was significant new features for native debugging that would work not only on GNU/Linux, and not only for some specific programming language. If the main maintenance effort until now was supposed to make addition of such features easier, then I applaud that effort and am sympathetic to it, but I still am impatient to see the features themselves. > > Perhaps we should decide on > > a list of new features that the next release should have, and start > > working on them. > > We've tried that, most recently with 6.0 and some MI features, and > failed. How did we fail, exactly? What were the reasons for the failure? Perhaps we could learn from past mistakes and do better next time? > As a group we found it necessary to largely disconnect release > cycles from feature cycles. Instead releases based are based more on > the calendar (yes this one is badly late) than some arbitrary feature list. These two goals not necessarily contradict. We could set up a list of features that are to be included in the next release, and if some of the features are not ready in time, make a release without them. IMHO, having a relatively short list of user-level features that are first priority would be a good aid for maintainers, in setting their priority to review patches, if for nothing else.