GDB 5.3.1 vs 5.4/6.0

GDB 5.3.1 vs 5.4/6.0

[Andrew Cagney]

Hello,

First, don't forget that the 5.3 branch is open.  Config and other fixes
can be committed.

Still, the question is: should the next release be 5.3.1, or 5.4/6.0?

5.3.1 would be something like end Jan / start Feb.
5.4/6.0 branch would be ~March.

(As for 5.4 vs 6.0, I don't think the multi-arch goal will have been
achieved.)

Andrew

Re: GDB 5.3.1 vs 5.4/6.0

[Joel Brobecker]

> Still, the question is: should the next release be 5.3.1, or 5.4/6.0?
> 
> 5.3.1 would be something like end Jan / start Feb.
> 5.4/6.0 branch would be ~March.

I think we have enough valuable fixes in the 5.3 branch to make a 5.3.1
release worth-while.

> (As for 5.4 vs 6.0, I don't think the multi-arch goal will have been
> achieved.)

Apart from HP/UX (my bad, sorry sorry sorry, I've been sooo busy, I
didn't even take a christmas break), which platforms still need to be
converted before we can go to 6.0?

-- 
Joel

Re: GDB 5.3.1 vs 5.4/6.0

[Andrew Cagney]

>> Still, the question is: should the next release be 5.3.1, or 5.4/6.0?
>> 
>> 5.3.1 would be something like end Jan / start Feb.
>> 5.4/6.0 branch would be ~March.
> 
> 
> I think we have enough valuable fixes in the 5.3 branch to make a 5.3.1
> release worth-while.

MichaelC in his last summary mentioned that no one had committed 
anything to the branch?

>> (As for 5.4 vs 6.0, I don't think the multi-arch goal will have been
>> achieved.)
> 
> 
> Apart from HP/UX (my bad, sorry sorry sorry, I've been sooo busy, I
> didn't even take a christmas break), which platforms still need to be
> converted before we can go to 6.0?

(HP/UX is bottom of my list in terms of worries - you've effectively got 
it under control!)

As for obsolete architectures, the remaining ones are:

m32r - no one came forward last time
mn10200 - dead
z8k - people keep poping up that use this!

The bigger problem is finishing off architectures such as MIPS.

Andrew

Re: GDB 5.3.1 vs 5.4/6.0

[Joel Brobecker]

> MichaelC in his last summary mentioned that no one had committed 
> anything to the branch?

Ah, sorry. I thought I had seen some checkins that went in the 5.3
branch after the 5.3 release, but double checking with the gdb
ChangeLog, I see that I was wrong. Sorry about that.

-- 
Joel

Re: GDB 5.3.1 vs 5.4/6.0

[Andrew Cagney]

>> MichaelC in his last summary mentioned that no one had committed 
>> anything to the branch?
> 
> 
> Ah, sorry. I thought I had seen some checkins that went in the 5.3
> branch after the 5.3 release, but double checking with the gdb
> ChangeLog, I see that I was wrong. Sorry about that.

M'kay.

I've seen a few `gdb doesn't build' postings / bug reports go by. 
Fixing those in a re-spin can be useful - gives those problems some closure.

I think the `until foo' breakage should also be at least put back to the 
old behavior.

Andrew

Re: GDB 5.3.1 vs 5.4/6.0

[Daniel Jacobowitz]

On Thu, Jan 02, 2003 at 03:32:48PM +0000, Andrew Cagney wrote:
> Hello,
> 
> First, don't forget that the 5.3 branch is open.  Config and other fixes
> can be committed.
> 
> Still, the question is: should the next release be 5.3.1, or 5.4/6.0?
> 
> 5.3.1 would be something like end Jan / start Feb.
> 5.4/6.0 branch would be ~March.
> 
> (As for 5.4 vs 6.0, I don't think the multi-arch goal will have been
> achieved.)

I recommend the way I've been doing binutils releases: leave the branch
open for a little, and if people find things that they want fixed in a
new release and handle getting them onto the branch, then do a 5.3.1
release.  Don't soak massive development time into it.  I have one
issue that I would probably want fixed in a 5.3.1, which is that
putting "call" in a breakpoints command list _still_ segfaults;
there're two patches for this still awaiting review.

One issue by itself isn't really enough to bother, though.

Re multiarch: HP/PA is progressing and I can help on that if needed; I
can even do the m32r if there is a perception that we still need it (is
there?) since there conveniently are GCC, sim, and binutils ports to
this target.  z8k has binutils and sim but no GCC port as far as I can
see; I could do it blindly, though, I wager - it's an impressively
minimal GDB port.  So if we want to hold out for multi-arch I bet we
could do it.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: GDB 5.3.1 vs 5.4/6.0

[Andrew Cagney]

> I recommend the way I've been doing binutils releases: leave the branch
> open for a little, and if people find things that they want fixed in a
> new release and handle getting them onto the branch, then do a 5.3.1
> release.  Don't soak massive development time into it.

Yes.  Play it by ear.

 > I have one
> issue that I would probably want fixed in a 5.3.1, which is that
> putting "call" in a breakpoints command list _still_ segfaults;
> there're two patches for this still awaiting review.
> 
> One issue by itself isn't really enough to bother, though.
> 
> Re multiarch: HP/PA is progressing and I can help on that if needed; I
> can even do the m32r if there is a perception that we still need it (is
> there?) since there conveniently are GCC, sim, and binutils ports to
> this target.  z8k has binutils and sim but no GCC port as far as I can
> see; I could do it blindly, though, I wager - it's an impressively
> minimal GDB port.  So if we want to hold out for multi-arch I bet we
> could do it.

Apparently there is an unofficial z8k compiler port somewhere.  The 
target should always be deleted rather than speculative converted.  cf 
the mn10200 which should have been deleted years ago.

I don't know of a good reason for hanging onto the m32r.

Andrew

Re: GDB 5.3.1 vs 5.4/6.0

[Michael Elizabeth Chastain]

Joel Brobecker writes:
> I think we have enough valuable fixes in the 5.3 branch to make a 5.3.1
> release worth-while.

Huh?  Every one of the valuable fixes are already in the gdb 5.3 release.
There's nothing more to release.  I mean that literally.  The only change
since the release is the version number bump to 5.3.0.90.

Are you saying that the 5.3 release has a lot of fixes that need to be
forward-ported to HEAD, or what?

Michael C

  % cvs diff -r gdb_5_3-12-12-release -r gdb_5_3-branch
  Index: gdb/ChangeLog
  ===================================================================
  RCS file: /cvs/src/src/gdb/ChangeLog,v
  retrieving revision 1.3181.2.54
  retrieving revision 1.3181.2.55
  diff -r1.3181.2.54 -r1.3181.2.55
  0a1,4
  > 2002-12-11  GDB Administrator  <gdbadmin@sourceware.org>
  >
  >       * version.in: Bump to version 5.3.0.90.
  >
  Index: gdb/version.in
  ===================================================================
  RCS file: /cvs/src/src/gdb/version.in,v
  retrieving revision 1.447.2.104
  retrieving revision 1.447.2.127
  diff -r1.447.2.104 -r1.447.2.127
  1c1
  < 5.3
  ---
  > 5.3.0.90_2003-01-02-cvs

Re: GDB 5.3.1 vs 5.4/6.0

[Michael Elizabeth Chastain]

Andrew Cagney asks:
> Still, the question is: should the next release be 5.3.1, or 5.4/6.0?

I prefer 5.4/6.0.  For a given # of developer hours, we can get more
done on a trunk than on a branch + trunk.

My 5.3 versus HEAD comparison tables are pretty healthy.  There are
no C++ regressions versus gdb (gcc is deteriorating but that is a
different story).  All the MI tests changed so I can't compare them
between 5.3 and HEAD, but HEAD doesn't have big screaming blocks
of non-PASSEes in MI.  There are about 5-10 things to look at overall
including the individual MI non-PASSes, which means there are probably
1-2 real bugs.

The bug database is pretty quiet.  There are about 10 bugs filed
against 5.3.  I don't feel like people are screaming at us for a 5.3.1.

Michael C