This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
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.
> 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.
(gdb) break main (gdb) run (gdb) bt (gdb) print foo
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |