Re: [rfa/doco] PROBLEMS: add regressions since gdb 6.0

[David Carlton <carlton@kealia.com>]

On Wed, 17 Mar 2004 14:30:26 -0500 (EST), mec.gnu@mindspring.com (Michael Elizabeth Chastain) said:

>> So I think the testsuite regression=>PR+description transition
>> should involve some more steps - the corresponding PR may be much
>> broader than the particular testsuite regression, and some of those
>> broader areas may involve situations where GDB has improved rather
>> than regressed.

> My first impulse is to pop open a more narrow, more accurate PR
> for "print (ClassWithEnum::PrivEnum) 42".  What do you think?

I'll go and do that.

> I agree with you; there is a step where we have to translate
> PR gdb/NNNN into text for PROBLEMS.  The text in PROBLEMS has to
> be accurate, and I want it to actually cover all the regression
> problems that we know about.  And it's also better if it's narrow,
> because the more narrow it is, the more users can say "okay, THAT
> bug does not affect me, I can upgrade".

> (I think regressions are special compared to regular bugs because if
> someone is using gdb 5.3 or gdb 6.0, and they are considering
> upgrading to gdb 6.1, then the new regressions are the bugs that are
> most important to them).

Those paragraphs make sense to me.

I think one of the things that is bothering me is that we're
highlighting new bugs but not highlighting bugs that have been fixed.
Some of the latter is in NEWS, but NEWS is both at a higher level (it
doesn't mention specific PR numbers) and it tends to concentrate on
new features, which isn't quite the same thing.  For GCC releases,
Gerald Pfeifer (if I'm remembering correctly) goes through the list of
GCC bugs and provides a table of all of the ones that have been fixed
in that particular release (breaking them down into categories);
besides making GCC developers feel good, it can also help users decide
when to upgrade, because they can look at the list of bugs that have
been fixed in the categories that they care about and see how
important those bugs are to them.

Of course, it helps that GCC has several people who try to make sure
that their bug database is as up to date as possible and organized in
such a way as to make it easy to figure out this information.  Whereas
you're the only person seriously looking at the GDB bug database, and
you're also focused (perhaps more focused) on regression testing.

David Carlton
carlton@kealia.com