Mirror of the gdb mailing list
 help / color / mirror / Atom feed
* Re: GDB 6.1 branch 2004-02-26-gmt
@ 2004-02-20  1:19 Michael Elizabeth Chastain
  2004-02-21 16:14 ` Eli Zaretskii
  0 siblings, 1 reply; 3+ messages in thread
From: Michael Elizabeth Chastain @ 2004-02-20  1:19 UTC (permalink / raw)
  To: cagney, gdb

Well, the regression list I have is:

  http://sources.redhat.com/gdb/bugs/826
  variables in C++ namespacs have to be enclosed in quotes

  http://sources.redhat.com/gdb/bugs/931
  GDB could be more generous when reading types C++ templates on input

  http://sources.redhat.com/gdb/bugs/1505
  [regression] gdb prints a bad backtrace for a thread

  http://sources.redhat.com/gdb/bugs/1512
  no canonical way to output names of C++ types

  http://sources.redhat.com/gdb/bugs/1516
  [regression] local classes, gcc 2.95.3, dwarf-2

These are regressions from gdb 6.0 to gdb HEAD.

I'm comfortable documenting them in PROBLEMS and leaving these
bugs in 6.1.

Michael C


^ permalink raw reply	[flat|nested] 3+ messages in thread
* GDB 6.1 branch 2004-02-26-gmt
@ 2004-02-20  0:34 Andrew Cagney
  0 siblings, 0 replies; 3+ messages in thread
From: Andrew Cagney @ 2004-02-20  0:34 UTC (permalink / raw)
  To: gdb

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.}


^ permalink raw reply	[flat|nested] 3+ messages in thread
end of thread, other threads:[~2004-02-21 16:14 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-02-20  1:19 GDB 6.1 branch 2004-02-26-gmt Michael Elizabeth Chastain
2004-02-21 16:14 ` Eli Zaretskii
  -- strict thread matches above, loose matches on Subject: below --
2004-02-20  0:34 Andrew Cagney

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox