GCC 3.3 Branch Open

GCC 3.3 Branch Open

[Mark Mitchell]

The GCC 3.3 branch is now open for regression-only changes again.

(Committing things there may not lead to much; I'm not presently
planning on a 3.3.3 release -- but if 3.4 drags out a long time, that
might make sense.)

Thanks,

-- 
Mark Mitchell <mark@codesourcery.com>
CodeSourcery, LLC

Re: GCC 3.3 Branch Open

[Eric Botcazou]

> The GCC 3.3 branch is now open for regression-only changes again.

Don't you need to bump the version number on the branch?

-- 
Eric Botcazou

Re: GCC 3.3 Branch Open

[Mark Mitchell]

[-- Attachment #1: Type: text/plain, Size: 260 bytes --]

On Sat, 2003-10-18 at 05:31, Eric Botcazou wrote:
> > The GCC 3.3 branch is now open for regression-only changes again.
> 
> Don't you need to bump the version number on the branch?

Yes, thank you.

-- 
Mark Mitchell <mark@codesourcery.com>
CodeSourcery, LLC

[-- Attachment #2: diffs --]
[-- Type: text/plain, Size: 2810 bytes --]

2003-10-19  Mark Mitchell  <mark@codesourcery.com>

	* doc/include/gcc-common.texi: Bump version number.
	* version.c (version_string): Reset to prerelease format.

Index: version.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/version.c,v
retrieving revision 1.1810.2.315
diff -c -5 -p -r1.1810.2.315 version.c
*** version.c	16 Oct 2003 19:45:43 -0000	1.1810.2.315
--- version.c	19 Oct 2003 23:15:30 -0000
***************
*** 4,14 ****
  /* This is the string reported as the version number by all components
     of the compiler.  If you distribute a modified version of GCC,
     please modify this string to indicate that, e.g. by putting your
     organization's name in parentheses at the end of the string.  */
  
! const char version_string[] = "3.3.2";
  
  /* This is the location of the online document giving instructions for
     reporting bugs.  If you distribute a modified version of GCC,
     please change this to refer to a document giving instructions for
     reporting bugs to you, not us.  (You are of course welcome to
--- 4,14 ----
  /* This is the string reported as the version number by all components
     of the compiler.  If you distribute a modified version of GCC,
     please modify this string to indicate that, e.g. by putting your
     organization's name in parentheses at the end of the string.  */
  
! const char version_string[] = "3.3.3 20031019 (prerelease)";
  
  /* This is the location of the online document giving instructions for
     reporting bugs.  If you distribute a modified version of GCC,
     please change this to refer to a document giving instructions for
     reporting bugs to you, not us.  (You are of course welcome to
Index: doc/include/gcc-common.texi
===================================================================
RCS file: /cvs/gcc/gcc/gcc/doc/include/gcc-common.texi,v
retrieving revision 1.3.14.3
diff -c -5 -p -r1.3.14.3 gcc-common.texi
*** doc/include/gcc-common.texi	7 Aug 2003 20:12:35 -0000	1.3.14.3
--- doc/include/gcc-common.texi	19 Oct 2003 23:15:30 -0000
***************
*** 2,12 ****
  @c This is part of the GCC manual.
  @c For copying conditions, see the file gcc.texi.
  
  @c Common values used in the GCC manuals:
  
! @set version-GCC 3.3.2
  
  @c DEVELOPMENT is set to indicate an in-development version,
  @c as compared to a release version.  When making a release
  @c branch, clear this.
  @clear DEVELOPMENT
--- 2,12 ----
  @c This is part of the GCC manual.
  @c For copying conditions, see the file gcc.texi.
  
  @c Common values used in the GCC manuals:
  
! @set version-GCC 3.3.3
  
  @c DEVELOPMENT is set to indicate an in-development version,
  @c as compared to a release version.  When making a release
  @c branch, clear this.
  @clear DEVELOPMENT

GCC 3.3 branch open

[Mark Mitchell]

The 3.3 branch is now open, under the usual regression-only check-in
rules.

--
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com

Re: GCC 3.3 branch open

[Kelley Cook]

Mark Mitchell wrote:

> The 3.3 branch is now open, under the usual regression-only check-in
> rules.

Is this really the usual checkin rules for a branch?

For example after 3.1 was released you said:

> 1. Anyone who can normally approve patches can approve patches that
>    fix regressions from previously released versions of GCC.
> 
> 2. I will review and approve patches that do not fix regressions if
> 
>    a) they appear safe
>    b) they fix very important problems, or
>    c) they add support for new platforms, language features, etc.
>       that we did not support before -- and that we cannot, therefore,
>       be regressing.
> 
>    Please make your case explicitly; assume I know very little (a
>    good assumption!) and explain why your patch fits these criteria.

-- http://gcc.gnu.org/ml/gcc/2002-05/msg01212.html

I thought regression-only was only the requirement when the next release 
was close.  I personally would think that important bug fixes should not 
necessarily have to wait for 3.4, even if that bug has been always 
present in GCC.

You, of course, are the release manager, so it is your call to make.

Kelley Cook

Re: GCC 3.3 branch open

[Mark Mitchell]

Kelley --

The rules have always been that fixes on the release branch and for
regressions only.

I do make exceptions, where warranted, and I will continue to do that.

However, the threshold is pretty high.  Largely, the point of the bug-fix
releases is to remove obstacles that are preventing people from upgrading to
the current release series.  A bug that has always existed does not
constitute such an obstacle.

-- Mark

----- Original Message ----- 
From: "Kelley Cook" <kcook34@ford.com>
To: "Mark Mitchell" <mark@codesourcery.com>
Cc: <gcc@gcc.gnu.org>
Sent: Friday, August 08, 2003 12:00 PM
Subject: Re: GCC 3.3 branch open


> Mark Mitchell wrote:
>
> > The 3.3 branch is now open, under the usual regression-only check-in
> > rules.
>
> Is this really the usual checkin rules for a branch?
>
> For example after 3.1 was released you said:
>
> > 1. Anyone who can normally approve patches can approve patches that
> >    fix regressions from previously released versions of GCC.
> >
> > 2. I will review and approve patches that do not fix regressions if
> >
> >    a) they appear safe
> >    b) they fix very important problems, or
> >    c) they add support for new platforms, language features, etc.
> >       that we did not support before -- and that we cannot, therefore,
> >       be regressing.
> >
> >    Please make your case explicitly; assume I know very little (a
> >    good assumption!) and explain why your patch fits these criteria.
>
> -- http://gcc.gnu.org/ml/gcc/2002-05/msg01212.html
>
> I thought regression-only was only the requirement when the next release
> was close.  I personally would think that important bug fixes should not
> necessarily have to wait for 3.4, even if that bug has been always
> present in GCC.
>
> You, of course, are the release manager, so it is your call to make.
>
> Kelley Cook
>
>
>

GCC 3.3 Branch Open

[Mark Mitchell]

The GCC 3.3 branch is now open for regression-fixes only, under the
usual release branch rules.

Also, how do I find bugzilla?  The release checklist has some bugzilla
activity for me, but I'm not sure what URL to use.  (The best thing
would be if someone would insert a link in the release notes; otherwise,
please send me the URL and I will take care of it.)

On that note, we may as well switch from GNATS to bugzilla now, if
bugzilla is ready to go.

Thanks!

-- 
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com

Re: GCC 3.3 Branch Open

[Daniel Berlin]

On Wednesday, May 14, 2003, at 07:48  PM, Mark Mitchell wrote:

> The GCC 3.3 branch is now open for regression-fixes only, under the
> usual release branch rules.
>
> Also, how do I find bugzilla?  The release checklist has some bugzilla
> activity for me, but I'm not sure what URL to use.  (The best thing
> would be if someone would insert a link in the release notes; 
> otherwise,
> please send me the URL and I will take care of it.)

http://gcc.gnu.org/bugzilla

There is nothing for you to do yet in Bugzilla, since any changes you 
made to the DB would be wiped out during final conversion anyway.
:)

>
> On that note, we may as well switch from GNATS to bugzilla now, if
> bugzilla is ready to go.

It is, actually, but it requires a bit of coordination among people.  
So i'll send out a seperate message about it.

>
> Thanks!
>
> -- 
> Mark Mitchell
> CodeSourcery, LLC
> mark@codesourcery.com
>

Re: GCC 3.3 Branch Open

[Joseph S. Myers]

On Wed, 14 May 2003, Daniel Berlin wrote:

> http://gcc.gnu.org/bugzilla
> 
> There is nothing for you to do yet in Bugzilla, since any changes you 
> made to the DB would be wiped out during final conversion anyway.
> :)

What's with the various different converter scripts (bug_email.pl,
gnatsparse.py), both of which have lists of version numbers is, only one
of which is mentioned in the releasing/branching notes and so knows of 
3.3.1 (and neither of which knows of 3.2.3)?

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

Re: GCC 3.3 Branch Open

[Daniel Berlin]

On Thursday, May 15, 2003, at 06:18  AM, Joseph S. Myers wrote:

> On Wed, 14 May 2003, Daniel Berlin wrote:
>
>> http://gcc.gnu.org/bugzilla
>>
>> There is nothing for you to do yet in Bugzilla, since any changes you
>> made to the DB would be wiped out during final conversion anyway.
>> :)
>
> What's with the various different converter scripts (bug_email.pl,
> gnatsparse.py),

gnatsparse is for converting gnats to bugzilla.
bug_email.pl is an inbound email handler that converts gccbug reports 
to bugzilla ones.
I've already updated both for 3.3.1.

the converter was rewritten by me in python so it would be 
understandable, and submittable to bugzilla's main sources.
It will be in the bugzilla distribution soon.



>  both of which have lists of version numbers is, only one
> of which is mentioned in the releasing/branching notes and so knows of
> 3.3.1 (and neither of which knows of 3.2.3)?
>
Why would one list a one-time db converter tool in the release notes?
Once the db conversion is done, there is no need to *ever* run 
gnatsparse again.

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

Re: GCC 3.3 Branch Open

[Daniel Berlin]

On Thursday, May 15, 2003, at 10:03  AM, Daniel Berlin wrote:

>
> On Thursday, May 15, 2003, at 06:18  AM, Joseph S. Myers wrote:
>
>> On Wed, 14 May 2003, Daniel Berlin wrote:
>>
>>> http://gcc.gnu.org/bugzilla
>>>
>>> There is nothing for you to do yet in Bugzilla, since any changes you
>>> made to the DB would be wiped out during final conversion anyway.
>>> :)
>>
>> What's with the various different converter scripts (bug_email.pl,
>> gnatsparse.py),
>
> gnatsparse is for converting gnats to bugzilla.
> bug_email.pl is an inbound email handler that converts gccbug reports 
> to bugzilla ones.
> I've already updated both for 3.3.1.

actually, Mark beat me to updating bug_email.pl
:)

----------------------------
revision 1.7
date: 2003/05/14 23:38:33;  author: mmitchel;  state: Exp;  lines: +4 -1
Update for 3.3.1

Re: GCC 3.3 Branch Open

[Gerald Pfeifer]

On Wed, 14 May 2003, Daniel Berlin wrote:
>> Also, how do I find bugzilla?  The release checklist has some bugzilla
>> activity for me, but I'm not sure what URL to use.  (The best thing
>> would be if someone would insert a link in the release notes;
>> otherwise, please send me the URL and I will take care of it.)
> There is nothing for you to do yet in Bugzilla, since any changes you
> made to the DB would be wiped out during final conversion anyway.
> :)

Just to make sure, Daniel: You are going to take care of items 14-17
documented in http://gcc.gnu.org/releasing.html ?

(How will this be handled for future releases, after we switched to
bugzilla?)

Gerald
-- 
Gerald "Jerry"   pfeifer@dbai.tuwien.ac.at   http://www.pfeifer.com/gerald/

Re: GCC 3.3 Branch Open

[Daniel Berlin]

On Thursday, May 15, 2003, at 08:41  AM, Gerald Pfeifer wrote:

> On Wed, 14 May 2003, Daniel Berlin wrote:
>>> Also, how do I find bugzilla?  The release checklist has some 
>>> bugzilla
>>> activity for me, but I'm not sure what URL to use.  (The best thing
>>> would be if someone would insert a link in the release notes;
>>> otherwise, please send me the URL and I will take care of it.)
>> There is nothing for you to do yet in Bugzilla, since any changes you
>> made to the DB would be wiped out during final conversion anyway.
>> :)
>
> Just to make sure, Daniel: You are going to take care of items 14-17
> documented in http://gcc.gnu.org/releasing.html ?
>
Yes
> (How will this be handled for future releases, after we switched to
> bugzilla?)
>

The only reason *i'm* taking care of them is because the final db 
conversion hasn't been done yet, so the process is slightly different 
(I have to update the one-time db conversion tools *and* the email 
handler. Also, if you retarget the bugs in Bugzilla, it'll be wiped out 
when the final db conversion happens in the next few days).

After we've switched, only the email handler needs to be updated, as 
the directions specify.
Mark could update the email handler if he felt like it, but since i'll 
be updating the one-time db conversion code in the same directory 
anyway, it doesn't seem to make sense to have him do it.
--Dan
> Gerald
> -- 
> Gerald "Jerry"   pfeifer@dbai.tuwien.ac.at   
> http://www.pfeifer.com/gerald/