Stopping daily bump of version.c on old/closed branches

Stopping daily bump of version.c on old/closed branches

[Gabriel Dos Reis]

Hi,

  As I announced earlier, the branch gcc-3_2-branch will be closed
after GCC-3.2.3 is realesed.  By that I really mean that we don't have
anything like GCC-3.2.4 floating around.  My inclination is to have
the conjob that currently bumps gcc/version.c not touch gcc-3_2-branch.

It appears that (thanks, Gerald) old branches are still being updated.
It might be desirable that we extend non-bumping to those branches as
well. 

Gerald suggested I bring the issue here before taking any explicit
action -- stopping version bump on gcc-3_2-branch and, if agreed, also
on old branches.  So here I am.  

Opinions?

-- Gaby

Re: Stopping daily bump of version.c on old/closed branches

[Daniel Berlin]

On Wednesday, April 23, 2003, at 02:41  AM, Gabriel Dos Reis wrote:

>
> Hi,
>
>   As I announced earlier, the branch gcc-3_2-branch will be closed
> after GCC-3.2.3 is realesed.  By that I really mean that we don't have
> anything like GCC-3.2.4 floating around.  My inclination is to have
> the conjob that currently bumps gcc/version.c not touch gcc-3_2-branch.
>
What is this script written in?
For that matter, what are most of these scripts written in?
If it's perl, we really should just keep a simple (tab or comma) 
delimited flat file (or mysql, though i think that's overkill) database.
that has the current branches, and a description of each, and have 
these scripts pull from it.
You could also make the web page pull the descriptions from the db, 
too, be it on the fly or once a day.
It seems every time someone adds or obsoletes a branch,  there are
50 places that need to be updated, rather than 1.
If these scripts are in perl or python, i'll happily volunteer to make 
them do this.
My awk/sed/sh foo just ain't good enough, however, and i'm actually 
proud of that.
:)
If it's a simple ascii file database of some sort, we could keep it in 
the repo and regen the web page on commit.


> It appears that (thanks, Gerald) old branches are still being updated.
> It might be desirable that we extend non-bumping to those branches as
> well.
>
> Gerald suggested I bring the issue here before taking any explicit
> action -- stopping version bump on gcc-3_2-branch and, if agreed, also
> on old branches.  So here I am.
>
> Opinions?
>
> -- Gaby

Re: Stopping daily bump of version.c on old/closed branches

[Phil Edwards]

On Wed, Apr 23, 2003 at 03:21:39AM -0400, Daniel Berlin wrote:
> 
> On Wednesday, April 23, 2003, at 02:41  AM, Gabriel Dos Reis wrote:
> 
> >
> >Hi,
> >
> >  As I announced earlier, the branch gcc-3_2-branch will be closed
> >after GCC-3.2.3 is realesed.  By that I really mean that we don't have
> >anything like GCC-3.2.4 floating around.  My inclination is to have
> >the conjob that currently bumps gcc/version.c not touch gcc-3_2-branch.
> >
> What is this script written in?

top level, maintainer-scripts/update_version

It's just sh, most of them are.  I wouldn't want to see them rewritten
in perl, to be honest.  And most of them that do use sh are pretty
straightforward.


Phil

-- 
If ye love wealth greater than liberty, the tranquility of servitude greater
than the animating contest for freedom, go home and leave us in peace.  We seek
not your counsel, nor your arms.  Crouch down and lick the hand that feeds you;
and may posterity forget that ye were our countrymen.            - Samuel Adams

Re: Stopping daily bump of version.c on old/closed branches

[Gabriel Dos Reis]

Phil Edwards <phil@jaj.com> writes:

| It's just sh, most of them are.  I wouldn't want to see them rewritten
| in perl, to be honest.  And most of them that do use sh are pretty
| straightforward.

The primary goal of my original message isn't about rewriting anything in
whatever language.  I'm just asking for opinions about not bumping
gcc/version.c on old and/or closed branches.

Rewriting is a separate issue and I'm not sure it was really proposed.

-- Gaby

Re: Stopping daily bump of version.c on old/closed branches

[Daniel Berlin]

On Wednesday, April 23, 2003, at 03:26  AM, Phil Edwards wrote:

> On Wed, Apr 23, 2003 at 03:21:39AM -0400, Daniel Berlin wrote:
>>
>> On Wednesday, April 23, 2003, at 02:41  AM, Gabriel Dos Reis wrote:
>>
>>>
>>> Hi,
>>>
>>>  As I announced earlier, the branch gcc-3_2-branch will be closed
>>> after GCC-3.2.3 is realesed.  By that I really mean that we don't 
>>> have
>>> anything like GCC-3.2.4 floating around.  My inclination is to have
>>> the conjob that currently bumps gcc/version.c not touch 
>>> gcc-3_2-branch.
>>>
>> What is this script written in?
>
> top level, maintainer-scripts/update_version
>
> It's just sh, most of them are.  I wouldn't want to see them rewritten
> in perl, to be honest.  And most of them that do use sh are pretty
> straightforward.

I wasn't proposing rewriting, it's just i didn't want to tamper with 
scripts written in a language
i'm not familiar with the nuances of.
So I asked what they were written in, since I didn't want to make a 
suggestion
without being able to at least conditionally volunteer to implement it.
:)

In this case, it looks like we would be changing
  BRANCHES=`$CVS status -v gcc/ChangeLog \
               | awk '{print $1;}' \
               | egrep 'gcc-[0-9]+_[0-9]+-branch$'`

to something like
  BRANCHES=`cat gcc/active-branches` \
               | awk '{print $1;}'

(or whatever)
if we were to use a list of active branches.

--Dan

Re: Stopping daily bump of version.c on old/closed branches

[Joseph S. Myers]

On Wed, 23 Apr 2003, Daniel Berlin wrote:

> In this case, it looks like we would be changing
>   BRANCHES=`$CVS status -v gcc/ChangeLog \
>                | awk '{print $1;}' \
>                | egrep 'gcc-[0-9]+_[0-9]+-branch$'`
> 
> to something like
>   BRANCHES=`cat gcc/active-branches` \
>                | awk '{print $1;}'
> 
> (or whatever)
> if we were to use a list of active branches.

Extracting the branches from CVS rather than maintaining a list manually
in the crontab was considered an improvement as it reduced the number of
steps required in the branch creation process
<http://gcc.gnu.org/ml/gcc/2002-02/msg01588.html>.  So, if you want to
maintain a list of active branches (maintainer-scripts/active-branches -
maintainer-scripts being checked out in ~gccadmin/scripts, albeit that at
present cvs update needs to be run there manually after changes and the
new crontab installed manually after changes), create a gcc_branch script
to handle most of the branch creation process (including updating
active-branches).  (Closing a branch would be a much simpler process, just
removing the line from active-branches and updating the home page list of
branch status.)

(Of course a gcc_branch script would need testing - an rsynced repository
copy is probably the simplest way of doing that testing.)

Various bits of releasing.html could also be automated that aren't at
present (whether in gcc_release or in a separate script).

-- 
Joseph S. Myers
jsm28@cam.ac.uk

Re: Stopping daily bump of version.c on old/closed branches

[Daniel Jacobowitz]

On Wed, Apr 23, 2003 at 04:08:38AM -0400, Daniel Berlin wrote:
> 
> On Wednesday, April 23, 2003, at 03:26  AM, Phil Edwards wrote:
> 
> >On Wed, Apr 23, 2003 at 03:21:39AM -0400, Daniel Berlin wrote:
> >>
> >>On Wednesday, April 23, 2003, at 02:41  AM, Gabriel Dos Reis wrote:
> >>
> >>>
> >>>Hi,
> >>>
> >>> As I announced earlier, the branch gcc-3_2-branch will be closed
> >>>after GCC-3.2.3 is realesed.  By that I really mean that we don't 
> >>>have
> >>>anything like GCC-3.2.4 floating around.  My inclination is to have
> >>>the conjob that currently bumps gcc/version.c not touch 
> >>>gcc-3_2-branch.
> >>>
> >>What is this script written in?
> >
> >top level, maintainer-scripts/update_version
> >
> >It's just sh, most of them are.  I wouldn't want to see them rewritten
> >in perl, to be honest.  And most of them that do use sh are pretty
> >straightforward.
> 
> I wasn't proposing rewriting, it's just i didn't want to tamper with 
> scripts written in a language
> i'm not familiar with the nuances of.
> So I asked what they were written in, since I didn't want to make a 
> suggestion
> without being able to at least conditionally volunteer to implement it.
> :)
> 
> In this case, it looks like we would be changing
>  BRANCHES=`$CVS status -v gcc/ChangeLog \
>               | awk '{print $1;}' \
>               | egrep 'gcc-[0-9]+_[0-9]+-branch$'`
> 
> to something like
>  BRANCHES=`cat gcc/active-branches` \
>               | awk '{print $1;}'
> 
> (or whatever)
> if we were to use a list of active branches.

Can I suggest a list of inactive branches instead?  It's not as
natural, but it seems that by default we always want the version bumped
until the branch is explicitly retired; this could be part of retiring
it.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: Stopping daily bump of version.c on old/closed branches

[Gabriel Dos Reis]

Daniel Jacobowitz <drow@mvista.com> writes:

[...]

| Can I suggest a list of inactive branches instead?  It's not as
| natural, but it seems that by default we always want the version bumped
| until the branch is explicitly retired; this could be part of retiring
| it.

This is an interesting proposal.  

May I suggest that we bump versions for all active branches, not just
those the tags of which happen to match 'gcc-[0-9]+_[0-9]+-branch$'?

-- Gaby

Re: Stopping daily bump of version.c on old/closed branches

[Gabriel Dos Reis]

Daniel Berlin <dberlin@dberlin.org> writes:

| On Wednesday, April 23, 2003, at 02:41  AM, Gabriel Dos Reis wrote:
| 
| >
| > Hi,
| >
| >   As I announced earlier, the branch gcc-3_2-branch will be closed
| > after GCC-3.2.3 is realesed.  By that I really mean that we don't have
| > anything like GCC-3.2.4 floating around.  My inclination is to have
| > the conjob that currently bumps gcc/version.c not touch gcc-3_2-branch.
| >
| What is this script written in?

sh.

| For that matter, what are most of these scripts written in?
| If it's perl, we really should just keep a simple (tab or comma)
| delimited flat file (or mysql, though i think that's overkill)
| database.
| that has the current branches, and a description of each, and have
| these scripts pull from it.
| You could also make the web page pull the descriptions from the db,
| too, be it on the fly or once a day.
| It seems every time someone adds or obsoletes a branch,  there are
| 50 places that need to be updated, rather than 1.

strongly agreed with your suggestion.

| If these scripts are in perl or python, i'll happily volunteer to make
| them do this.
| My awk/sed/sh foo just ain't good enough, however, and i'm actually
| proud of that.
| :)

:-)  
Thanks for the prompt answer.

After I raised the issue with Gerald, he was kind enough to do my
homework and pointed out that the actual script is taken from:

    egcs/maintainer-scripts/update_version

The bits that are of interest are:

    # Compute the branches which we should update.
    $CVS co gcc/ChangeLog
    BRANCHES=`$CVS status -v gcc/ChangeLog \
              | awk '{print $1;}' \
              | egrep 'gcc-[0-9]+_[0-9]+-branch$'`
    # Always update the mainline.
    BRANCHES="${BRANCHES} HEAD"

Indeed we could just use a plain ascii file as db for active branches names.


My first question would be:  Do people think that we should stop
updating gcc/version.c on old or obsoleted branches?

-- Gaby

Re: Stopping daily bump of version.c on old/closed branches

[Gerald Pfeifer]

On Wed, 23 Apr 2003, Gabriel Dos Reis wrote:
> My first question would be:  Do people think that we should stop
> updating gcc/version.c on old or obsoleted branches?

Somehow this proposal lead to a bikeshed, and in general Gaby's suggestion
only got positive responses, so after waiting one week I implemented the
most conservative of all proposals in the most low-tech way per the patch
below.

Tested on gcc.gnu.org and installed on mainline.

Gerald

2003-05-02  Gerald Pfeifer  <gerald@pfeifer@dbai.tuwien.ac.at>

	* update_version (IGNORE_BRANCHES): Add.
	(BRANCHES): Do not consider branches matching $IGNORE_BRANCHES.

Index: update_version
===================================================================
RCS file: /cvs/gcc/gcc/maintainer-scripts/update_version,v
retrieving revision 1.9
diff -u -3 -p -r1.9 update_version
--- update_version	2 May 2003 09:13:52 -0000	1.9
+++ update_version	2 May 2003 09:35:48 -0000
@@ -1,7 +1,9 @@
 #!/bin/sh

-# Run this from /tmp.
 CVSROOT=${CVSROOT:-/cvs/gcc}
+IGNORE_BRANCHES='gcc-(2_95|3_0|3_1|3_2)-branch'
+
+# Run this from /tmp.
 export CVSROOT
 /bin/rm -rf /tmp/$$
 /bin/mkdir /tmp/$$
@@ -14,7 +16,8 @@ CVS=${CVS:-/usr/local/bin/cvs}
 $CVS co gcc/ChangeLog
 BRANCHES=`$CVS status -v gcc/ChangeLog \
           | awk '{print $1;}' \
-          | egrep 'gcc-[0-9]+_[0-9]+-branch$'`
+          | egrep 'gcc-[0-9]+_[0-9]+-branch$' \
+          | egrep -v $IGNORE_BRANCHES`
 # Always update the mainline.
 BRANCHES="${BRANCHES} HEAD"

Re: Stopping daily bump of version.c on old/closed branches

[Gabriel Dos Reis]

Gerald Pfeifer <pfeifer@dbai.tuwien.ac.at> writes:

| On Wed, 23 Apr 2003, Gabriel Dos Reis wrote:
| > My first question would be:  Do people think that we should stop
| > updating gcc/version.c on old or obsoleted branches?
| 
| Somehow this proposal lead to a bikeshed, and in general Gaby's suggestion
| only got positive responses, so after waiting one week I implemented the
| most conservative of all proposals in the most low-tech way per the patch
| below.

Thank you very much for taking care of this.

-- Gaby