This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: GCC 4.3 release schedule
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.