Re: Tracepoint support in Cygnus GDB ?

["Eli Zaretskii" <eliz@elta.co.il>]

> Date: Sat, 27 Sep 2003 14:37:07 -0400
> From: Andrew Cagney <ac131313@redhat.com>
> 
> > 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.