GCC Release Status (2003-08-03)

GCC Release Status (2003-08-03)

[Mark Mitchell]

GCC 3.3.1
=========

I was notified that the FSF had released its hold on GCC 3.3.1
yesterday.

I've applied the last patches to GCC 3.3.1, and the release will be
out within a few days.  The FSF's machines have been cracked again, so
they are going through the process of recreating accounts.

The 3.3.1 target should be removed from bugzilla, but I do not know
how to do this.

GCC 3.3.2
=========

I've tentatively scheduled GCC 3.3.2 for October 1, 2003.

There are 93 regressions targeted for GCC 3.3.2.  

GCC 3.4
=======

GCC 3.4 is in Stage 2.

There are 297 regressions targeted for GCC 3.4 (down from 306 last
week).  Of those, 94 (down from 109) are C++ PRs.

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

Re: GCC Release Status (2003-08-03)

[Steven Bosscher]

Hi Mark,

Op zo 03-08-2003, om 18:12 schreef Mark Mitchell:
> GCC 3.3.1
> =========
> 
> I was notified that the FSF had released its hold on GCC 3.3.1
> yesterday.
> 
> I've applied the last patches to GCC 3.3.1, and the release will be
> out within a few days.

Do you think there still is time to fix bug 11713
(http://gcc.gnu.org/PR11713) which is a C++ regression from 3.3.0
(according to phil's reghunter).  I have already identified a patch
(yours) that seems to introduce the bug.

Gr.
Steven

Re: GCC Release Status (2003-08-03)

[Daniel Berlin]

On Sunday, August 3, 2003, at 12:12 PM, Mark Mitchell wrote:

>
> GCC 3.3.1
> =========
>
> I was notified that the FSF had released its hold on GCC 3.3.1
> yesterday.
>
> I've applied the last patches to GCC 3.3.1, and the release will be
> out within a few days.  The FSF's machines have been cracked again, so
> they are going through the process of recreating accounts.
>
> The 3.3.1 target should be removed from bugzilla, but I do not know
> how to do this.

Mass change all the 3.3.1 targets to 3.3.2
Then edit the products, choose gcc, choose edit target milestones, and 
delete 3.3.1
>
> GCC 3.3.2
> =========
>
> I've tentatively scheduled GCC 3.3.2 for October 1, 2003.
>
> There are 93 regressions targeted for GCC 3.3.2.
>
> GCC 3.4
> =======
>
> GCC 3.4 is in Stage 2.
>
> There are 297 regressions targeted for GCC 3.4 (down from 306 last
> week).  Of those, 94 (down from 109) are C++ PRs.
>
> --
> Mark Mitchell
> CodeSourcery, LLC
> mark@codesourcery.com
>

Re: GCC Release Status (2003-08-03)

[Joe Buck]

On Sun, Aug 03, 2003 at 05:28:05PM -0400, Daniel Berlin wrote:
> 
> On Sunday, August 3, 2003, at 12:12 PM, Mark Mitchell wrote:
> 
> >
> > GCC 3.3.1
> > =========
> >
> > I was notified that the FSF had released its hold on GCC 3.3.1
> > yesterday.
> >
> > I've applied the last patches to GCC 3.3.1, and the release will be
> > out within a few days.  The FSF's machines have been cracked again, so
> > they are going through the process of recreating accounts.
> >
> > The 3.3.1 target should be removed from bugzilla, but I do not know
> > how to do this.

> Mass change all the 3.3.1 targets to 3.3.2
> Then edit the products, choose gcc, choose edit target milestones, and 
> delete 3.3.1

Wait just a minute!  You're about to screw up my life.

How, when I am preparing the release notes for 3.3.2, am I to distinguish
bugs that are fixed in 3.3.1 from those fixed in 3.3.2 if you change all
occurrences of "3.3.1" to "3.3.2" even in bugs that are already marked
as fixed?

Re: GCC Release Status (2003-08-03)

[Daniel Berlin]

On Mon, 4 Aug 2003, Joe Buck wrote:

> On Sun, Aug 03, 2003 at 05:28:05PM -0400, Daniel Berlin wrote:
> >
> > On Sunday, August 3, 2003, at 12:12 PM, Mark Mitchell wrote:
> >
> > >
> > > GCC 3.3.1
> > > =========
> > >
> > > I was notified that the FSF had released its hold on GCC 3.3.1
> > > yesterday.
> > >
> > > I've applied the last patches to GCC 3.3.1, and the release will be
> > > out within a few days.  The FSF's machines have been cracked again, so
> > > they are going through the process of recreating accounts.
> > >
> > > The 3.3.1 target should be removed from bugzilla, but I do not know
> > > how to do this.
>
> > Mass change all the 3.3.1 targets to 3.3.2
> > Then edit the products, choose gcc, choose edit target milestones, and
> > delete 3.3.1
>
> Wait just a minute!  You're about to screw up my life.
>
I'm not about to do anything.
:)
He asked how to remove a target.
I don't actually thing we should remove a target.

But, when removing a target, you should retarget all the bugs targeted at
it.


> How, when I am preparing the release notes for 3.3.2, am I to distinguish
> bugs that are fixed in 3.3.1 from those fixed in 3.3.2 if you change all
> occurrences of "3.3.1" to "3.3.2" even in bugs that are already marked
> as fixed?

>

Re: GCC Release Status (2003-08-03)

[Mark Mitchell]

> > Mass change all the 3.3.1 targets to 3.3.2
> > Then edit the products, choose gcc, choose edit target milestones, and
> > delete 3.3.1
>
> Wait just a minute!  You're about to screw up my life.
>
> How, when I am preparing the release notes for 3.3.2, am I to distinguish
> bugs that are fixed in 3.3.1 from those fixed in 3.3.2 if you change all
> occurrences of "3.3.1" to "3.3.2" even in bugs that are already marked
> as fixed?

The good news is that I didn't understand Dan's instructions. :-)

Anyhow, we certainly shouldn't change old, closed bugs.  I just want to keep
people from marking new bugs as targeted for 3.3.1.

Thanks,

-- Mark

Re: GCC Release Status (2003-08-03)

[Daniel Berlin]

On Monday, August 4, 2003, at 11:28 PM, Mark Mitchell wrote:

>
>>> Mass change all the 3.3.1 targets to 3.3.2
>>> Then edit the products, choose gcc, choose edit target milestones, 
>>> and
>>> delete 3.3.1
>>
>> Wait just a minute!  You're about to screw up my life.
>>
>> How, when I am preparing the release notes for 3.3.2, am I to 
>> distinguish
>> bugs that are fixed in 3.3.1 from those fixed in 3.3.2 if you change 
>> all
>> occurrences of "3.3.1" to "3.3.2" even in bugs that are already marked
>> as fixed?
>
> The good news is that I didn't understand Dan's instructions. :-)
>
> Anyhow, we certainly shouldn't change old, closed bugs.  I just want 
> to keep
> people from marking new bugs as targeted for 3.3.1.
>
I can add this feature if you guys really want it, I just see it as a 
"don't do that" type thing that we're all smart enough not to do.  Why 
would a developer target a new bug at an old release?
Remember, users can't target bugs to milestones.


> Thanks,
>
> -- Mark
>

Re: GCC Release Status (2003-08-03)

[Richard Earnshaw]

> > Anyhow, we certainly shouldn't change old, closed bugs.  I just want 
> > to keep
> > people from marking new bugs as targeted for 3.3.1.
> >
> I can add this feature if you guys really want it, I just see it as a 
> "don't do that" type thing that we're all smart enough not to do.  Why 
> would a developer target a new bug at an old release?
> Remember, users can't target bugs to milestones.

Can we have the concept of "obsolete milestones"?  Ie they remain valid 
(from an historical perspective), but aren't available in the pull-down 
menu on the various bug pages (this stops the list growing excessively 
long with obsolete options as time passes).

R.

Re: GCC Release Status (2003-08-03)

[Joe Buck]

On Monday, August 4, 2003, at 11:28 PM, Mark Mitchell wrote:
> > Anyhow, we certainly shouldn't change old, closed bugs.  I just want 
> > to keep
> > people from marking new bugs as targeted for 3.3.1.

On Mon, Aug 04, 2003 at 11:41:00PM -0400, Daniel Berlin wrote:
> I can add this feature if you guys really want it, I just see it as a 
> "don't do that" type thing that we're all smart enough not to do.  Why 
> would a developer target a new bug at an old release?
> Remember, users can't target bugs to milestones.

I've already spent time changing incorrectly set target milestones, and
I can change them again if need be.  We don't have to make the tools force
us to behave; we can use peer pressure (after all, all of us with CVS
write access could do whatever we want, and we don't).

I don't think we need to ask Daniel to do anything here.  All we need is
for the folks with Bugzilla write access to understand the rule.

In any case, for every rule there's an exception: what if we discover,
after the release, that some open bug was actually fixed in 3.3.1?  Why
*not* set the target milestone to 3.3.1 and add it to the list of fixed
bugs?

My goal here is to get to the point where I can do the release notes with
one Bugzilla query.  Dream on, of course; I still have to distinguish bugs
that arose during development and never appeared in any release, as well
as do a sanity check, but if I can at least get a superset, that will save
a lot of work.

Re: GCC Release Status (2003-08-03)

[Mark Mitchell]

On Tue, 2003-08-05 at 18:41, Joe Buck wrote:
> In any case, for every rule there's an exception: what if we discover,
> after the release, that some open bug was actually fixed in 3.3.1?  Why
> *not* set the target milestone to 3.3.1 and add it to the list of fixed
> bugs?

I suppose that makes sense.  It's a little confusing, in that a bugzilla
query done after the fact will show up different results than the one
you used to generate the release notes, but the bottom line is this: the
service that you provide by doing the release notes is so great that
whatever you think will make it easiest for you do to that is what we
should do.

If you think we needn't do anything here, that's good enough for me.

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

Re: GCC Release Status (2003-08-03)

[Joe Buck]

On Wed, Aug 06, 2003 at 08:47:07AM -0700, Mark Mitchell wrote:
> On Tue, 2003-08-05 at 18:41, Joe Buck wrote:
> > In any case, for every rule there's an exception: what if we discover,
> > after the release, that some open bug was actually fixed in 3.3.1?  Why
> > *not* set the target milestone to 3.3.1 and add it to the list of fixed
> > bugs?
> 
> I suppose that makes sense.  It's a little confusing, in that a bugzilla
> query done after the fact will show up different results than the one
> you used to generate the release notes,

Right, but I would then correct the gcc-3.x/changes.html page on the
web to compensate.

> If you think we needn't do anything here, that's good enough for me.

I don't think that we need to do anything here.  We might want to revisit
the issue five or six releases down the road, when the growing choice list
for target-milestone becomes inconvenient.  But at least for now, let's
just leave it.

Re: GCC Release Status (2003-08-03)

[Daniel Berlin]

On Wednesday, August 6, 2003, at 12:37 PM, Joe Buck wrote:

> On Wed, Aug 06, 2003 at 08:47:07AM -0700, Mark Mitchell wrote:
>> On Tue, 2003-08-05 at 18:41, Joe Buck wrote:
>>> In any case, for every rule there's an exception: what if we 
>>> discover,
>>> after the release, that some open bug was actually fixed in 3.3.1?  
>>> Why
>>> *not* set the target milestone to 3.3.1 and add it to the list of 
>>> fixed
>>> bugs?
>>
>> I suppose that makes sense.  It's a little confusing, in that a 
>> bugzilla
>> query done after the fact will show up different results than the one
>> you used to generate the release notes,
>
> Right, but I would then correct the gcc-3.x/changes.html page on the
> web to compensate.
>
>> If you think we needn't do anything here, that's good enough for me.
>
> I don't think that we need to do anything here.  We might want to 
> revisit
> the issue five or six releases down the road, when the growing choice 
> list
> for target-milestone becomes inconvenient.  But at least for now, let's
> just leave it.

I can change the sort keys so that the active milestones are always on 
top.

Re: GCC Release Status (2003-08-03)

[Joe Buck]

On Wed, Aug 06, 2003 at 12:47:15PM -0400, Daniel Berlin wrote:
> I can change the sort keys so that the active milestones are always on 
> top.

Cool!  Please do that.

Re: GCC Release Status (2003-08-03)

[Daniel Berlin]

On Wednesday, August 6, 2003, at 12:51 PM, Joe Buck wrote:

> On Wed, Aug 06, 2003 at 12:47:15PM -0400, Daniel Berlin wrote:
>> I can change the sort keys so that the active milestones are always on
>> top.
>
> Cool!  Please do that.
>
Done.
If you look, you'll see that 3.3.1 now is at the bottom of the list, 
under the separator.

Re: GCC Release Status (2003-08-03)

[Mark Mitchell]

> I can add this feature if you guys really want it, I just see it as a
> "don't do that" type thing that we're all smart enough not to do.  Why
> would a developer target a new bug at an old release?
> Remember, users can't target bugs to milestones.

I'm smart, but I've made mistakes before.

The computer should be able to keep me from making this particular mistake.

The failure mode is that a bug goes into everlasting limbo, which would
hardly say good things about our quality processes.

Therefore, if you can make the computer keep me out of trouble, that would
be good.

Thanks,

-- Mark

Re: GCC Release Status (2003-08-03)

[Nathanael Nerode]

>The 3.3.1 target should be removed from bugzilla, but I do not know
>how to do this.

Should it?  I'm not sure about that.  It's still the correct target for 
the many *resolved* bugs which were fixed in 3.3.1; or will they have 
their target set to "--"?  If so, make sure not to remove the target 
until the 3.3.1 release notes are final, with the corresponding list 
generated.  :-)

At any rate, it should not be allowed as a target for open bugs any more.

Re: GCC Release Status (2003-08-03)

[Daniel Berlin]

On Sunday, August 3, 2003, at 1:24 PM, Nathanael Nerode wrote:

>> The 3.3.1 target should be removed from bugzilla, but I do not know
>> how to do this.
>
> Should it?  I'm not sure about that.  It's still the correct target 
> for the many *resolved* bugs which were fixed in 3.3.1; or will they 
> have their target set to "--"?

They are fixed, so they shouldn't have a milestone target anymore, 
unless you want one so you can tell what *was* fixed in 3.3.1.

> If so, make sure not to remove the target until the 3.3.1 release 
> notes are final, with the corresponding list generated.  :-)
>
> At any rate, it should not be allowed as a target for open bugs any 
> more.

I don't think i need to make bugzilla have support for "non-open" 
milestones, since the people targeting things (IE not the users) know 
which are open and which aren't.

Re: GCC Release Status (2003-08-03)

[Joe Buck]

On Sun, Aug 03, 2003 at 05:30:39PM -0400, Daniel Berlin wrote:
> 
> On Sunday, August 3, 2003, at 1:24 PM, Nathanael Nerode wrote:
> 
> >> The 3.3.1 target should be removed from bugzilla, but I do not know
> >> how to do this.
> >
> > Should it?  I'm not sure about that.  It's still the correct target 
> > for the many *resolved* bugs which were fixed in 3.3.1; or will they 
> > have their target set to "--"?
> 
> They are fixed, so they shouldn't have a milestone target anymore, 
> unless you want one so you can tell what *was* fixed in 3.3.1.
> 
> > If so, make sure not to remove the target until the 3.3.1 release 
> > notes are final, with the corresponding list generated.  :-)
> >
> > At any rate, it should not be allowed as a target for open bugs any 
> > more.
> 
> I don't think i need to make bugzilla have support for "non-open" 
> milestones, since the people targeting things (IE not the users) know 
> which are open and which aren't.

But you will be erasing historical data (about which bugs were fixed in
which release).  How will we ever get that data back once you destroy it?

Re: GCC Release Status (2003-08-03)

[Daniel Berlin]

On Mon, 4 Aug 2003, Joe Buck wrote:

> On Sun, Aug 03, 2003 at 05:30:39PM -0400, Daniel Berlin wrote:
> >
> > On Sunday, August 3, 2003, at 1:24 PM, Nathanael Nerode wrote:
> >
> > >> The 3.3.1 target should be removed from bugzilla, but I do not know
> > >> how to do this.
> > >
> > > Should it?  I'm not sure about that.  It's still the correct target
> > > for the many *resolved* bugs which were fixed in 3.3.1; or will they
> > > have their target set to "--"?
> >
> > They are fixed, so they shouldn't have a milestone target anymore,
> > unless you want one so you can tell what *was* fixed in 3.3.1.
> >
> > > If so, make sure not to remove the target until the 3.3.1 release
> > > notes are final, with the corresponding list generated.  :-)
> > >
> > > At any rate, it should not be allowed as a target for open bugs any
> > > more.
> >
> > I don't think i need to make bugzilla have support for "non-open"
> > milestones, since the people targeting things (IE not the users) know
> > which are open and which aren't.
>
> But you will be erasing historical data (about which bugs were fixed in
> which release).  How will we ever get that data back once you destroy it?

Err, I suggested we not delete old milestones if you want to know what
was fixed in a given version. You must be misreading me.