>>> As for some of the others, I think they would be better served as
>>> notes in the documentation (i.e., gdb.texinfo).
> 
> 
> That's a good point - if we want to make users aware of certain
> well-known bugs, then gdb.texinfo is a much more visible place than
> PROBLEMS.  (Nobody will see PROBLEMS other than possibly the specific
> individual, if any, who is installing that version of GDB by hand.)
> GCC has a section of known bugs in its manual; we should follow suit.

Right, now we're getting somewhere.

I've attached the original PROBLEMS file from 5.1.  Looking through the 
file it's pretty clear what the [my] original intent was - late breaking 
stuff-ups.  It strongly suggests using the same criteria as the release 
process:

	"doesn't build, break main; run doesn't work"
however, also including:
	"problems instead fixed in mainline"

would be a good get-out-of goal free card.

A list of "medium"(1) !change-request "bugs" would be easy to generate. 
  Properly @anchor{}ed it could even be cross referenced from the main 
text (but lets walk before we can run).  That could be included in the 
doco as an appendix.

>>>>> Personally, the old division makes more sense to me: a list of all
>>>>> regressions, plus some more serious outstanding issues.  Obviously the
>>>>> header "Regressions since 5.3" should be changed, however.
> 
> 
>>> How about: serious problems that have been fixed in the mainline but
>>> are too nasty to backport?
> 
> 
> The "breakpoints in constructors" bug isn't fixed in mainline,
> either.

(it's actually the GDB doesn't support N:M breakpoints bug but that's 
another story :-) It should be in the doco.

Andrew


(1) "high" gets used by me when doing a release process.  Everyone knows 
that "low" translates to "won't fix" right ;-)