Re: DFA scheduler patch for review

[Geoff Keating <geoffk at geoffk dot org>]

> Date: Mon, 29 Apr 2002 11:38:49 -0700 (PDT)
> Cc: vmakarov@cygnus.com, gcc-patches@gcc.gnu.org, mark@codesourcery.com
> From: "David S. Miller" <davem@redhat.com>
> 
>    From: Geoff Keating <geoffk@geoffk.org>
>    Date: Mon, 29 Apr 2002 11:46:24 -0700
>    
>    Well, it's been several days, no-one has commented on the patch, and
>    I've reviewed it and I think it is OK.  So, please commit it.
>    
> YIKES!!!

Why so surprised?  This is how it's supposed to happen.

> I think we should consider stabilization of the mainline, in
> particular whether we are going to do that, before beginning to
> install the big changes.
> 
> The more we diverge the mainline before doing a quick stabilization,
> the more work that stabilization is going to be.

We're now two days before the last-announced deadline for branch
merges.  It may take Vlad that long to double-check everything and
commit.  I don't think it's reasonable to wait any longer.

It's not reasonable to try to keep the mainline frozen when there is a
branch.  The whole point of having a branch is so that the mainline
can diverge.

I don't think the mainline is so unstable that work should stop on it
until it's fixed.  The three targets the regression tester uses are
all building and showing no regressions.

> Another note, most of us aren't commenting on anything wrt.  the
> mainline because most of us are going for 30 hour stretches fixing
> bugs for 3.1!

It was part of the original timeline that at the point the new GCC is
released, the mainline is closed to large merges, and therefore _all_
large merges happen while some people are working on a release.  I'm
not sure that this is a good idea, but it was also part of the
original timeline proposal that we'd try the timeline for a while and
see how it went.  Mark said he was considering a change to this but I
haven't heard anything about it since then, and I don't believe he had
intended to _prevent_ large changes while a release is being prepared
on a branch, just allow those who were working on the release some
time afterwards to get their own merges done (which sounds like a good
idea to me).

-- 
- Geoffrey Keating <geoffk@geoffk.org> <geoffk@redhat.com>