Re: GDB 6.1 branch end jan?

[Andrew Cagney <cagney@gnu.org>]

PS:

I need to remember to include the following information in this initial 
post.  I always seem to receive a slew of private e-mails asking if some 
yet to be contributed/announced "port" (architecture or system) can be 
squeesed into the next release.

Per:
http://sources.redhat.com/gdb/current/onlinedocs/gdbint_15.html#SEC132

--

15.2 Branch Commit Policy

The branch commit policy is pretty slack. GDB releases 5.0, 5.1 and 5.2 
all used the below:

* The `gdb/MAINTAINERS' file still holds.
* Don't fix something on the branch unless/until it is also fixed in the 
trunk. If this isn't possible, mentioning it in the `gdb/PROBLEMS' file 
is better than committing a hack.
* When considering a patch for the branch, suggested criteria include: 
Does it fix a build? Does it fix the sequence break main; run when 
debugging a static binary?
* The further a change is from the core of GDB, the less likely the 
change will worry anyone (e.g., target specific code).
* Only post a proposal to change the core of GDB after you've sent 
individual bribes to all the people listed in the `MAINTAINERS' file ;-)

Pragmatics: Provided updates are restricted to non-core functionality 
there is little chance that a broken change will be fatal. This means 
that changes such as adding a new architectures or (within reason) 
support for a new host are considered acceptable.

--

I should also note that with 6.0, significant flexability was afforded 
to people trying to frame-ify their architecture.

Andrew