GDB 6.1 branch 2004-02-26-gmt

[Andrew Cagney <cagney at gnu dot org>]

Hello,

It's time has come.  Things appear to have died down, and the backlog 
sufficiently drained, for the GDB 6.1 branch to be cut.  With about a 
week's notice I'm planning on:

	-D 2004-02-26-gmt

as the branch date.  If things go to plan, that makes the ideal release 
date:

	-D 2004-04-14-gmt (6 weeks)

So can I suggest treating the next week as something of a quiet period 
(....).

Right now the bug database shows:

378 	``GNU/Linux'' ``Linux kernel''

as the only high/build PR (that can't be right).

enjoy,
Andrew


PS: Branch Commit Policy

The branch commit policy is pretty slack.

@itemize @bullet
@item
The @file{gdb/MAINTAINERS} file still holds.
@item
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 @file{gdb/PROBLEMS}
file is better than committing a hack.
@item
When considering a patch for the branch, suggested criteria include:
Does it fix a build?  Does it fix the sequence @kbd{break main; run}
when debugging a static binary?
@item
The further a change is from the core of @value{GDBN}, the less likely
the change will worry anyone (e.g., target, architecture, or system
specific code).
@item
Only post a proposal to change the core of @value{GDBN} after you've
sent individual bribes to all the people listed in the
@file{MAINTAINERS} file @t{;-)}
@item
Only the very brave or very foolish would try to apply the obvious fix
rule to the branch.
@end itemize

@emph{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.}