Re: DFA scheduler patch for review

[Mark Mitchell <mark at codesourcery dot com>]

> 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).

Right.

In fact, the SC has approved (well, voting sort of trailed off, but
we got a clear majority of those who voted, so I think it's safe to
say the SC approved) the following change to the schedule:

- The mainline stage one development (i.e., major chaos-causing changes)
  will end one month after the release.  Then, things will proceed on
  a two-month schedule from there on both the release and mainline;
  there will be a release one month, and the end of a development stage
  the next month, and so forth.

  Thus, we're now on a (nominally) 7-month cycle.  Stage one on the
  mainline is 3 months long; long enough to let people who are working
  hard on the branch (thanks!) have some fun on the mainline too.

Now is indeed exactly the time to be doing wild stuff on the trunk, and
I have no complaint about putting in the DFA patches.  They've been
reviewed by an appropriate reviewer.

It is, however, true that -- as David M. points out -- we should work
hard to stabilize the mainline *before* we branch.  In fact, after stage
one closes, we're supposed to work exclusively on bug-fixes.  Now that
I have more time to work on GCC releases, I'll be doing some
bug-fixing -- and I'll be leaning on everyone else to do it too.

Part of the problem we're having now is that there were a lot of *known*
regressions -- i.e, stuff in GNATS -- that we didn't start working on
until two weeks ago.  Not good.

The message is this: it's fine to check things in now, but do be prepared
to stand behind your patches over this next release cycle.  If you don't,
there will be consequences -- I just don't know what they are yet. :-)

-- 
Mark Mitchell                mark@codesourcery.com
CodeSourcery, LLC            http://www.codesourcery.com