GDB 5.1.1 scheduled 00:00 24 Jan 2002 GMT

GDB 5.1.1 scheduled 00:00 24 Jan 2002 GMT

[Andrew Cagney]

I'm planning on creating a GDB 5.1.1 from the head of the GDB 5.1 branch 
on or about 24 January 2002 GMT.

The purpose of this release is to mainly address (C) and other problems 
in the documentation.

As a bonus it will pick up a significant number of C++ and other fixes.

It has been proposed that the 5.2 branch occure mid Feb.

Andrew

Re: GDB 5.1.1 scheduled 00:00 24 Jan 2002 GMT

[Daniel Jacobowitz]

On Thu, Jan 17, 2002 at 04:06:57PM -0500, Andrew Cagney wrote:
> I'm planning on creating a GDB 5.1.1 from the head of the GDB 5.1 branch 
> on or about 24 January 2002 GMT.
> 
> The purpose of this release is to mainly address (C) and other problems 
> in the documentation.
> 
> As a bonus it will pick up a significant number of C++ and other fixes.

No, actually, it won't :)  The only fixes it will pick up are the
DW_FORM_strp support, (C) fixes, and the mysterious i387 FP bug fix.

I haven't had time to merge C++ back to the branch and do not intend to
with another release in two months.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: GDB 5.1.1 scheduled 00:00 24 Jan 2002 GMT

[Jason Molenda]

On Thu, Jan 17, 2002 at 04:06:57PM -0500, Andrew Cagney wrote:
> I'm planning on creating a GDB 5.1.1 from the head of the GDB 5.1 branch 
> on or about 24 January 2002 GMT.

It is traditional cvs usage to do all 5.1.* releases off of a single
branch, the gdb-5_1-branch.  Creating a new branch for the 5.1.1
changes gains you little but some juked up cvs branch structure.
If a 5.1.2 release happens, would that be based off of the 5.1
branch, or another branch branched off the tip of 5.1.1?  What if
a 5.1.1a had to be made to correct something small?  If a 5.1.1.1a
branch happens and a 5.1.2 has to happen, does that mean the 5.1.2
is branched off the tip of 5.1.1a branch or 5.1.1?

I know the gdb releases won't be so complicated, but why start a
precedent like this?  Instead, a single branch, gdb-5_1-branch,
can be used for all of these.  You tag the releases, so when 5.1
is released you put a tag like gdb-5_1-release on it.  You continue
to check in small patches to gdb-5_1-branch.  When 5.1.1 is ready,
you add another tag, gdb-5_1_1-release.  5.1.1a?  More checkins on
the 5.1 branch, another -release tag.  Same thing for 5.1.2.

Incidentally, this also touches on a style nit of mine that I've
talked to Andrew about in the past in direct mail, but I'm strongly
opposed to encoding dates in the branch names.  The thinking behind
gdb-5_1-20010914-branch (or whatever it was) is that you can guess
when the sources were branched off the trunk.  If that's an important
piece of information, encode it in the branchpoint tag
(gdb-5_1-2001-09-14-branchpoint) which people rarely have to type
on their own, and call the branch something sensible like
gdb-5_1-branch.  By encoding the date in the branch tag, which
people have to use often, you make them remember arbitrary information
which doesn't disambiguate anything.  I can check out a copy of
the gcc 3.0 branch without looking at a single web page, without
checking a single tag list -- any reasonable person can guess what
it will look like.  No reasonable person can guess what the gdb
5.1 branch name might be.  You could just as easily include a few
bytes of /dev/random in there for all it does.

I apologize if I come off sounding overly indignant about this,
but it's really annoying and I shake my head in disappointment each
time see this practice becoming codified or think about it being
emulated in future branches.

Jason

Re: GDB 5.1.1 scheduled 00:00 24 Jan 2002 GMT

[Andrew Cagney]

> On Thu, Jan 17, 2002 at 04:06:57PM -0500, Andrew Cagney wrote:
> 
>> I'm planning on creating a GDB 5.1.1 from the head of the GDB 5.1 branch 
>> on or about 24 January 2002 GMT.
> 
> 
> It is traditional cvs usage to do all 5.1.* releases off of a single
> branch, the gdb-5_1-branch.  Creating a new branch for the 5.1.1
> changes gains you little but some juked up cvs branch structure.
> If a 5.1.2 release happens, would that be based off of the 5.1
> branch, or another branch branched off the tip of 5.1.1?  What if
> a 5.1.1a had to be made to correct something small?  If a 5.1.1.1a
> branch happens and a 5.1.2 has to happen, does that mean the 5.1.2
> is branched off the tip of 5.1.1a branch or 5.1.1?


Er, I think you miss understand what is going on here.  GDB 5.1.1 will 
be taken from the head of the 5.1 branch.  This process was discussed 
and agreed to long long ago.

Andrew

Re: GDB 5.1.1 scheduled 00:00 24 Jan 2002 GMT

[Eli Zaretskii]

> Date: Thu, 17 Jan 2002 13:18:15 -0800
> From: Jason Molenda <jason-swarelist@molenda.com>
> 
> By encoding the date in the branch tag, which
> people have to use often, you make them remember arbitrary information
> which doesn't disambiguate anything.  I can check out a copy of
> the gcc 3.0 branch without looking at a single web page, without
> checking a single tag list -- any reasonable person can guess what
> it will look like.  No reasonable person can guess what the gdb
> 5.1 branch name might be.

You mean, you don't have a small shell script for CVS command on the
branch (created when Andrew first announces the tag)? ;-)

Re: GDB 5.1.1 scheduled 00:00 24 Jan 2002 GMT

[Andrew Cagney]

> I'm planning on creating a GDB 5.1.1 from the head of the GDB 5.1 branch on or about 24 January 2002 GMT.
> 
> The purpose of this release is to mainly address (C) and other problems in the documentation.
> 
> As a bonus it will pick up a significant number of C++ and other fixes.


^D^D^D It will pick up a few C++ and other fixes.


> It has been proposed that the 5.2 branch occure mid Feb.


FYI,

Andrew

Re: GDB 5.1.1 scheduled 00:00 24 Jan 2002 GMT

[Andrew Cagney]

> Incidentally, this also touches on a style nit of mine that I've
> talked to Andrew about in the past in direct mail, but I'm strongly
> opposed to encoding dates in the branch names.  The thinking behind
> gdb-5_1-20010914-branch (or whatever it was) is that you can guess
> when the sources were branched off the trunk.  If that's an important
> piece of information, encode it in the branchpoint tag
> (gdb-5_1-2001-09-14-branchpoint) which people rarely have to type
> on their own, and call the branch something sensible like
> gdb-5_1-branch.  By encoding the date in the branch tag, which
> people have to use often, you make them remember arbitrary information
> which doesn't disambiguate anything.  I can check out a copy of
> the gcc 3.0 branch without looking at a single web page, without
> checking a single tag list -- any reasonable person can guess what
> it will look like.  No reasonable person can guess what the gdb
> 5.1 branch name might be.  You could just as easily include a few
> bytes of /dev/random in there for all it does.


BTW, the how-to-release doco hints at this.  Would you like me to expand 
a little including the above?

BTW, other side is that the tag includes the date so it is easy to find 
exactly when that tag was created (something CVS is really bad at).

enjoy,
Andrew