GDB 7.9 branching - 2 weeks to go (Mon, Jan 12th)!

GDB 7.9 branching - 2 weeks to go (Mon, Jan 12th)!

[Joel Brobecker]

Hello,

Just a quick reminder that we're about 2 weeks away from our targeted
branching date for GDB 7.9. Jan 12th is only a week after what I expect
to be most people's return to work (Mon Jan 5th), so might be a little
tight.

But, at the moment, there is no blocking item listed. I will add
PR gdb/17525 (target-async: breakpoint commands not executed when
program run from -x script), but only blocking for the release.
I don't think the problem is severe enough that it warrants blocking
the branch.

-- 
Joel

Re: GDB 7.9 branching - 2 weeks to go (Mon, Jan 12th)!

[Eli Zaretskii]

> Date: Tue, 30 Dec 2014 11:15:00 +0400
> From: Joel Brobecker <brobecker@adacore.com>
> 
> Just a quick reminder that we're about 2 weeks away from our targeted
> branching date for GDB 7.9. Jan 12th is only a week after what I expect
> to be most people's return to work (Mon Jan 5th), so might be a little
> tight.

What about 7.8.2 -- is it still going to happen?  If so, when
approximately?

Thanks.

Re: GDB 7.9 branching - 2 weeks to go (Mon, Jan 12th)!

[Joel Brobecker]

> > Just a quick reminder that we're about 2 weeks away from our targeted
> > branching date for GDB 7.9. Jan 12th is only a week after what I expect
> > to be most people's return to work (Mon Jan 5th), so might be a little
> > tight.
> 
> What about 7.8.2 -- is it still going to happen?  If so, when
> approximately?

I hope so.

When depends on when the issues actually get fixed, but as soon as
they do.  There is one assigned to me that I currently have no time
to look into, so it might be a while, unfortunately. There is another
assigned to me that's just a matter of backporting from master, so
easily dealt with. The last one is marked as assigned to Phil with a
question mark...

If it drags on for too long, we might decide to get 7.8.2 out the door
without some of the fixes we wanted...

-- 
Joel

Re: GDB 7.9 branching - 2 weeks to go (Mon, Jan 12th)!

[Jan Kratochvil]

On Tue, 30 Dec 2014 08:15:00 +0100, Joel Brobecker wrote:
> But, at the moment, there is no blocking item listed.

I find as a blocker the regression already filed for 7.8.x:
	https://sourceware.org/gdb/wiki/GDB_7.8_Release
	[Phil?] PR cli/17716 ([7.7 regression] Backtrace cannot be stopped by 'q' or CTRL-C) 
	https://sourceware.org/bugzilla/show_bug.cgi?id=17716

Therefore I have copied the TODO item now also for 7.9:
	https://sourceware.org/gdb/wiki/GDB_7.9_Release?action=diff&rev2=4&rev1=3

For some reason it did not reproduce in real world of F-20 (7.7) but it does
reproduce in F-21 (7.8) which I find very annoying as a GDB user.


Jan

Re: GDB 7.9 branching - 2 weeks to go (Mon, Jan 12th)!

[Joel Brobecker]

> Just a quick reminder that we're about 2 weeks away from our targeted
> branching date for GDB 7.9. Jan 12th is only a week after what I expect
> to be most people's return to work (Mon Jan 5th), so might be a little
> tight.

One more week to go, if we still maintain the original target date...

-- 
Joel

Re: GDB 7.9 branching - 2 weeks to go (Mon, Jan 12th)!

[Doug Evans]

On Sun, Jan 4, 2015 at 8:10 PM, Joel Brobecker <brobecker@adacore.com> wrote:
>> Just a quick reminder that we're about 2 weeks away from our targeted
>> branching date for GDB 7.9. Jan 12th is only a week after what I expect
>> to be most people's return to work (Mon Jan 5th), so might be a little
>> tight.
>
> One more week to go, if we still maintain the original target date...

Dang.  For some reason I had the 19th stuck in my mind.

I owe a few people some reviews.

Re: GDB 7.9 branching - 2 weeks to go (Mon, Jan 12th)!

[Joel Brobecker]

> > One more week to go, if we still maintain the original target date...
> 
> Dang.  For some reason I had the 19th stuck in my mind.
> I owe a few people some reviews.

Depending on the patches, we might be able to branch while accepting
they be ported to the branch. If too complex, however, then we can
also delay the creation of the branch, if we feel it would make sense
to do so.

-- 
Joel

Re: GDB 7.9 branching - 2 weeks to go (Mon, Jan 12th)!

[Eli Zaretskii]

> Date: Mon, 5 Jan 2015 08:10:18 +0400
> From: Joel Brobecker <brobecker@adacore.com>
> 
> > Just a quick reminder that we're about 2 weeks away from our targeted
> > branching date for GDB 7.9. Jan 12th is only a week after what I expect
> > to be most people's return to work (Mon Jan 5th), so might be a little
> > tight.
> 
> One more week to go, if we still maintain the original target date...

Would someone please review the patches I posted here:

  https://sourceware.org/ml/gdb-patches/2014-12/msg00693.html
  https://sourceware.org/ml/gdb-patches/2014-12/msg00694.html
  https://sourceware.org/ml/gdb-patches/2014-12/msg00695.html
  https://sourceware.org/ml/gdb-patches/2014-12/msg00696.html
  https://sourceware.org/ml/gdb-patches/2015-01/msg00021.html

Please?

Re: GDB 7.9 branching - 2 weeks to go (Mon, Jan 12th)!

[Steve Ellcey]

On Tue, 2014-12-30 at 11:15 +0400, Joel Brobecker wrote:
> Hello,
> 
> Just a quick reminder that we're about 2 weeks away from our targeted
> branching date for GDB 7.9. Jan 12th is only a week after what I expect
> to be most people's return to work (Mon Jan 5th), so might be a little
> tight.
> 
> But, at the moment, there is no blocking item listed. I will add
> PR gdb/17525 (target-async: breakpoint commands not executed when
> program run from -x script), but only blocking for the release.
> I don't think the problem is severe enough that it warrants blocking
> the branch.

I think PR gdb/17718 should be considered a blocking bug because it
breaks the builds on some systems (depending on what version of GCC is
used to build).

There is some discussion of how it should be fixed in the defect report
and in https://sourceware.org/ml/gdb-patches/2014-12/msg00501.html and
other email threads.

Steve Ellcey
sellcey@imgtec.com

Re: GDB 7.9 branching - 2 weeks to go (Mon, Jan 12th)!

[Joel Brobecker]

> I think PR gdb/17718 should be considered a blocking bug because it
> breaks the builds on some systems (depending on what version of GCC is
> used to build).

It should not break the build, actually, because releases are configured
to make --disable-werror the default. The change is performed as soon as
the branch is cut. So we should be OK.

-- 
Joel