Re: GCC 4.3 release schedule

Re: GCC 4.3 release schedule

[Benjamin Kosnik]

> I'd rather take the make the dot-zero release approach while branching
> and count on interested people fixing bugs on the branch after the
> dot-zero release.  This way if nobody is interested on a particular
> release series then we can declare the dot-zero release final -
> otherwise we'd do more releases from the branch anyway.

Quite honestly, I think a version of this basic idea is an improvement
over the current vague procedures, and certainly worth trying. I would
be open to experimentation in the gcc release procedure, especially
after the trials of the 4.2.x series.

Aligning Stage 1 freedoms immeidately after the confinements of Stage
3 branch/dot-zero-release seems to be the most natural way to motivate
work on Stage 3 fixing/polishing. Our current procedure works against
this natural flow.

So, the way I see it, something like this:

- now till < 100 bugs: Stage 3. Weekly bug counts sent to gcc list.

- < 100 bugs: mainline freeze, branch, lockdown for two weeks. All
  hands on board for release. All checkins must have bz#. End two week
  lockdown with 4.3.0 release candidate 1.

- 4.3.0.rc1 release, mainline Stage 1. + 2 weeks, 4.3.0.rc2. 

- 4.3.0.rc2 + 2 weeks, 4.3.0 final. (or mainline Stage 1 here?)

Temporary pain for long-term gain.

Anyway. I'm surprised this suggestion did not get more comments. This
is much more transparent than current procedures, and has a chance of
focusing the gcc community on releases, not on the wide-open gates of
Stage 1.

-benjamin

Re: GCC 4.3 release schedule

[Andrew MacLeod]

Benjamin Kosnik wrote:
>   
>> I'd rather take the make the dot-zero release approach while branching
>> and count on interested people fixing bugs on the branch after the
>> dot-zero release.  This way if nobody is interested on a particular
>> release series then we can declare the dot-zero release final -
>> otherwise we'd do more releases from the branch anyway.
>>     
>
> Quite honestly, I think a version of this basic idea is an improvement
> over the current vague procedures, and certainly worth trying. I would
> be open to experimentation in the gcc release procedure, especially
> after the trials of the 4.2.x series.
>
> Aligning Stage 1 freedoms immeidately after the confinements of Stage
> 3 branch/dot-zero-release seems to be the most natural way to motivate
> work on Stage 3 fixing/polishing. Our current procedure works against
> this natural flow.
>
> So, the way I see it, something like this:
>
> - now till < 100 bugs: Stage 3. Weekly bug counts sent to gcc list.
>
> - < 100 bugs: mainline freeze, branch, lockdown for two weeks. All
>   hands on board for release. All checkins must have bz#. End two week
>   lockdown with 4.3.0 release candidate 1.
>
> - 4.3.0.rc1 release, mainline Stage 1. + 2 weeks, 4.3.0.rc2. 
>
> - 4.3.0.rc2 + 2 weeks, 4.3.0 final. (or mainline Stage 1 here?)
>
> Temporary pain for long-term gain.
>
> Anyway. I'm surprised this suggestion did not get more comments. This
> is much more transparent than current procedures, and has a chance of
> focusing the gcc community on releases, not on the wide-open gates of
> Stage 1.
>
> -benjamin
>   
The only problem, is that anyone doing stage 1 work is already doing so 
in a  branch, and history (at least as I remember it :-) is that if  
little johnny doesn't have a pressing need for the current release, he 
will simply keep plugging along on his branch until stage 1 happens, 
whether its 2 weeks away or 3 months.

But yes, Id still be in favour of trying this or anything else which 
might help. Cut a release branch, and simply refuse to open stage 1 
until we release. Something has to help.  Often there is a race for 
merging branches when stage 1 opens (the earlier you merge, the easier 
it is). Maybe we can have a short stage 0.9 for merging of branches/work 
to mainline for those that contributed to getting the release out.  
Maybe that would help too, but then you'd have to define "contribution" :-).

   Ultimately, we need to get people interested in actually getting a 
release out.  I don't know of an easier way do that than aligning your 
desire to have a release with someone else wanting to use it. That at 
least motivates them, and locking into stage 3 until its released may 
encourage others to assist.

Andrew

Re: GCC 4.3 release schedule

[Benjamin Kosnik]

> The only problem, is that anyone doing stage 1 work is already doing
> so in a  branch, and history (at least as I remember it :-) is that
> if little johnny doesn't have a pressing need for the current
> release, he will simply keep plugging along on his branch until stage
> 1 happens, whether its 2 weeks away or 3 months.

Ahhh... but you show the way to induce participation here:
 
> But yes, Id still be in favour of trying this or anything else which 
> might help. Cut a release branch, and simply refuse to open stage 1 
> until we release. Something has to help.  Often there is a race for 
> merging branches when stage 1 opens (the earlier you merge, the
> easier it is). Maybe we can have a short stage 0.9 for merging of
> branches/work to mainline for those that contributed to getting the
> release out. Maybe that would help too, but then you'd have to define
> "contribution" :-).

This 0.9 stage idea is golden.

Why don't we just straight out rank bugs closed to merge priority? Most
bugs fixed means first merge in stage one, period. Second higest # of
bugs fixed means second merge, etc etc.

That really aligns things correctly!

-benjamin

Re: GCC 4.3 release schedule

[Richard Guenther]

On 10/29/07, Benjamin Kosnik <bkoz@redhat.com> wrote:
>
> > The only problem, is that anyone doing stage 1 work is already doing
> > so in a  branch, and history (at least as I remember it :-) is that
> > if little johnny doesn't have a pressing need for the current
> > release, he will simply keep plugging along on his branch until stage
> > 1 happens, whether its 2 weeks away or 3 months.
>
> Ahhh... but you show the way to induce participation here:
>
> > But yes, Id still be in favour of trying this or anything else which
> > might help. Cut a release branch, and simply refuse to open stage 1
> > until we release. Something has to help.  Often there is a race for
> > merging branches when stage 1 opens (the earlier you merge, the
> > easier it is). Maybe we can have a short stage 0.9 for merging of
> > branches/work to mainline for those that contributed to getting the
> > release out. Maybe that would help too, but then you'd have to define
> > "contribution" :-).
>
> This 0.9 stage idea is golden.
>
> Why don't we just straight out rank bugs closed to merge priority? Most
> bugs fixed means first merge in stage one, period. Second higest # of
> bugs fixed means second merge, etc etc.
>
> That really aligns things correctly!

I'd rather rate along highest # of bugs still open in subsystem merged
by contributor.
Those get to merge last, as they didn't show incentive to maintain
their merged code
(and yes, this happens).

Richard.

Re: GCC 4.3 release schedule

[Jason Merrill]

Andrew MacLeod wrote:
> But yes, Id still be in favour of trying this or anything else which 
> might help. Cut a release branch, and simply refuse to open stage 1 
> until we release.

I think I prefer Richard's suggestion of not branching until we're ready 
to make the .0 release.  The effect should be the same except that 
people don't have to deal with checking patches in on the branch vs. the 
trunk until after 4.3.0 goes out.

Jason

Re: GCC 4.3 release schedule

[Andrew MacLeod]

Jason Merrill wrote:
> Andrew MacLeod wrote:
>> But yes, Id still be in favour of trying this or anything else which 
>> might help. Cut a release branch, and simply refuse to open stage 1 
>> until we release.
>
> I think I prefer Richard's suggestion of not branching until we're 
> ready to make the .0 release.  The effect should be the same except 
> that people don't have to deal with checking patches in on the branch 
> vs. the trunk until after 4.3.0 goes out.

Sure, I think it boils down to the same thing from a conceptual point of 
view, but perhaps the nitty gritty details are easier if you keep it as 
mainline so we dont have to check everything into 2 branches.  Bottom 
line is you freeze development until its time to release.

Andrew

Re: GCC 4.3 release schedule

[Richard Guenther]

On 10/29/07, Andrew MacLeod <amacleod@redhat.com> wrote:
> Jason Merrill wrote:
> > Andrew MacLeod wrote:
> >> But yes, Id still be in favour of trying this or anything else which
> >> might help. Cut a release branch, and simply refuse to open stage 1
> >> until we release.
> >
> > I think I prefer Richard's suggestion of not branching until we're
> > ready to make the .0 release.  The effect should be the same except
> > that people don't have to deal with checking patches in on the branch
> > vs. the trunk until after 4.3.0 goes out.
>
> Sure, I think it boils down to the same thing from a conceptual point of
> view, but perhaps the nitty gritty details are easier if you keep it as
> mainline so we dont have to check everything into 2 branches.  Bottom
> line is you freeze development until its time to release.

Well... this is the point of having stage3 ;)  Of course work goes on on
branches.  One point of essentially freezing mainline until the release
is to not pessimize people fixing bugs for the release instead of doing
work on the already-open-after-branching stage1.  This theoretically
would allow shortening stage1 drastically (to lets say 2 weeks of
branch merging and another 4 weeks of general "patches") to get back
to a 6 month release cycle (I personally think the each-stage-is-2-month
is not realistic).

Richard.

Re: GCC 4.3 release schedule

[Andrew MacLeod]

Richard Guenther wrote:
>> Sure, I think it boils down to the same thing from a conceptual point of
>> view, but perhaps the nitty gritty details are easier if you keep it as
>> mainline so we dont have to check everything into 2 branches.  Bottom
>> line is you freeze development until its time to release.
>>     
>
> Well... this is the point of having stage3 ;)  Of course work goes on on
> branches.  One point of essentially freezing mainline until the release
> is to not pessimize people fixing bugs for the release instead of doing
> work on the already-open-after-branching stage1.  This theoretically
>   

but people do continue working on branches parallel to stage 3, and we 
are looking for a way to focus people onto stage 3 in order to get it 
out in a timely fashion. simply locking it down doesn't do that, either 
in a branch or on mainline, we've seen it in the past. I've been guilty 
of it. I have had other big ticket items I'm working on, and if the 
release isn't something that fits into plans anywhere, it doesn't matter 
when it gets released, so the other work is more important.  And lets 
face it, bug fixing isn't exciting and motivating work to most people.  
We need a reason to get interested enough to focus on getting the 
release out.
> would allow shortening stage1 drastically (to lets say 2 weeks of
> branch merging and another 4 weeks of general "patches") to get back
> to a 6 month release cycle (I personally think the each-stage-is-2-month
> is not realistic).
>
>   
I don't think we need a 6 month release cycle myself, but maybe thats 
just me.  Are people actually looking for new compilers that 
frequently?  I wouldn't think that would be the norm. thats barely time 
for the compiler to properly stabilize.  I think it would be even harder 
to get focus on stage 3 that frequently. I still think we need to try to 
have a look at the schedules of the various groups that USE the 
compiler, and set our release schedules to something that is going to be 
useful to multiple groups, thus generating the most interest in a  release.

Andrew

Re: GCC 4.3 release schedule

[Richard Guenther]

On 10/29/07, Andrew MacLeod <amacleod@redhat.com> wrote:
> Richard Guenther wrote:
> >> Sure, I think it boils down to the same thing from a conceptual point of
> >> view, but perhaps the nitty gritty details are easier if you keep it as
> >> mainline so we dont have to check everything into 2 branches.  Bottom
> >> line is you freeze development until its time to release.
> >>
> >
> > Well... this is the point of having stage3 ;)  Of course work goes on on
> > branches.  One point of essentially freezing mainline until the release
> > is to not pessimize people fixing bugs for the release instead of doing
> > work on the already-open-after-branching stage1.  This theoretically
> >
>
> but people do continue working on branches parallel to stage 3, and we
> are looking for a way to focus people onto stage 3 in order to get it
> out in a timely fashion. simply locking it down doesn't do that, either
> in a branch or on mainline, we've seen it in the past. I've been guilty
> of it. I have had other big ticket items I'm working on, and if the
> release isn't something that fits into plans anywhere, it doesn't matter
> when it gets released, so the other work is more important.  And lets
> face it, bug fixing isn't exciting and motivating work to most people.
> We need a reason to get interested enough to focus on getting the
> release out.

That's true.  We need to ensure we end stage3 with a release (even
if it will be of worse quality than usual, just because nobody was
really interested in it).  Just opening stage1 and _not_ releasing
doesn't make this particular situation better.

> > would allow shortening stage1 drastically (to lets say 2 weeks of
> > branch merging and another 4 weeks of general "patches") to get back
> > to a 6 month release cycle (I personally think the each-stage-is-2-month
> > is not realistic).
> >
> >
> I don't think we need a 6 month release cycle myself, but maybe thats
> just me.  Are people actually looking for new compilers that
> frequently?  I wouldn't think that would be the norm. thats barely time
> for the compiler to properly stabilize.  I think it would be even harder
> to get focus on stage 3 that frequently. I still think we need to try to
> have a look at the schedules of the various groups that USE the
> compiler, and set our release schedules to something that is going to be
> useful to multiple groups, thus generating the most interest in a  release.

*sigh* - also true.  I thought with a shorter release cycle it would be easier
to tell people "no, your feature is not ready for this stage1, just wait N
month until next stage1" with N being reasonable (that is, less than half
a year).  For 4.3 we had a nearly 8 month stage1(!) and doing release
planning in advance (the scheduled project list) before any code
exists doesn't help this.  We simply shouldn't promise to merge anything
for a specific release.  We should merge things when they are ready and
when trunk is in the right stage.  But I guess the GCC development
model just doesn't work like this :(

Richard.

RE: GCC 4.3 release schedule

[Eric Weddington]

 

> -----Original Message-----
> From: Andrew MacLeod [mailto:amacleod@redhat.com] 
> Sent: Monday, October 29, 2007 12:48 PM
> To: Richard Guenther
> Cc: Jason Merrill; Benjamin Kosnik; gcc@gcc.gnu.org; 
> mark@codesourcery.com
> Subject: Re: GCC 4.3 release schedule

> I don't think we need a 6 month release cycle myself, but maybe thats 
> just me.  Are people actually looking for new compilers that 
> frequently? 

It depends on the community using it. For the AVR, 3-6 months is the norm
because of the need to have support for new AVR devices (variants). We're
currently working adding 19 new devices for the next release cycle.

Eric Weddington

Re: GCC 4.3 release schedule

[Benjamin Kosnik]

> I think I prefer Richard's suggestion of not branching until we're
> ready to make the .0 release.  The effect should be the same except
> that people don't have to deal with checking patches in on the branch
> vs. the trunk until after 4.3.0 goes out.

This would certainly make things easier. And easier is fine by me...

Jason, any thoughts on how to translate "ready to make a .0 release"
into "made a .0 release," in terms of a firm schedule, with dates? I'm
assuming that the < 100 bugzilla count is an adequate milestone for the
release branch to be cut.

Or do you think < 100 implies branch implies 4.3.0 release, as
originally described by Richard is the way to go?

I'm willing to try this. It's just that I would like some advance notice
before a release, just to check over things. (Say, a week. Maybe two. It
doesn't have to be a long time. And it should definitely not stretch
to 1 or 7 months...)

Just curious. I think we all agree on the general goal of a rapid and
timely release once the branch is cut. It's the specific details that
I'm curious to learn...

-benjamin

Re: GCC 4.3 release schedule

[Richard Guenther]

On 10/29/07, Benjamin Kosnik <bkoz@redhat.com> wrote:
>
> > I think I prefer Richard's suggestion of not branching until we're
> > ready to make the .0 release.  The effect should be the same except
> > that people don't have to deal with checking patches in on the branch
> > vs. the trunk until after 4.3.0 goes out.
>
> This would certainly make things easier. And easier is fine by me...
>
> Jason, any thoughts on how to translate "ready to make a .0 release"
> into "made a .0 release," in terms of a firm schedule, with dates? I'm
> assuming that the < 100 bugzilla count is an adequate milestone for the
> release branch to be cut.
>
> Or do you think < 100 implies branch implies 4.3.0 release, as
> originally described by Richard is the way to go?
>
> I'm willing to try this. It's just that I would like some advance notice
> before a release, just to check over things. (Say, a week. Maybe two. It
> doesn't have to be a long time. And it should definitely not stretch
> to 1 or 7 months...)

Sure.  I'd expect the usual release candidate or two separated by
one or two weeks.  I'd also expect the mainline to be frozen after rc1.
I guess branching can happen at the point there is either rc2 or
the 4.3.0 release.

> Just curious. I think we all agree on the general goal of a rapid and
> timely release once the branch is cut. It's the specific details that
> I'm curious to learn...

We'll all learn as this would be the first time we do it this way ;)

Richard.

Re: GCC 4.3 release schedule

[Mark Mitchell]

Richard Guenther wrote:

> Sure.  I'd expect the usual release candidate or two separated by
> one or two weeks.  I'd also expect the mainline to be frozen after rc1.
> I guess branching can happen at the point there is either rc2 or
> the 4.3.0 release.

I'm following this discussion closely, of course.

To tell the truth, I'm pleased that consensus seems to be developing
around delaying Stage 1 until we have a release out the door.  My only
concern with that in the past has been that people might not be willing
to do it.  Not creating a branch will somewhat increase pressure to
focus on the release -- but that will only work if enough people are
actually motivated to work on the release anyhow.  It seems like there's
enough momentum in this cycle to make that work.

I'll keep listening, in case there's more feedback, but it seems like a
good plan to me.

Thanks,

-- 
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713

Re: GCC 4.3 release schedule

[Jason Merrill]

Benjamin Kosnik wrote:
> Jason, any thoughts on how to translate "ready to make a .0 release"
> into "made a .0 release," in terms of a firm schedule, with dates? I'm
> assuming that the < 100 bugzilla count is an adequate milestone for the
> release branch to be cut.
> 
> Or do you think < 100 implies branch implies 4.3.0 release, as
> originally described by Richard is the way to go?

No.  Previously we've branched at <100 regressions, but waited for the 
numbers to get better than that before making the release.  I'm 
suggesting that the release criteria stay about the same as before, just 
that we delay the branch until the release is ready rather than have 
branch criteria and then release criteria.

> I'm willing to try this. It's just that I would like some advance notice
> before a release, just to check over things.

I would expect Mark's status mails to cover that.

Jason

Re: GCC 4.3 release schedule

[Mark Mitchell]

Jason Merrill wrote:

> No.  Previously we've branched at <100 regressions, but waited for the
> numbers to get better than that before making the release.  I'm
> suggesting that the release criteria stay about the same as before, just
> that we delay the branch until the release is ready rather than have
> branch criteria and then release criteria.

Yes, that's what I'm imagining too, under this plan.  All we'd be doing
differently is delaying Stage 1 until after the release, instead of
parallelizing Stage 1 with the final release preparation.

-- 
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713

Re: GCC 4.3 release schedule

[Gerald Pfeifer]

On Mon, 29 Oct 2007, Jason Merrill wrote:
> I think I prefer Richard's suggestion of not branching until we're ready to
> make the .0 release.  The effect should be the same except that people don't
> have to deal with checking patches in on the branch vs. the trunk until after
> 4.3.0 goes out.

I like this approach.

Gerald

Re: GCC 4.3 release schedule

[Andrew MacLeod]

Gerald Pfeifer wrote:
> On Mon, 29 Oct 2007, Jason Merrill wrote:
>   
>> I think I prefer Richard's suggestion of not branching until we're ready to
>> make the .0 release.  The effect should be the same except that people don't
>> have to deal with checking patches in on the branch vs. the trunk until after
>> 4.3.0 goes out.
>>     
>
> I like this approach.
>   

So have we come to some sort of consensus here?  We leave mainline as 
stage 3 until we release? or at least have a somewhat final release 
candidate?

Once we hit the target of 100 open PRs,( or whenever we would have 
originally cut a stage 3 release branch),  we firm up stage 3 so that 
*really* only bugfixes go in.  Then we work toward a release candidate, 
etc etc.?

We can play it by ear, but do you want to wait to open stage 1 until we  
actually release 4.3, or do it after RC2 or something like that where 
there isn't much else going to happen to it?   Either works for me, but 
I don't see that opening stage 1 before we actually release buys us much.


Andrew

Re: GCC 4.3 release schedule

[Benjamin Kosnik]

> >> I think I prefer Richard's suggestion of not branching until we're
> >> ready to make the .0 release.  The effect should be the same
> >> except that people don't have to deal with checking patches in on
> >> the branch vs. the trunk until after 4.3.0 goes out.
> >>     
> >
> > I like this approach.

Me too. 

I'm also very pleased that the RM and SC are open and willing to
consider changes of this nature to GCC release procedure. Thanks.

> So have we come to some sort of consensus here?  We leave mainline as 
> stage 3 until we release? or at least have a somewhat final release 
> candidate?

The summary of this thread is that opening stage 1 before we
release hurts us. So, we're trying to figure out another way.

I think there is consensus that this is a good idea. Well, maybe not
consensus, but all the posted commentary seems in favor. I assume if
people objected, they'd say something... 
 
> Once we hit the target of 100 open PRs,( or whenever we would have 
> originally cut a stage 3 release branch),  we firm up stage 3 so that 
> *really* only bugfixes go in.  Then we work toward a release
> candidate, etc etc.?

I guess. This is the part that is less certain to me. There is less
consensus here, in that Richard and I are advocating a strict
time-based release schedule once the < 100 PR bit is flipped, with
staggered RCs. (Richard, I hope this generalized summary is accurate.) 

Jason and Mark seem to be less impressed with this specific part. 

> We can play it by ear, but do you want to wait to open stage 1 until
> we actually release 4.3, or do it after RC2 or something like that
> where there isn't much else going to happen to it?   Either works for
> me, but I don't see that opening stage 1 before we actually release
> buys us much.

So, I'd guess Stage 1 opens after 4.3.0 is released, or at least tagged
in SVN.

-benjamin

Re: GCC 4.3 release schedule

[Richard Guenther]

On 11/1/07, Benjamin Kosnik <bkoz@redhat.com> wrote:

> > Once we hit the target of 100 open PRs,( or whenever we would have
> > originally cut a stage 3 release branch),  we firm up stage 3 so that
> > *really* only bugfixes go in.  Then we work toward a release
> > candidate, etc etc.?
>
> I guess. This is the part that is less certain to me. There is less
> consensus here, in that Richard and I are advocating a strict
> time-based release schedule once the < 100 PR bit is flipped, with
> staggered RCs. (Richard, I hope this generalized summary is accurate.)

No, I was suggesting a more "when we think it's ready" approach
(so, leave it basically unspecified).  Of course we have the usual
indicators of the number of regressions against previous releases and
the number of P1 bugs.  I don't think there should be any automatism
at the point we reach <100 regressions.  Rather for example once
that happens, going over the remaining regressions and deciding
which ones we want to fix before the release and doing so.  Of course
at some point a RC is warranted, as only that might be tested by some
more obscure targets.

> Jason and Mark seem to be less impressed with this specific part.

I'd agree with them.

Richard.

Re: GCC 4.3 release schedule

[Diego Novillo]

On 11/1/07, Gerald Pfeifer <gerald@pfeifer.com> wrote:
> On Mon, 29 Oct 2007, Jason Merrill wrote:
> > I think I prefer Richard's suggestion of not branching until we're ready to
> > make the .0 release.  The effect should be the same except that people don't
> > have to deal with checking patches in on the branch vs. the trunk until after
> > 4.3.0 goes out.
>
> I like this approach.

Likewise.


Diego.

Re: GCC 4.3 release schedule

[J.C. Pizarro]

I've a fast idea.

To release now it as gcc-4.3.0 if the building of distribution's base
doesn't crashes.

To start the branch for gcc-4.4-ss.

Many linux's people start to test gcc-4.3.0 from their distributions
and to report their bugs.

Tomorrow, we will have a rocked gcc-4.3.15 quickly possible.

    J.C. Pizarro

GCC 4.3 release schedule

[Andrew MacLeod]

Now that GCC is in stage 4.3, I think we'd all be in agreement that it 
would be nice to keep this stage short and get a release out.

We are interested in using 4.3 as the system compiler in Fedora 9, and 
as such, we'd like to nail down some time lines and requirements with 
release management and the steering committee.

The timelines involved are something like this:  (clearly anything 
earlier would be great :-)

Nov 14th - we'd like to start building F9 with a 4.3 compiler. Ideally 
we'd have a branch cut no later than that and starting to stabilize 
without much new code going in.
Dec 14th - viability decision on using 4.3 as the F9 compiler.  There is 
a window here as late as Jan 14th, but the opinions will start forming 
in Dec. There shouldn't be any ABI changes from this point on.
Feb 29th - Optimistic target date for a 4.3 release.  can slip as much 
as a  month,  but clearly the earlier the release happens the better.

I don't recall seeing any other timeline requirements, does this seem 
like a reasonable target schedule? Once a decision is made to use 4.3 by 
mid-jan, it becomes very difficult to back out if something happens to 
the release date, so it becomes quite important that the final criteria 
is well understood by then and appears reachable.  If something 
unforeseen happens late in the cycle to delay the release, its also 
important that we can get some sort of steering committee agreement on 
what to do so we don't have some sort of evil gcc offspring as happened 
once before. Thats something I don't expect to happen, but will have to 
visit as risk management before the final decision is made.   My hope is 
that it'll be in good enough shape by mid january that slippage by that 
much is unlikely and isn't an issue.

Does this seem like a reasonable schedule?  Can we set the criteria for 
what a final release would look like?  We're committed to applying 
engineering resource to help make it happen.

Andrew

Re: GCC 4.3 release schedule

[Richard Guenther]

On 10/26/07, Andrew MacLeod <amacleod@redhat.com> wrote:
>
> Now that GCC is in stage 4.3, I think we'd all be in agreement that it
> would be nice to keep this stage short and get a release out.
>
> We are interested in using 4.3 as the system compiler in Fedora 9, and
> as such, we'd like to nail down some time lines and requirements with
> release management and the steering committee.

Of course it doesn't work like this ;)

> The timelines involved are something like this:  (clearly anything
> earlier would be great :-)
>
> Nov 14th - we'd like to start building F9 with a 4.3 compiler. Ideally
> we'd have a branch cut no later than that and starting to stabilize
> without much new code going in.

I oppose to cut a branch without immediately releasing 4.3.0.  This just
doesn't work - just look at the history.  I also think that Nov 14th is _very_
optimistic (I personally was thinking about a (early) Q1 release).

Note that we are building what-becomes-openSUSE 11.0 with current trunk
in parallel to 4.2 at the moment, switching to 4.3 is in the next weeks
(unless I get pushed back again ;)).

> Dec 14th - viability decision on using 4.3 as the F9 compiler.  There is
> a window here as late as Jan 14th, but the opinions will start forming
> in Dec. There shouldn't be any ABI changes from this point on.
> Feb 29th - Optimistic target date for a 4.3 release.  can slip as much
> as a  month,  but clearly the earlier the release happens the better.

If we branch too early I bet we will not make even the Feb 29th date.

How does targeting a release around Feb 1st sound (that is, without
branching before, a RC1 on Feb 1st, the release including branching
a week or two later)?  It looks like that would work for your constraints.

> I don't recall seeing any other timeline requirements, does this seem
> like a reasonable target schedule? Once a decision is made to use 4.3 by
> mid-jan, it becomes very difficult to back out if something happens to
> the release date, so it becomes quite important that the final criteria
> is well understood by then and appears reachable.  If something
> unforeseen happens late in the cycle to delay the release, its also
> important that we can get some sort of steering committee agreement on
> what to do so we don't have some sort of evil gcc offspring as happened
> once before.

Once again - GCC development and release planning doesn't work this way.
But instead you (and me and others) are supposed to make the release "happen"
by fixing bugs and fulfilling the release criteria.  A "date" wasn't a
release criteria
in the past and I don't think it should become one (in fact, the only
time a release
"date" would be a welcome criteria is if the release is a throw-away
and releasing
would allow us to work on next stage1 again).

> Thats something I don't expect to happen, but will have to
> visit as risk management before the final decision is made.   My hope is
> that it'll be in good enough shape by mid january that slippage by that
> much is unlikely and isn't an issue.
>
> Does this seem like a reasonable schedule?  Can we set the criteria for
> what a final release would look like?  We're committed to applying
> engineering resource to help make it happen.

Again, if you commit enough engineering resource to make it happen, then I'm
sure we'll make your timeline.  If not, well - shit happens?.  At
least I wouldn't
like to see us to be locked in into some agreement around release dates.  After
all this doesn't work for glibc (ok, _that_ probably works for RedHat)
or the kernel
either.

Just my $1000M dollars.

Again - please don't branch without releasing.
(repeat 1000 times).

Thanks,
Richard.

Re: GCC 4.3 release schedule

[Andrew MacLeod]

Richard Guenther wrote:
> On 10/26/07, Andrew MacLeod <amacleod@redhat.com> wrote:
>   
>> Now that GCC is in stage 4.3, I think we'd all be in agreement that it
>> would be nice to keep this stage short and get a release out.
>>
>> We are interested in using 4.3 as the system compiler in Fedora 9, and
>> as such, we'd like to nail down some time lines and requirements with
>> release management and the steering committee.
>>     
>
> Of course it doesn't work like this ;)
>
>   
we can at least make projected dates known so we have something firmer 
than "at some point in the future" :-)
>> The timelines involved are something like this:  (clearly anything
>> earlier would be great :-)
>>
>> Nov 14th - we'd like to start building F9 with a 4.3 compiler. Ideally
>> we'd have a branch cut no later than that and starting to stabilize
>> without much new code going in.
>>     
>
> I oppose to cut a branch without immediately releasing 4.3.0.  This just
> doesn't work - just look at the history.  I also think that Nov 14th is _very_
> optimistic (I personally was thinking about a (early) Q1 release).
>
>   

I got the impression from marks latest note that he was planing to cut a 
4.3 branch when we got down to 100 P1s.

>We're still in Stage 3 for GCC 4.3.  As before, I think a reasonable
>target for creating the release branch is less than 100 open
>regressions. 


This was where I was going with the nov 14th date as a latest target.  
So you are saying we shouldn't branch at this point? 

I'd like to see some stabilization... Ie, not hunks of new functionality. 

Early Q1 for 4.3.0 works for us for a release. I had no idea any one 
else cared when 4.3 goes out.


> Note that we are building what-becomes-openSUSE 11.0 with current trunk
> in parallel to 4.2 at the moment, switching to 4.3 is in the next weeks
> (unless I get pushed back again ;)).
>
>   
It would be excellent to have both openSUSE and fedora pounding on 4.3 
at the same time.
>> Dec 14th - viability decision on using 4.3 as the F9 compiler.  There is
>> a window here as late as Jan 14th, but the opinions will start forming
>> in Dec. There shouldn't be any ABI changes from this point on.
>> Feb 29th - Optimistic target date for a 4.3 release.  can slip as much
>> as a  month,  but clearly the earlier the release happens the better.
>>     
>
> If we branch too early I bet we will not make even the Feb 29th date.
>
> How does targeting a release around Feb 1st sound (that is, without
> branching before, a RC1 on Feb 1st, the release including branching
> a week or two later)?  It looks like that would work for your constraints.
>
>   
having a RC by the beginning of february seems reasonable to me  :-) mid 
january would be even better.
>> I don't recall seeing any other timeline requirements, does this seem
>> like a reasonable target schedule? Once a decision is made to use 4.3 by
>> mid-jan, it becomes very difficult to back out if something happens to
>> the release date, so it becomes quite important that the final criteria
>> is well understood by then and appears reachable.  If something
>> unforeseen happens late in the cycle to delay the release, its also
>> important that we can get some sort of steering committee agreement on
>> what to do so we don't have some sort of evil gcc offspring as happened
>> once before.
>>     
>
> Once again - GCC development and release planning doesn't work this way.
> But instead you (and me and others) are supposed to make the release "happen"
> by fixing bugs and fulfilling the release criteria.  A "date" wasn't a
> release criteria
> in the past and I don't think it should become one (in fact, the only
> time a release
> "date" would be a welcome criteria is if the release is a throw-away
> and releasing
> would allow us to work on next stage1 again).
>
>   
I understand, but without some sort of date guideline, you cant plan on 
using as yet unreleased compiler. It buggers up the release cycle. I 
don't propose the date as a hard release criteria, but as a target that 
we'd like to work towards. So what I'd like to see is what the final 
release requirements are, and then along they way we can monitor the 
current status and if we are falling behind,  can try to apply more 
resource to it to get back on track. 
>> Thats something I don't expect to happen, but will have to
>> visit as risk management before the final decision is made.   My hope is
>> that it'll be in good enough shape by mid january that slippage by that
>> much is unlikely and isn't an issue.
>>
>> Does this seem like a reasonable schedule?  Can we set the criteria for
>> what a final release would look like?  We're committed to applying
>> engineering resource to help make it happen.
>>     
>
> Again, if you commit enough engineering resource to make it happen, then I'm
> sure we'll make your timeline.  If not, well - shit happens?.  At
> least I wouldn't
> like to see us to be locked in into some agreement around release dates.  After
> all this doesn't work for glibc (ok, _that_ probably works for RedHat)
> or the kernel
> either.
>
>   
Right. so I'm not looking to lock into Feb 29th as a rock hard release 
date, but I would like to see the project agree that it would be good to 
target releasing on a specific date and work towards that with dated 
milestones. if we are ready earlier, awesome, if we're later,  shit does 
happen, but it would be good to have a date in mind people can focus on. 
Its easier for other projects to work with you if you at least have a 
schedule date they can use.

As you say, enough engineering resource is likely to make it happen, but 
projected dates give external groups warmer fuzzies and makes it easier 
to allocate engineering resource.

So lets see, the dates you gave were targetting RC1 for gcc4.3.0 say 
Feb4 (giving us the weekend :-) and the full release say 2 weeks later, 
Feb 18th.  (as target dates :-) Anyone think we can pull these dates in 
at all?

do we actually have criteria for what is required to reach RC1? I would 
like to see something.  


Andrew

Re: GCC 4.3 release schedule

[Richard Guenther]

On 10/26/07, Andrew MacLeod <amacleod@redhat.com> wrote:
> Richard Guenther wrote:
> > On 10/26/07, Andrew MacLeod <amacleod@redhat.com> wrote:
> >>
> >> Nov 14th - we'd like to start building F9 with a 4.3 compiler. Ideally
> >> we'd have a branch cut no later than that and starting to stabilize
> >> without much new code going in.
> >>
> >
> > I oppose to cut a branch without immediately releasing 4.3.0.  This just
> > doesn't work - just look at the history.  I also think that Nov 14th is _very_
> > optimistic (I personally was thinking about a (early) Q1 release).
> >
> >
>
> I got the impression from marks latest note that he was planing to cut a
> 4.3 branch when we got down to 100 P1s.
>
> >We're still in Stage 3 for GCC 4.3.  As before, I think a reasonable
> >target for creating the release branch is less than 100 open
> >regressions.
>
>
> This was where I was going with the nov 14th date as a latest target.
> So you are saying we shouldn't branch at this point?

Yes.  While I saw Marks status report I also saw us running away from
completing the 4.2.0 release into stage1 after the branch was cut.

If we think 4.3.0 is ready at the point we reach 100 open regressions
then we should release it.  There is no point in branching but not
releasing.  If we don't think 4.3.0 is ready at that point, then the 100
open regressions is the wrong metric.  (I'd rather use zero P1 bugs
as metric)

Given that both Novell and RedHat want to use 4.3 for their next
community release I think working towards the release and branching
and releasing at the same point will work out.

> I'd like to see some stabilization... Ie, not hunks of new functionality.

I agree.  There seem to be still some "late features" going in while
I'd rather would like people to spend their time on fixing bugs ...
(but it doesn't work that way ;)).  But technically stage3 is bugfixes
and documentation only - we just need to enforce this more strictly.

> Early Q1 for 4.3.0 works for us for a release. I had no idea any one
> else cared when 4.3 goes out.

Well, I'm pretty sure that we make the Q1 deadline, so I didn't bother
too much to try to put it in stone ;)

> > Note that we are building what-becomes-openSUSE 11.0 with current trunk
> > in parallel to 4.2 at the moment, switching to 4.3 is in the next weeks
> > (unless I get pushed back again ;)).
> >
> >
> It would be excellent to have both openSUSE and fedora pounding on 4.3
> at the same time.

Yes.  I think Ubuntu is on track for 4.3 as well, most likely Debian, too.

> >> Dec 14th - viability decision on using 4.3 as the F9 compiler.  There is
> >> a window here as late as Jan 14th, but the opinions will start forming
> >> in Dec. There shouldn't be any ABI changes from this point on.
> >> Feb 29th - Optimistic target date for a 4.3 release.  can slip as much
> >> as a  month,  but clearly the earlier the release happens the better.
> >>
> >
> > If we branch too early I bet we will not make even the Feb 29th date.
> >
> > How does targeting a release around Feb 1st sound (that is, without
> > branching before, a RC1 on Feb 1st, the release including branching
> > a week or two later)?  It looks like that would work for your constraints.
> >
> >
> having a RC by the beginning of february seems reasonable to me  :-) mid
> january would be even better.

Yeah - though I expect the usual holidays lack-of-interest.

> >> I don't recall seeing any other timeline requirements, does this seem
> >> like a reasonable target schedule? Once a decision is made to use 4.3 by
> >> mid-jan, it becomes very difficult to back out if something happens to
> >> the release date, so it becomes quite important that the final criteria
> >> is well understood by then and appears reachable.  If something
> >> unforeseen happens late in the cycle to delay the release, its also
> >> important that we can get some sort of steering committee agreement on
> >> what to do so we don't have some sort of evil gcc offspring as happened
> >> once before.
> >>
> >
> > Once again - GCC development and release planning doesn't work this way.
> > But instead you (and me and others) are supposed to make the release "happen"
> > by fixing bugs and fulfilling the release criteria.  A "date" wasn't a
> > release criteria
> > in the past and I don't think it should become one (in fact, the only
> > time a release
> > "date" would be a welcome criteria is if the release is a throw-away
> > and releasing
> > would allow us to work on next stage1 again).
> >
> >
> I understand, but without some sort of date guideline, you cant plan on
> using as yet unreleased compiler. It buggers up the release cycle. I
> don't propose the date as a hard release criteria, but as a target that
> we'd like to work towards. So what I'd like to see is what the final
> release requirements are, and then along they way we can monitor the
> current status and if we are falling behind,  can try to apply more
> resource to it to get back on track.
> >> Thats something I don't expect to happen, but will have to
> >> visit as risk management before the final decision is made.   My hope is
> >> that it'll be in good enough shape by mid january that slippage by that
> >> much is unlikely and isn't an issue.
> >>
> >> Does this seem like a reasonable schedule?  Can we set the criteria for
> >> what a final release would look like?  We're committed to applying
> >> engineering resource to help make it happen.
> >>
> >
> > Again, if you commit enough engineering resource to make it happen, then I'm
> > sure we'll make your timeline.  If not, well - shit happens?.  At
> > least I wouldn't
> > like to see us to be locked in into some agreement around release dates.  After
> > all this doesn't work for glibc (ok, _that_ probably works for RedHat)
> > or the kernel
> > either.
> >
> >
> Right. so I'm not looking to lock into Feb 29th as a rock hard release
> date, but I would like to see the project agree that it would be good to
> target releasing on a specific date and work towards that with dated
> milestones. if we are ready earlier, awesome, if we're later,  shit does
> happen, but it would be good to have a date in mind people can focus on.
> Its easier for other projects to work with you if you at least have a
> schedule date they can use.
>
> As you say, enough engineering resource is likely to make it happen, but
> projected dates give external groups warmer fuzzies and makes it easier
> to allocate engineering resource.

But ...

> So lets see, the dates you gave were targetting RC1 for gcc4.3.0 say
> Feb4 (giving us the weekend :-) and the full release say 2 weeks later,
> Feb 18th.  (as target dates :-) Anyone think we can pull these dates in
> at all?
>
> do we actually have criteria for what is required to reach RC1? I would
> like to see something.

... when we think it's ready.  It doesn't help anyone to declare victory
and release 4.3.0 when it still miscompiles the kernel (not that I know
if it does).  Warm fuzzyness for PMs put aside.

Richard.

Re: GCC 4.3 release schedule

[Dennis Clarke]

> On 10/26/07, Andrew MacLeod <amacleod@redhat.com> wrote:
>> Richard Guenther wrote:
>> > On 10/26/07, Andrew MacLeod <amacleod@redhat.com> wrote:
>> >>

>
> ... when we think it's ready.  It doesn't help anyone to declare victory
> and release 4.3.0 when it still miscompiles the kernel (not that I know
> if it does).  Warm fuzzyness for PMs put aside.

At the risk of annoying you Red Hat Linux guys ( and Linux people in general
) you may be surprised to hear that there are problems for UNIX(tm) users
out there.  Now I have tried and failed to get a successful bootstrap build
of GCC 4.2.2 on Solaris 8 ( Sparc or x86 ) and on Solaris 10. When I look at
the Build status page I see no one has posted a result there for GCC 4.2.2 :

  Please see : http://gcc.gnu.org/gcc-4.2/buildstat.html

I was able to get a decent build with GCC 4.2.1 however :

     And see : http://gcc.gnu.org/ml/gcc-testresults/2007-08/msg00318.html

Exact same machine with exact same environment can not build GCC 4.2.2.

Now then, you seem to be discussing GCC 4.3 when GCC 4.2.x still does not
build correctly on a highly standards compliant UNIX platform.  Am I reading
this correctly ?  If not .. then please educate me if you can. I would like
to at least see GCC 4.2.2 bootstrap out of the box before flailing forwards
to GCC 4.3.x.

-
Dennis Clarke

Re: GCC 4.3 release schedule

[Richard Guenther]

On 10/26/07, Dennis Clarke <dclarke@blastwave.org> wrote:
>
> > On 10/26/07, Andrew MacLeod <amacleod@redhat.com> wrote:
> >> Richard Guenther wrote:
> >> > On 10/26/07, Andrew MacLeod <amacleod@redhat.com> wrote:
> >> >>
>
> >
> > ... when we think it's ready.  It doesn't help anyone to declare victory
> > and release 4.3.0 when it still miscompiles the kernel (not that I know
> > if it does).  Warm fuzzyness for PMs put aside.
>
> At the risk of annoying you Red Hat Linux guys ( and Linux people in general
> ) you may be surprised to hear that there are problems for UNIX(tm) users
> out there.  Now I have tried and failed to get a successful bootstrap build
> of GCC 4.2.2 on Solaris 8 ( Sparc or x86 ) and on Solaris 10. When I look at
> the Build status page I see no one has posted a result there for GCC 4.2.2 :
>
>   Please see : http://gcc.gnu.org/gcc-4.2/buildstat.html
>
> I was able to get a decent build with GCC 4.2.1 however :
>
>      And see : http://gcc.gnu.org/ml/gcc-testresults/2007-08/msg00318.html
>
> Exact same machine with exact same environment can not build GCC 4.2.2.
>
> Now then, you seem to be discussing GCC 4.3 when GCC 4.2.x still does not
> build correctly on a highly standards compliant UNIX platform.  Am I reading
> this correctly ?

Yes.  This is because the interest in 4.2.x is much lower than in 4.3.0
right now.

> If not .. then please educate me if you can. I would like
> to at least see GCC 4.2.2 bootstrap out of the box before flailing forwards
> to GCC 4.3.x.

Patches welcome.  Certainly there are targets that are less maintained
(and tested) than the *-linux targets.  But without infinite resources
we cannot do anything about this.  Thus, in the case of Solaris - talk to Sun.

Richard.

Re: GCC 4.3 release schedule

[Dennis Clarke]

> On 10/26/07, Dennis Clarke <dclarke@blastwave.org> wrote:
>>On 10/26/07, Andrew MacLeod <amacleod@redhat.com> wrote:
>> >> Richard Guenther wrote:
>> >> > On 10/26/07, Andrew MacLeod <amacleod@redhat.com> wrote:
>> >> >>
>>
>> >
>> > ... when we think it's ready.  It doesn't help anyone to declare victory
>> > and release 4.3.0 when it still miscompiles the kernel (not that I know
>> > if it does).  Warm fuzzyness for PMs put aside.
>>
>> At the risk of annoying you Red Hat Linux guys ( and Linux people in
>> general
>> ) you may be surprised to hear that there are problems for UNIX(tm) users
>> out there.  Now I have tried and failed to get a successful bootstrap
>> build
>> of GCC 4.2.2 on Solaris 8 ( Sparc or x86 ) and on Solaris 10. When I look
>> at
>> the Build status page I see no one has posted a result there for GCC 4.2.2
>> :
>>
>>   Please see : http://gcc.gnu.org/gcc-4.2/buildstat.html
>>
>> I was able to get a decent build with GCC 4.2.1 however :
>>
>>      And see : http://gcc.gnu.org/ml/gcc-testresults/2007-08/msg00318.html
>>
>> Exact same machine with exact same environment can not build GCC 4.2.2.
>>
>> Now then, you seem to be discussing GCC 4.3 when GCC 4.2.x still does not
>> build correctly on a highly standards compliant UNIX platform.  Am I
>> reading this correctly ?
>
> Yes.  This is because the interest in 4.2.x is much lower than in 4.3.0
> right now.

  Everyone wants next years car models in the late fall. I understand that
only too well. I'm a tad more interested in quality results however as
opposed to a shiney new sports car where the brakes don't work.

  I hate car analogies .. but they often work. Sorry.

>> If not .. then please educate me if you can. I would like
>> to at least see GCC 4.2.2 bootstrap out of the box before flailing
>> forwards
>> to GCC 4.3.x.
>
> Patches welcome.  Certainly there are targets that are less maintained
> (and tested) than the *-linux targets.  But without infinite resources
> we cannot do anything about this.

  I can relate.  I really can.

> Thus, in the case of Solaris - talk to Sun.

I think that the rage inside Sun is Studio 12 and Studio 11 compilers which
are, within reason, vastly superior to GCC.  Then again we do not have the
source code ( yet ) but we do have the sources to OpenSolaris. One would
think that after some two years of the OpenSolaris project we would be able
to build the OS with GCC and some people have tried :

  http://www.opensolaris.org/os/project/gccfss-on/

I have not tried that myself.

If one uses the free Studio 12 compiler tools from Sun then you can build
the whole OS ( big chunks at least ) quite neatly.  I have done that so many
times it is just silly :

  http://www.blastwave.org/articles/BLS-0050/index.html

The Indiana project being headed up by Ian Murdock ( the ian in Debian )
will make big changes in the Solaris landscape and really we need to stop
thinking about Sun corporate and start looking to the extended OpenSolaris
community. Guys like me ( and Blastwave people in general ) are not on the
Sun payroll.  Conversely Red Hat has paid people in the GCC maillists.  I
have my own reasons to pour efforts into GCC and one of them is simply that
*everything* in the OS should be open sourced and *everything* that a person
uses to build it should be open sourced. I think that is the key concept
behind the FSF and the Linux community in general.  It is also why I pour my
heart and guts into Blastwave.org to ensure that people have access to open
source software in a classically/traditionally closed off proprietary
operating system.  I think that project Indiana will blow the doors off
those old concepts.

In any case .. I have my reasons to want a nice clean GCC 4.2.2 for
Solaris/OpenSolaris users and my open sourcey intentions are all within
reason.

Patches are always welcome indeed.

Dennis Clarke

Re: GCC 4.3 release schedule

[Eric Botcazou]

> When I look at the Build status page I see no one has posted a result
> there for GCC 4.2.2 :
>
>   Please see : http://gcc.gnu.org/gcc-4.2/buildstat.html

Here are a couple of posts by Kaveh:
  http://gcc.gnu.org/ml/gcc-testresults/2007-10/msg00388.html
  http://gcc.gnu.org/ml/gcc-testresults/2007-10/msg00390.html

They are more noisy than usual because of -fpic/-fPIC testing.

-- 
Eric Botcazou

Re: GCC 4.3 release schedule

[Dennis Clarke]

>> When I look at the Build status page I see no one has posted a result
>> there for GCC 4.2.2 :
>>
>>   Please see : http://gcc.gnu.org/gcc-4.2/buildstat.html
>
> Here are a couple of posts by Kaveh:
>   http://gcc.gnu.org/ml/gcc-testresults/2007-10/msg00388.html
>   http://gcc.gnu.org/ml/gcc-testresults/2007-10/msg00390.html
>
> They are more noisy than usual because of -fpic/-fPIC testing.
>

  Oooh .. thank you very much!

  I can handle the noise no problem and I am happy to see these results. Why
isn't the main page for build reports updated ? It *looks* like no one (
me too ) is getting clean builds.

Dennis

Re: GCC 4.3 release schedule

[Eric Botcazou]

> Why isn't the main page for build reports updated ?

Will do.

> It *looks* like no one ( me too ) is getting clean builds.

The GCC 4.2.x compiler is in pretty good shape on SPARC/Solaris, modulo the 
libgomp problems on Solaris 10 with the Sun tools.  You need to use the GNU 
tools if you care about OpenMP on Solaris 10.

-- 
Eric Botcazou

Re: GCC 4.3 release schedule

[Dennis Clarke]

>> Why isn't the main page for build reports updated ?
>
> Will do.
>
>> It *looks* like no one ( me too ) is getting clean builds.
>
> The GCC 4.2.x compiler is in pretty good shape on SPARC/Solaris, modulo the
> libgomp problems on Solaris 10 with the Sun tools.  You need to use the GNU
> tools if you care about OpenMP on Solaris 10.

I think the problem is that I am using Sun ONE Studio 8 on Solaris 8 to
build. My assumption here is that once GCC runs well on Solaris 8 Sparc v7
then it will run on any furture release of either Solaris or Sparc CPU
hardware. At least that is what the ABI says and it works.

The issue that I ran into was related to the stage 2 GCC compiler binary
getting CFLAGS options that were intended for the Studio 8 cc compiler. For
some obscure reason ( to me ) I am able to get a bootstrap of GCC 4.21. on
the same machine with that same environment vars in place but not with GCC
4.2.2.

I'll start digging .. again.

Dennis

Re: GCC 4.3 release schedule

[Janis Johnson]

On Fri, 2007-10-26 at 19:54 +0200, Eric Botcazou wrote:
> > When I look at the Build status page I see no one has posted a result
> > there for GCC 4.2.2 :
> >
> >   Please see : http://gcc.gnu.org/gcc-4.2/buildstat.html
> 
> Here are a couple of posts by Kaveh:
>   http://gcc.gnu.org/ml/gcc-testresults/2007-10/msg00388.html
>   http://gcc.gnu.org/ml/gcc-testresults/2007-10/msg00390.html
> 
> They are more noisy than usual because of -fpic/-fPIC testing.

I added more entries to gcc-4.2/buildstat.html.

Bootstrap and test results for 4.2.2:

  i686-pc-linux-gnu (Slackware 12.0, kernel 2.6.22, glibc 2.5)

Test results for 4.2.2:

  hppa2.0w-hp-hpux11.11
  hppa64-hp-hpux11.11
  hppa-unknown-linux-gnu
  i386-unknown-freebsd5.5
  i686-pc-linux-gnu (2)
  ia64-unknown-linux-gnu
  s390-ibm-linux-gnu
  s390x-ibm-linux-gnu
  sparc-sun-solaris2.8
  sparc64-unknown-linux-gnu
  x86_64-unknown-linux-gnu (2)

Sorry for the delay.

Janis

Re: GCC 4.3 release schedule

[Eric Botcazou]

> I added more entries to gcc-4.2/buildstat.html.
>
> Bootstrap and test results for 4.2.2:
>
>   i686-pc-linux-gnu (Slackware 12.0, kernel 2.6.22, glibc 2.5)
>
> Test results for 4.2.2:
>
>   hppa2.0w-hp-hpux11.11
>   hppa64-hp-hpux11.11
>   hppa-unknown-linux-gnu
>   i386-unknown-freebsd5.5
>   i686-pc-linux-gnu (2)
>   ia64-unknown-linux-gnu
>   s390-ibm-linux-gnu
>   s390x-ibm-linux-gnu
>   sparc-sun-solaris2.8
>   sparc64-unknown-linux-gnu
>   x86_64-unknown-linux-gnu (2)

Thanks!

-- 
Eric Botcazou

Re: GCC 4.3 release schedule

[Martin Michlmayr]

* Richard Guenther <richard.guenther@gmail.com> [2007-10-26 17:51]:
> Yes.  I think Ubuntu is on track for 4.3 as well, most likely Debian, too.

I've been testing 4.3 on a number of architectures Debian supports and
filings bugs.  There are still many that haven't been resolved yet.
Of course, gcc 4.3 also introduces build failures in about 550
packages (mostly due to the C++ header inclusion clean-up) and these
need to be fixed too.  However, Debian's next release is further away
than SUSE's and Fedora's so there should be enough time to fix these
issues.
-- 
Martin Michlmayr
http://www.cyrius.com/

Re: GCC 4.3 release schedule

[Joe Buck]

On Fri, Oct 26, 2007 at 08:20:02PM +0200, Martin Michlmayr wrote:
> * Richard Guenther <richard.guenther@gmail.com> [2007-10-26 17:51]:
> > Yes.  I think Ubuntu is on track for 4.3 as well, most likely Debian, too.
> 
> I've been testing 4.3 on a number of architectures Debian supports and
> filings bugs.  There are still many that haven't been resolved yet.
> Of course, gcc 4.3 also introduces build failures in about 550
> packages (mostly due to the C++ header inclusion clean-up) and these
> need to be fixed too.  However, Debian's next release is further away
> than SUSE's and Fedora's so there should be enough time to fix these
> issues.

You might want to hold off on investing the work in fixing those 550
packages, because I think it's premature to consider the header "cleanup"
final.

Can you estimate how many of the broken packages use <ext/hash_set> or
<ext/hash_map>?

Re: GCC 4.3 release schedule

[Martin Michlmayr]

* Joe Buck <Joe.Buck@synopsys.COM> [2007-10-26 11:44]:
> You might want to hold off on investing the work in fixing those 550
> packages, because I think it's premature to consider the header
> "cleanup" final.
> 
> Can you estimate how many of the broken packages use <ext/hash_set>
> or <ext/hash_map>?

Sorry I wasn't being clear.  This is without the recent removal of
some backward-compability headers.  The errors I'm talking about are
due to the fix for PR28080 and similar and those changes will be in
4.3.
-- 
Martin Michlmayr
http://www.cyrius.com/

Re: GCC 4.3 release schedule

[Joe Buck]

On Fri, Oct 26, 2007 at 10:28:35PM +0200, Martin Michlmayr wrote:
> * Joe Buck <Joe.Buck@synopsys.COM> [2007-10-26 11:44]:
> > You might want to hold off on investing the work in fixing those 550
> > packages, because I think it's premature to consider the header
> > "cleanup" final.
> > 
> > Can you estimate how many of the broken packages use <ext/hash_set>
> > or <ext/hash_map>?
> 
> Sorry I wasn't being clear.  This is without the recent removal of
> some backward-compability headers.  The errors I'm talking about are
> due to the fix for PR28080 and similar and those changes will be in
> 4.3.

OK.  Can you estimate how many packages use <ext/hash_map> or
<ext/hash_set>?

Re: GCC 4.3 release schedule

[Martin Michlmayr]

* Joe Buck <Joe.Buck@synopsys.COM> [2007-10-26 14:53]:
> Can you estimate how many packages use <ext/hash_map> or <ext/hash_set>?

Not easily because I backed out those changes.
-- 
Martin Michlmayr
http://www.cyrius.com/

Re: GCC 4.3 release schedule

[Matthias Klose]

Richard Guenther writes:
> On 10/26/07, Andrew MacLeod <amacleod@redhat.com> wrote:
> > > Note that we are building what-becomes-openSUSE 11.0 with current trunk
> > > in parallel to 4.2 at the moment, switching to 4.3 is in the next weeks
> > > (unless I get pushed back again ;)).
> > >
> > >
> > It would be excellent to have both openSUSE and fedora pounding on 4.3
> > at the same time.
> 
> Yes.  I think Ubuntu is on track for 4.3 as well, most likely Debian, too.

Ubuntu did plan the 2008 April release (8.04) with a compiler taken
from the 4.2 branch; the main repository is already fixed to build
with 4.3 and build tests are run regularily, so a change to 4.3 could
be considered. About 5% of the packages needed a change to build with
4.3 (most of them added C++ headers).

Debian's next release will be around fall 2008 (or later, when its
ready), considering 4.3 as the system compiler, hopefully for all 10+
architectures.

Both distributions do not rebuild the archive by default when changing
the compiler version, so the new compiler is only used for new package
uploads.

For previous releases APIs of runtime libraries were changed up to
close the release date. This makes it somewhat difficult to already
use a prerelease version of the compiler in the distribution (or all
packages uploaded between the compiler upload and the upload of a
fixed comiler need to be rebuilt, which might be difficult for the
slower Debian architectures). Would the GCC developers consider an
ABI/API freeze somehwat between beginning of stage3 and the release?

  Matthias

Re: GCC 4.3 release schedule

[Mark Mitchell]

Andrew MacLeod wrote:

> we can at least make projected dates known so we have something firmer
> than "at some point in the future" :-)

The canonical rule of project management is: "Features, Schedule, Cost:
Pick At Most 2." :-)  In other words, you can decide what features you
want and when you want them by -- but be prepared to pay for a vast
team.  Or, you can decide what you want to pay, and when you want it --
but be prepared to get whatever features are done by then with the team
you paid for.  In the case of GCC, it's worse than that since we're not
all interested in the same things, or being in any way centrally directed.

As RM, I try to take into account what I know about when distributors
will be applying effort, but I must absolutely avoid in any way tilting
the FSF release process towards the needs of one distributor, possibly
at the expense of another.  I don't think it's appropriate for us to set
a schedule tailored to any one distributor's needs -- and there are a
lot more distributors than just Red Hat and SuSE, so I'd say that even
if you were on the same schedule.  But, I certainly do think it's
helpful for a contributor to tell us when resources might be available
and I appreciate you sharing that information.

If you're interested in driving the release to a particular date, the
best thing you can do is to go clear out the P1s in bugzilla and then
bash out a few P2s.  (I've noticed Red Hat folks doing some of that
already, thanks!)  I'd imagine that the dates you want to hit would be
achievable if you, Jakub, Jason, etc. all work on issues.

I've found schedules for GCC to be very hard to predict.  As I said in
my status report, our practice has been to cut the release branch when
we reach 100 regressions, and release 2-4 months after that point,
depending on quality on the branch.  To be honest, I'd rather wait
longer to make the branch -- but there tends to be intense pressure in
the developer community to make a branch so we can get on to the next
round of major features.  In any case, after we make the branch, it's in
regression-only mode, so stability tends to be quite good, though
dot-zero releases are, after all, dot-zero releases.

Thanks,

-- 
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713

Re: GCC 4.3 release schedule

[David Daney]

Mark Mitchell wrote:
> As I said in
> my status report, our practice has been to cut the release branch when
> we reach 100 regressions, and release 2-4 months after that point,
> depending on quality on the branch.  To be honest, I'd rather wait
> longer to make the branch -- but there tends to be intense pressure in
> the developer community to make a branch so we can get on to the next
> round of major features.

I don't want to start a flame-fest, but perhaps we could reconsider the 
release-branching criteria.

As Richard indicated, some (including me) might prefer delaying the 
branch until we are much closer to the release.  It doesn't seem ideal 
to re-live the 4.2 schedule ad infinitum.

As for what the actual date for release should be, I have no preference.

David Daney

Re: GCC 4.3 release schedule

[Dennis Clarke]

> Mark Mitchell wrote:
>> As I said in
>> my status report, our practice has been to cut the release branch when
>> we reach 100 regressions, and release 2-4 months after that point,
>> depending on quality on the branch.  To be honest, I'd rather wait
>> longer to make the branch -- but there tends to be intense pressure in
>> the developer community to make a branch so we can get on to the next
>> round of major features.
>

   Is "correctness" a feature ?

   I would like to see a nice clean GCC 4.2.x before GCC 4.3.zero even gets
thought of.  Why would one simply branch towards the next release when
the previous one still needs some work?  To appease sales people and
developers making noises for features?

> I don't want to start a flame-fest, but perhaps we could reconsider the
> release-branching criteria.

  I will read intently.

Dennis Clarke

Re: GCC 4.3 release schedule

[Jason Merrill]

Dennis Clarke wrote:
>    Is "correctness" a feature ?

Yes, but not one that gets merged in during stage 1 :)

>    I would like to see a nice clean GCC 4.2.x before GCC 4.3.zero even gets
> thought of.  Why would one simply branch towards the next release when
> the previous one still needs some work?  To appease sales people and
> developers making noises for features?

Planning for 4.3.0 has no effect at all on the 4.2.x schedule.  People 
work on 4.2.x or not depending on their own priorities.  I've fixed a 
few bugs in 4.2 since the 4.2.2 release, and I fully expect there will 
be at least a 4.2.3 before 4.3.0 goes out.

Distributors are interested in a timely 4.3.0 because they'll be using 
whatever compiler they settle on for a long time and would like it to be 
up to date.  Sometimes some of the new features are important to support 
the needs of other parts of the system.

Jason

Re: GCC 4.3 release schedule

[Richard Guenther]

On 10/26/07, Mark Mitchell <mark@codesourcery.com> wrote:
>
> I've found schedules for GCC to be very hard to predict.  As I said in
> my status report, our practice has been to cut the release branch when
> we reach 100 regressions, and release 2-4 months after that point,
> depending on quality on the branch.  To be honest, I'd rather wait
> longer to make the branch -- but there tends to be intense pressure in
> the developer community to make a branch so we can get on to the next
> round of major features.  In any case, after we make the branch, it's in
> regression-only mode, so stability tends to be quite good, though
> dot-zero releases are, after all, dot-zero releases.

To jump in on the last fact - dot-zero releases are dot-zero releases - it
makes sense to expose the branch to wider testing by, at branching time,
exposing a dot-zero release to the public ;)

And I seriously dispute that branching and waiting has ever made the
branch of better quality just because we branched and waited.  Instead
the opposite is true - developer ressources are dragged away to work
on their stage1 projects (that is true for myself).

I'd rather take the make the dot-zero release approach while branching
and count on interested people fixing bugs on the branch after the
dot-zero release.  This way if nobody is interested on a particular
release series then we can declare the dot-zero release final - otherwise
we'd do more releases from the  branch anyway.

Which still leaves us with the problem of setting criteria for releasing a
dot-zero.  Being it 100 regressions or zero P1 bugs or whatever.  Early
testing certainly helps here (sofar we are doing build-testing only, but
I expect to put the built binaries in "production" soon), but there are
still serious problems with 4.3 at the moment, like sorting out the libstdc++
API mess.

Thanks,
Richard.

Re: GCC 4.3 release schedule

[Andrew MacLeod]

Mark Mitchell wrote:
> Andrew MacLeod wrote:
>
>   
>> we can at least make projected dates known so we have something firmer
>> than "at some point in the future" :-)
>>     
>
> As RM, I try to take into account what I know about when distributors
> will be applying effort, but I must absolutely avoid in any way tilting
> the FSF release process towards the needs of one distributor, possibly
> at the expense of another.  I don't think it's appropriate for us to set
> a schedule tailored to any one distributor's needs -- and there are a
> lot more distributors than just Red Hat and SuSE, so I'd say that even
> if you were on the same schedule.  But, I certainly do think it's
> helpful for a contributor to tell us when resources might be available
> and I appreciate you sharing that information.
>
>   

I'm not suggesting we tailor the schedule to a specific distributor, but 
I do think when we have useful information that a client of GCC will be 
choosing a release by $date, it might be worth considering how that fits 
into the current or future release schedules.  Fortunately we seem to 
have an alignment of the planets at the moment, so it doesn't appear it 
will be much of an issue for this release. we got lucky. 12 months ago, 
it might have actually been planned instead of luck  had fedora and suse 
said our plans are to be looking for a compiler in early Q3/2007 and 
then again in Q1/2008. And if other distributions provided approximate 
dates, we'd see where "ooo, look, 5 distributions will be looking for a 
compiler in Q1/2008.  perhaps we should try to arrange our schedule to 
have a release available then.  That means stage 1 goes to june, stage 2 
goes to mid september, and that should result in a release in late 
Q4/early Q1 which all those distributions will be interested in".  I 
think we'd see a lot of resource pumped into getting that release out.   
If the schedule had shown not more than 1 distribution was looking for a 
release until June of next year, perhaps we decide to delay things 
further to allow more development.

One of the reasons we sometimes languish in stage 3 is because a release 
is not interesting to enough parties. They end up spending their 
resource working on a future release which will be of interest to them, 
and stage 3 drags on.   I think our best bet at making stage 3 practical 
and short is to have enough interest in getting the release out.   And 
the reality of the situation is that you probably need a couple of 
distributions interested in it. It looks like thats the case with this 
release, and I am hopeful that we are going to have a reasonable stage 3 
and get a release out in a timely fashion. In the future, we can 
probably accomplish the same thing if we try to align a release date 
with interested parties.


> If you're interested in driving the release to a particular date, the
> best thing you can do is to go clear out the P1s in bugzilla and then
> bash out a few P2s.  (I've noticed Red Hat folks doing some of that
> already, thanks!)  I'd imagine that the dates you want to hit would be
> achievable if you, Jakub, Jason, etc. all work on issues.
>
>   
We do intend to do that, but its easier to get the resource assignments 
if we can say "gcc 4.3 is currently planned to be released on Feb 8th, 
but we need 25% of 3 developers for 3 months to help make sure".  It 
boils down to the same thing to you and me, but not to the other 
projects and people involved.  If we can set a trend like this, and we 
meet a couple of release dates accurately, we might be able to regularly 
get resource assigned to releases.


> I've found schedules for GCC to be very hard to predict.  As I said in
> my status report, our practice has been to cut the release branch when
> we reach 100 regressions, and release 2-4 months after that point,
> depending on quality on the branch.  To be honest, I'd rather wait
> longer to make the branch -- but there tends to be intense pressure in
> the developer community to make a branch so we can get on to the next
> round of major features.  In any case, after we make the branch, it's in
> regression-only mode, so stability tends to be quite good, though
> dot-zero releases are, after all, dot-zero releases.
>   

Yeah, I'm not so concerned about whether we cut a release branch early 
or not. Cutting a branch, or saying mainline is regression only, or 
whatever mechanism boils down to the same thing. The key is to get 
people working on it because the release is needed.   If the release is 
needed, its likely to be needed by a certain date. In the past our dates 
have been set fairly arbitrarily by ourselves right?  If our date 
coincides with dates that others actually need the compiler by, I bet we 
see a lot less slippage.  I just suggest we try it, it really not that 
big a change in my view, and I think it may solve come of our problem in 
getting focus on releases.  I have no doubt that if we set a date in 
early february, we'll probably make it.  And I'd like to see if we can 
reproduce that in the future.

Just my opinion :-)

Andrew

Re: GCC 4.3 release schedule

[Andrew Pinski]

On 10/26/07, Andrew MacLeod <amacleod@redhat.com> wrote:
>
> Now that GCC is in stage 4.3, I think we'd all be in agreement that it
> would be nice to keep this stage short and get a release out.

Let me suggest something which is going sound a little crazy.

Create a beta that is released now and then release one once (or
twice) a month until we release 4.3.  This is seperate from a release
candidate and the snapshot.  The beta is get attention from some folks
that would not have used the snapshot before.  It might get say some
Fortran developers or some interesting C++ developers using it.  We
can write a little thing up on why we are doing the beta, C++0x
support, more fortran support and vectorizer turned on by default at
-O3.

-- Pinski

Re: GCC 4.3 release schedule

[Andrew MacLeod]

Andrew Pinski wrote:
> On 10/26/07, Andrew MacLeod <amacleod@redhat.com> wrote:
>   
>> Now that GCC is in stage 4.3, I think we'd all be in agreement that it
>> would be nice to keep this stage short and get a release out.
>>     
>
> Let me suggest something which is going sound a little crazy.
>
> Create a beta that is released now and then release one once (or
> twice) a month until we release 4.3.  This is seperate from a release
> candidate and the snapshot.  The beta is get attention from some folks
> that would not have used the snapshot before.  It might get say some
> Fortran developers or some interesting C++ developers using it.  We
> can write a little thing up on why we are doing the beta, C++0x
> support, more fortran support and vectorizer turned on by default at
> -O3.
>   
Im not sure what that buys us. All the critical users are involved in 
creating the RC's. If we want others to use it, let them use the first 
RC and call it beta 1 instead/as well.

 I think most casual users will do the same thing I do for a linux 
distro, simply wait for the release so you are less likely to have to 
deal with instabilities.

Andrew

Re: GCC 4.3 release schedule

[Jack Lloyd]

On Thu, Nov 01, 2007 at 09:50:00AM -0700, Andrew Pinski wrote:
> Create a beta that is released now and then release one once (or
> twice) a month until we release 4.3.  This is seperate from a release
> candidate and the snapshot.  The beta is get attention from some folks
> that would not have used the snapshot before.  It might get say some
> Fortran developers or some interesting C++ developers using it.  We
> can write a little thing up on why we are doing the beta, C++0x
> support, more fortran support and vectorizer turned on by default at
> -O3.

I would like this. It's common for snapshots to fail to build (at
least on my machines), which is definitely a discouragement from
trying them too often, and by the time the RCs hit it's way too late
to do much about any problems but file a bug and hope it gets fixed in
the next release.

-Jack

Re: GCC 4.3 release schedule

[Daniel Jacobowitz]

On Thu, Nov 01, 2007 at 01:55:04PM -0400, Jack Lloyd wrote:
> I would like this. It's common for snapshots to fail to build (at
> least on my machines), which is definitely a discouragement from
> trying them too often, and by the time the RCs hit it's way too late
> to do much about any problems but file a bug and hope it gets fixed in
> the next release.

Perhaps we should make a prerelease now and call it a Technology
Preview then... :-)

-- 
Daniel Jacobowitz
CodeSourcery

Re: GCC 4.3 release schedule

[Richard Guenther]

On 11/1/07, Daniel Jacobowitz <drow@false.org> wrote:
> On Thu, Nov 01, 2007 at 01:55:04PM -0400, Jack Lloyd wrote:
> > I would like this. It's common for snapshots to fail to build (at
> > least on my machines), which is definitely a discouragement from
> > trying them too often, and by the time the RCs hit it's way too late
> > to do much about any problems but file a bug and hope it gets fixed in
> > the next release.
>
> Perhaps we should make a prerelease now and call it a Technology
> Preview then... :-)

Well, there are installable gcc 4.3 builds for openSUSE available, and
I know of at least Debian packages in experimental.  I wouldn't be surprised
if Fedora also has gcc 4.3 packages ready.  So Technology Previews are
out there ;)

Richard.

Re: GCC 4.3 release schedule

[Gerald Pfeifer]

On Thu, 1 Nov 2007, Richard Guenther wrote:
> Well, there are installable gcc 4.3 builds for openSUSE available,
> and I know of at least Debian packages in experimental.  I wouldn't
> be surprised if Fedora also has gcc 4.3 packages ready.

FreeBSD also has packages (and of course the source ports) available. ;-)

Gerald

Re: GCC 4.3 release schedule

[Andrew MacLeod]

Jack Lloyd wrote:
> On Thu, Nov 01, 2007 at 09:50:00AM -0700, Andrew Pinski wrote:
>   
>> Create a beta that is released now and then release one once (or
>> twice) a month until we release 4.3.  This is seperate from a release
>> candidate and the snapshot.  The beta is get attention from some folks
>> that would not have used the snapshot before.  It might get say some
>> Fortran developers or some interesting C++ developers using it.  We
>> can write a little thing up on why we are doing the beta, C++0x
>> support, more fortran support and vectorizer turned on by default at
>> -O3.
>>     
>
> I would like this. It's common for snapshots to fail to build (at
> least on my machines), which is definitely a discouragement from
> trying them too often, and by the time the RCs hit it's way too late
> to do much about any problems but file a bug and hope it gets fixed in
> the next release.
>   
I'd suggest we are close to a beta state right now, so if it fails to 
build there ought to be a high priority PR opened.

Andrew