GDB 6.7 branch creation scheduled June 10th

GDB 6.7 branch creation scheduled June 10th

[Joel Brobecker]

Hello everyone,

Just a quick message to remind you that the schedule date for
the next (6.7) gdb branch is June 10th (Sun). The branch will
actually be cut a little later, but using a date in the past
as the branch point.

Anything that should be done before the branch is cut?

[Daniel: I'm supposed to remind you about the signed/unsigned char
 display issue - I confess that I don't remember whether this has
 been dealt with or not]

-- 
Joel

Re: GDB 6.7 branch creation scheduled June 10th

[Nick Roberts]

 > Anything that should be done before the branch is cut?
 > 
 > [Daniel: I'm supposed to remind you about the signed/unsigned char
 >  display issue - I confess that I don't remember whether this has
 >  been dealt with or not]

I'm not fussed about the signed/unsigned char display issue as it has a
workaround, but I would like the regression regarding annotations to be
resolved before the branch is cut.

See http://www.sourceware.org/ml/gdb/2007-06/msg00022.html

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: GDB 6.7 branch creation scheduled June 10th

[Daniel Jacobowitz]

On Thu, Jun 07, 2007 at 11:19:02PM -0700, Joel Brobecker wrote:
> [Daniel: I'm supposed to remind you about the signed/unsigned char
>  display issue - I confess that I don't remember whether this has
>  been dealt with or not]

It hasn't.  I've just moved house, but I may have time to work on it
this week - I was just thinking about it in fact.

-- 
Daniel Jacobowitz
CodeSourcery

Re: GDB 6.7 branch creation scheduled June 10th

[Thiago Jung Bauermann]

Hi,

On Thu, 2007-06-07 at 23:19 -0700, Joel Brobecker wrote:
> Hello everyone,
> 
> Just a quick message to remind you that the schedule date for
> the next (6.7) gdb branch is June 10th (Sun). The branch will
> actually be cut a little later, but using a date in the past
> as the branch point.
> 
> Anything that should be done before the branch is cut?

I posted this patch to the list a while back:

http://sourceware.org/ml/gdb-patches/2007-04/msg00359.html

If the patch is ok, I'd like to ask for its inclusion in GDB 6.7.
-- 
[]'s
Thiago Jung Bauermann
Software Engineer
IBM Linux Technology Center

Re: GDB 6.7 branch creation scheduled June 10th

[Daniel Jacobowitz]

On Thu, Jun 14, 2007 at 03:50:58PM -0300, Thiago Jung Bauermann wrote:
> I posted this patch to the list a while back:
> 
> http://sourceware.org/ml/gdb-patches/2007-04/msg00359.html
> 
> If the patch is ok, I'd like to ask for its inclusion in GDB 6.7.

I believe Joseph was looking at this patch earlier, and it was not
working properly for him.  Joseph, was that the same patch?

Further comments, please reply to the patch instead of this message,
please.

-- 
Daniel Jacobowitz
CodeSourcery

Re: GDB 6.7 branch creation scheduled June 10th

[Joseph S. Myers]

On Thu, 14 Jun 2007, Daniel Jacobowitz wrote:

> On Thu, Jun 14, 2007 at 03:50:58PM -0300, Thiago Jung Bauermann wrote:
> > I posted this patch to the list a while back:
> > 
> > http://sourceware.org/ml/gdb-patches/2007-04/msg00359.html
> > 
> > If the patch is ok, I'd like to ask for its inclusion in GDB 6.7.
> 
> I believe Joseph was looking at this patch earlier, and it was not
> working properly for him.  Joseph, was that the same patch?

Yes, it's that patch; I've posted my comments on it.

http://sourceware.org/ml/gdb-patches/2007-06/msg00287.html

-- 
Joseph S. Myers
joseph@codesourcery.com

DELAYED: GDB 6.7 branch creation scheduled June 25th

[Joel Brobecker]

Hello everyone,

Sorry, I'm a bit stuck right now and for the next few days.
I will be in New York next week, and will create the branch
from there.

I was going to use the 2007-06-17 date where to start the branch,
but I might reconsider:
  . Extensive gdbarch changes made by Markus and Ulrich
    These should be pretty safe, and yet not including them in the
    branch might complicate branch patch merging later on
  . Daniel's adjustment in configure.ac ($objdir issue)

Also, this would allow us to include recent improvements such as:
  . the qOffsets changes

I think there are also a couple of items that Daniel and someone
else wanted in...

So I'll re-evaluate the situation on Monday.

-- 
Joel

Re: DELAYED: GDB 6.7 branch creation scheduled June 25th

[H. J. Lu]

On Thu, Jun 21, 2007 at 11:15:30AM -0700, Joel Brobecker wrote:
> Hello everyone,
> 
> Sorry, I'm a bit stuck right now and for the next few days.
> I will be in New York next week, and will create the branch
> from there.
> 
> I was going to use the 2007-06-17 date where to start the branch,
> but I might reconsider:
>   . Extensive gdbarch changes made by Markus and Ulrich
>     These should be pretty safe, and yet not including them in the
>     branch might complicate branch patch merging later on
>   . Daniel's adjustment in configure.ac ($objdir issue)
> 
> Also, this would allow us to include recent improvements such as:
>   . the qOffsets changes
> 
> I think there are also a couple of items that Daniel and someone
> else wanted in...
> 
> So I'll re-evaluate the situation on Monday.

gcore doesn't work properly on Linux/ia64. I can only get the first
frame:

[hjl@gnu-14 gcore-1]$ ./gdb gcore core.8246 
GNU gdb 6.6.50.20070619-cvs
Copyright (C) 2007 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and
you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for
details.
This GDB was configured as "ia64-unknown-linux-gnu"...
Using host libthread_db library "/lib/tls/libthread_db.so.1".

warning: Can't read pathname for load map: Input/output error.
Reading symbols from /lib/tls/libc.so.6.1...done.
Loaded symbols for /lib/tls/libc.so.6.1
Reading symbols from /lib/ld-linux-ia64.so.2...done.
Loaded symbols for /lib/ld-linux-ia64.so.2
Failed to read a valid object file image from memory.
Core was generated by `/export/home/hjl/bugs/gdb/gcore-1/gcore'.
Program terminated with signal 5, Trace/breakpoint trap.
#0  terminal_func () at gcore.c:35
35        sleep (60);
Setting up the environment for debugging gdb.
Function "internal_error" not defined.
Make breakpoint pending on future shared library load? (y or [n])
[answered N; input not from terminal]
Function "info_command" not defined.
Make breakpoint pending on future shared library load? (y or [n])
[answered N; input not from terminal]
/export/home/hjl/bugs/gdb/gcore-1/.gdbinit:8: Error in sourced command
file:
No breakpoint number 0.
(gdb) bt
#0  terminal_func () at gcore.c:35
(gdb) 

gdb 6.5-16.el5rh from RHEL5 works fine. I have no problem on
Linux/x86-64.


H.J.


H.J.

Re: DELAYED: GDB 6.7 branch creation scheduled June 25th

[Nick Roberts]

 > Sorry, I'm a bit stuck right now and for the next few days.
 > I will be in New York next week, and will create the branch
 > from there.
 > 
 > I was going to use the 2007-06-17 date where to start the branch,
 > but I might reconsider:
 >   . Extensive gdbarch changes made by Markus and Ulrich
 >     These should be pretty safe, and yet not including them in the
 >     branch might complicate branch patch merging later on
 >   . Daniel's adjustment in configure.ac ($objdir issue)
 > 
 > Also, this would allow us to include recent improvements such as:
 >   . the qOffsets changes
 > 
 > I think there are also a couple of items that Daniel and someone
 > else wanted in...

These facts suggest to me that it's best to delay the branch, possibly by a
month or two, not backdate it.  I guess I'm used to Emacs where the freeze
alone lasted for three years (which _is_ ridiculous) but where does the
pressure come from for such a prompt release?

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: DELAYED: GDB 6.7 branch creation scheduled June 25th

[Joel Brobecker]

> These facts suggest to me that it's best to delay the branch, possibly by a
> month or two, not backdate it.

As far as I am concerned, the fact that we use backdating is unrelated
to where we decide the branchpoint to be. I like backdating, because
it allows me to put the head in maintenance mode for a couple of days
while I work on the branch.

> I guess I'm used to Emacs where the freeze alone lasted for three
> years (which _is_ ridiculous) but where does the pressure come from
> for such a prompt release?

There is no hard pressure; actually, no pressure at all, as far as
I am concerned. But having a rough schedule helps us have structure.
The sense of promptness is relative. I personally like releasing often.
In my sense, GDB has enough material to be released twice a year, others
mentioned that they would like more frequent releases. In any case, if
it turns out that at one point we feel that we haven't done enough when
comes the time to start preparing the next planned release, then for
sure we'll just delay it. But what I do NOT want to do, is to delay the
branch because we're waiting for the next fix, enhancement, etc, unless
there is a compeling reason to.

In this particular case, I think we have more than enough material
to start a new release. Just to verify my impression, I had a look
at the NEWS file, and the "since 6.6" section is actually very long!
And the great thing is that I know more are coming for the release
following that one (which I hope we'll be able to call it GDB 7 :-).

-- 
Joel

Re: DELAYED: GDB 6.7 branch creation scheduled June 25th

[Nick Roberts]

 > > These facts suggest to me that it's best to delay the branch, possibly by a
 > > month or two, not backdate it.
 > 
 > As far as I am concerned, the fact that we use backdating is unrelated
 > to where we decide the branchpoint to be. I like backdating, because
 > it allows me to put the head in maintenance mode for a couple of days
 > while I work on the branch.

You've lost me.  I thought the branchpoint is where the branch was cut.

 >
 >                           But what I do NOT want to do, is to delay the
 > branch because we're waiting for the next fix, enhancement, etc, unless
 > there is a compeling reason to.

The next enhancement can always wait for the next release but if there's a bug
that needs fixing, that needs to be done before the release.  If you're saying
branch and then fix before the release, there doesn't seem much point in
testing until all the fixes are in.  So where's the gain in branching early?

 > In this particular case, I think we have more than enough material
 > to start a new release. Just to verify my impression, I had a look
 > at the NEWS file, and the "since 6.6" section is actually very long!
 > And the great thing is that I know more are coming for the release
 > following that one (which I hope we'll be able to call it GDB 7 :-).

Sure.  I don't think anyone is saying that there haven't been enough changes.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: DELAYED: GDB 6.7 branch creation scheduled June 25th

[Joel Brobecker]

> The next enhancement can always wait for the next release but if
> there's a bug that needs fixing, that needs to be done before the
> release. 

Yes, of course. 

> If you're saying branch and then fix before the release, there doesn't
> seem much point in testing until all the fixes are in.  So where's the
> gain in branching early?

I disagree with the assumption that we are branching "early". We are
branching, because we need to branch to make a release. If the fix
for the bug doesn't make it before the branch is done, then we'll
just port the fix to the branch. If during testing we discover that
there is a significant issue, then we just delay the release.

-- 
Joel

Re: DELAYED: GDB 6.7 branch creation scheduled June 25th

[Nick Roberts]

 > > If you're saying branch and then fix before the release, there doesn't
 > > seem much point in testing until all the fixes are in.  So where's the
 > > gain in branching early?
 > 
 > I disagree with the assumption that we are branching "early". We are
 > branching, because we need to branch to make a release. If the fix
 > for the bug doesn't make it before the branch is done, then we'll
 > just port the fix to the branch. If during testing we discover that
 > there is a significant issue, then we just delay the release.

You've not really answered my question but the prerogative is yours, of
course.  Once the branch is made, I might miss the announcement for the
imminent release, so I would only ask that the bug I have reported:

http://sourceware.org/ml/gdb/2007-06/msg00022.html

is indeed fixed before the release.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: DELAYED: GDB 6.7 branch creation scheduled June 25th

[Joel Brobecker]

> You've not really answered my question but the prerogative is yours, of
> course.

Can you ask your question again? I probably didn't understand what
you were asking.

> Once the branch is made, I might miss the announcement for the
> imminent release, so I would only ask that the bug I have reported:

As of now, the release is scheduled one month after branching.

> http://sourceware.org/ml/gdb/2007-06/msg00022.html
> 
> is indeed fixed before the release.

You have to understand that this can not be guarantied by me.  I could
be underestimating the severity of the problem, but this issue hardly
seems blocking. If you or anyone has a plan for fixing this issue
and promises to propose a patch within a reasonable timeframe (let's
say 2 weeks), then we can consider delaying the release a bit.
Otherwise, I think we should proceed, and just have this particular
issue documented as a known problem.

-- 
Joel

Re: DELAYED: GDB 6.7 branch creation scheduled June 25th

[Nick Roberts]

 > > You've not really answered my question but the prerogative is yours, of
 > > course.
 > 
 > Can you ask your question again? I probably didn't understand what
 > you were asking.

It's just the one that I left in the the message "So where's the gain in
branching early?" but perhaps Stan Shebs answered it.

 > > Once the branch is made, I might miss the announcement for the
 > > imminent release, so I would only ask that the bug I have reported:
 > 
 > As of now, the release is scheduled one month after branching.
 > 
 > > http://sourceware.org/ml/gdb/2007-06/msg00022.html
 > > 
 > > is indeed fixed before the release.
 > 
 > You have to understand that this can not be guarantied by me.

You're the release manager so presumably you can insist on certain things
being done before a release is made.

 >                                                                I could
 > be underestimating the severity of the problem, but this issue hardly
 > seems blocking. 

It breaks existing use of Gdb in Emacs 22.1.

 >                  If you or anyone has a plan for fixing this issue
 > and promises to propose a patch within a reasonable timeframe (let's
 > say 2 weeks), then we can consider delaying the release a bit.

My plan would be just revert the change and I think Jan Kratochvil has agreed
with this.  AFAICS there's no reason why this would delay the release.

 > Otherwise, I think we should proceed, and just have this particular
 > issue documented as a known problem.

It's not just a bug but a regression.  I don't think breaking a feature
and then documenting it as a known problem is really an acceptable policy.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: DELAYED: GDB 6.7 branch creation scheduled June 25th

[Joel Brobecker]

> It's just the one that I left in the the message "So where's the gain in
> branching early?" but perhaps Stan Shebs answered it.

And again, why are you saying that we're branching early? I think
I understand the real question now that you've mentioned the annotation
bug again. Otherwise, the answer would be the same: We're not branching
early, we have lots of exciting stuff that could benefit a lot of users.
We should release that, and I think the sooner the better.

Note that the time of branching is only loosely related to the time
when we make the release. The branch is only a tool that we have to
help us stabilize a code base. So just because we branch next week
doesn't mean that we can't take the time we need to create the actual
release.

> You're the release manager so presumably you can insist on certain things
> being done before a release is made.

What I can do is delay the release. You know however that I cannot force
anyone to do anything, much less within a certain time-frame.

> It breaks existing use of Gdb in Emacs 22.1.

OK, I missed that part. This is indeed more serious than I thought.

> My plan would be just revert the change and I think Jan Kratochvil has
> agreed with this.  AFAICS there's no reason why this would delay the
> release.

Sounds like a promising plan. But you are hammering at the wrong guy.
Keep pinging Jan and the maintainers that can approve the revert,
not me.

> It's not just a bug but a regression.  I don't think breaking a feature
> and then documenting it as a known problem is really an acceptable policy.

It's usually not acceptable, as you know, but sometimes we can
compromise. It depends on the situation and the severity of the
regression.

-- 
Joel

Re: DELAYED: GDB 6.7 branch creation scheduled June 25th

[Nick Roberts]

 > > It's just the one that I left in the the message "So where's the gain in
 > > branching early?" but perhaps Stan Shebs answered it.
 > 
 > And again, why are you saying that we're branching early? I think
 > I understand the real question now that you've mentioned the annotation
 > bug again. 

Perhaps I should have emhasised the words "where's the gain".  That was
my real question.  Please don't be quite so cynical.

 >...
 > > My plan would be just revert the change and I think Jan Kratochvil has
 > > agreed with this.  AFAICS there's no reason why this would delay the
 > > release.
 > 
 > Sounds like a promising plan. But you are hammering at the wrong guy.
 > Keep pinging Jan and the maintainers that can approve the revert,
 > not me.

I'm just drawing it to your attention as release manager and, through this
forum, hopefully to the attention of others.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: DELAYED: GDB 6.7 branch creation scheduled June 25th

[Joel Brobecker]

> Perhaps I should have emhasised the words "where's the gain".  That was
> my real question.  Please don't be quite so cynical.

To which I thought I had answered: Lots of improvements that will
benefit many users. Just the NEWS sections is longer than I remember
it to ever be. I'm sorry if you think that I'm cynical, but I'm not. 

> I'm just drawing it to your attention as release manager and,

Point taken.

In terms of learning from this thread: I interpreted your questions
as vague general questions and I couldn't understand the motivation
behind them. So I answered accordingly. Maybe I was naive, maybe I
misinterpreted. But it doesn't matter. What matters is that you know
how I operate, now.  So if you tell us right from the beginning what
it is that you need, and why, we will answer your request a lot faster.

> through this forum, hopefully to the attention of others.

I'm sorry, but I think you're using the wrong communication channel.
Pinging the relevant parties on gdb-patches should be a lot more
effective.

-- 
Joel

Re: DELAYED: GDB 6.7 branch creation scheduled June 25th

[Nick Roberts]

 > In terms of learning from this thread: I interpreted your questions
 > as vague general questions and I couldn't understand the motivation
 > behind them. So I answered accordingly. Maybe I was naive, maybe I
 > misinterpreted. But it doesn't matter. What matters is that you know
 > how I operate, now.  So if you tell us right from the beginning what
 > it is that you need, and why, we will answer your request a lot faster.

Hopefully they weren't vague, but they were deliberately general because I
thought there were others who wanted similar bugs resolved before the release,
and I tried to suggest a policy for future releases too.  As no one supported
those ideas I moved to my specific issue.

 > > through this forum, hopefully to the attention of others.
 > 
 > I'm sorry, but I think you're using the wrong communication channel.
 > Pinging the relevant parties on gdb-patches should be a lot more
 > effective.

I thought gdb-patches was primarily for the submission of patches and gdb
for more general matters.  It's probably unimportant though, as I guess the
global maintainers read both.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: DELAYED: GDB 6.7 branch creation scheduled June 25th

[Daniel Jacobowitz]

On Sun, Jun 24, 2007 at 12:44:26PM +1200, Nick Roberts wrote:
>  > In terms of learning from this thread: I interpreted your questions
>  > as vague general questions and I couldn't understand the motivation
>  > behind them. So I answered accordingly. Maybe I was naive, maybe I
>  > misinterpreted. But it doesn't matter. What matters is that you know
>  > how I operate, now.  So if you tell us right from the beginning what
>  > it is that you need, and why, we will answer your request a lot faster.
> 
> Hopefully they weren't vague, but they were deliberately general because I
> thought there were others who wanted similar bugs resolved before the release,
> and I tried to suggest a policy for future releases too.  As no one supported
> those ideas I moved to my specific issue.

May I suggest a wiki page?  I didn't get to look at the patch today
but I still hope to tomorrow or else I'll make time during the week.
There's the signed char thing too.

I created:
  http://sourceware.org/gdb/wiki/GDB_6.7_Release

Joel, feel free to update it, consult it, or completely ignore it :-)

-- 
Daniel Jacobowitz
CodeSourcery

Re: DELAYED: GDB 6.7 branch creation scheduled June 25th

[Joel Brobecker]

> I created:
>   http://sourceware.org/gdb/wiki/GDB_6.7_Release
> 
> Joel, feel free to update it, consult it, or completely ignore it :-)

Thanks Daniel, I think this is a great idea; a lot more transparent than
my private hand-written list. I'll start updating it tomorrow to include
all the issues that I think should be resolved before we issue the first
candidate release (I'm a bit behind on gdb-patches, as you might have
noticed with the target_has_all_memory question).

-- 
Joel

Re: DELAYED: GDB 6.7 branch creation scheduled June 25th

[Joel Brobecker]

All,

> May I suggest a wiki page?  I didn't get to look at the patch today
> but I still hope to tomorrow or else I'll make time during the week.
> There's the signed char thing too.
> 
> I created:
>   http://sourceware.org/gdb/wiki/GDB_6.7_Release

I have updated the page to include some issues that we'd like to see
solved before the 6.7 release. Please let me know if you'd like to add
more items to it. There are already several patches that I'd like to
be included in the release so I'm waiting for a couple more days before
branching.

-- 
Joel

Re: DELAYED: GDB 6.7 branch creation scheduled June 25th

[Markus Deuling]

Joel Brobecker wrote:
> All,
> 
>> May I suggest a wiki page?  I didn't get to look at the patch today
>> but I still hope to tomorrow or else I'll make time during the week.
>> There's the signed char thing too.
>>
>> I created:
>>   http://sourceware.org/gdb/wiki/GDB_6.7_Release
> 
> I have updated the page to include some issues that we'd like to see
> solved before the 6.7 release. Please let me know if you'd like to add
> more items to it. There are already several patches that I'd like to
> be included in the release so I'm waiting for a couple more days before
> branching.
> 

I have a patch pending which updates gdbint.texinfo to reflect all the changes to gdbarch.sh et. al. (macro vs. gdbarch-function):
http://sourceware.org/ml/gdb-patches/2007-06/msg00463.html

I'd really like to have it included in 6.7 so that the source maps the manual.

-- 
Markus Deuling
GNU Toolchain for Linux on Cell BE
deuling@de.ibm.com

Re: DELAYED: GDB 6.7 branch creation scheduled June 25th

[Daniel Jacobowitz]

On Sat, Jun 23, 2007 at 12:05:40PM +1200, Nick Roberts wrote:
>  > > If you're saying branch and then fix before the release, there doesn't
>  > > seem much point in testing until all the fixes are in.  So where's the
>  > > gain in branching early?
>  > 
>  > I disagree with the assumption that we are branching "early". We are
>  > branching, because we need to branch to make a release. If the fix
>  > for the bug doesn't make it before the branch is done, then we'll
>  > just port the fix to the branch. If during testing we discover that
>  > there is a significant issue, then we just delay the release.
> 
> You've not really answered my question but the prerogative is yours, of
> course.  Once the branch is made, I might miss the announcement for the
> imminent release, so I would only ask that the bug I have reported:
> 
> http://sourceware.org/ml/gdb/2007-06/msg00022.html
> 
> is indeed fixed before the release.

I will try to look at it today.

-- 
Daniel Jacobowitz
CodeSourcery

Re: DELAYED: GDB 6.7 branch creation scheduled June 25th

[Stan Shebs]

Nick Roberts wrote:
>  > > These facts suggest to me that it's best to delay the branch, possibly by a
>  > > month or two, not backdate it.
>  > 
>  > As far as I am concerned, the fact that we use backdating is unrelated
>  > to where we decide the branchpoint to be. I like backdating, because
>  > it allows me to put the head in maintenance mode for a couple of days
>  > while I work on the branch.
>
> You've lost me.  I thought the branchpoint is where the branch was cut.
>   
It is, but the branchpoint can just as easily be a past revision as the 
current head. There's a lot to be said for branching from the 
best-working version of the past week for instance, rather than from 
whatever randomness is currently at the head of the trunk.

Stan