This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: GCC 4.1 Projects
Daniel Jacobowitz wrote:
The Stage 1 schedule looks full to me, and I'd like to see those patches
go in soon so that we can start shaking out the inevitable problems.
I'm much less worried about the long-term impact of Nathanael's patch;
if it breaks something, it will get fixed, and then that will be that.
But, that brief breakage might make things difficult for people putting
in things during Stage 1, or compound the problem of having an unstable
mainline.
I think that's not a useful criteria for scheduling decisions.
Let me be more concrete. Paolo Bonzini posted a patch to move
in-srcdir builds to a host subdirectory. This is a substantial build
infrastructure change, even though it will not affect a substantial
number of developers - assuming it works correctly. I consider it no
different "in kind" from Nathanael's changes. He can approve that; so
a system where he can't approve his own tested patch is one in which
you are overriding his judgement. ISTR that that is exactly what you
did not want to do with this scheduling exercise.
Nathanael's writeup conveyed to me that there were two parts of his
project: Part I and Part II. It sounded like Part II is not ready yet,
and in fact requires as-of-yet not reached consensus to be reached with
the Ada maintainers. I could have separated Part I into an early-stage
project, and that might have been a better decision; instead, I thought
it would be best to get this all done at once in a single effort later.
I disagree that I'm overriding Nathanael's judgement about his patch.
Or, at least, I partially disagree: I'm certainly not offerring any
negative opinion on his patch. I agree that I'm trying to control the
timing.
I do realize that this is a situation where people who try to be good
citizens could get penalized at the expense of people who aren't. I
would hope that maintainers should exercise discipline in that respect;
it's my feeling that those who submitted projects (like Nathanael)
should have an edge over others who pop up with big patches without
prior notice.
s/could/absolutely will/. It's a remarkably strong incentive not to
submit project proposals for 4.2.
Sadly, that's true, if people want to game the system. If we think
that's a big enough problem, we should just back away from this whole
idea of me trying to do any scheduling. I can't see how to do it, if we
don't trust the majority of the players. I guess I'm a little more
trusting than you, and think that the GCC community is pretty good at
building up a self-regulating culture, once there's sufficient buy-in
for an idea.
Part of what I didn't like about the way things worked before was that
I'd try to say "OK, let's move on to Stage 2", and I'd get a rash of
"but my really cool project is almost ready..." messages. I wanted to
provide some accountability; now, I feel more comfortable saying "OK,
but you didn't tell anyone about your project, so wait until the next
cycle." I think that gives people an incentive to be up-front about
what they're doing, which I think everyone agrees is desirable. If
maintainers decide just to check in patches anyhow, then maybe we've got
bigger problems.
(To be clear, the hypothetical defer-until-next-cycle message is
something I'd want to confer with appopriate maintainers about. I've
been trying to divest myself of responsibility for areas of the compiler
in which I'm not an expert; for example, just today I encouraged the
Fortran people to set their own release-branch policy, and during 4.0 I
encouraged language and backend maintainers to make similar decisions.
I intend to do that during 4.1 as well; if the Java people feel a
particular java-only patch is appropriate in Stage 3, I'm not going to
second-guess.)
I see less value in trying to schedule them in advance. Organizing
windows around particular projects makes sense, in an ongoing fashion
and as they become available. Pre-planning the windows assumes a lot
about the state of the tree at the time, esp. other projects that come
up during stage 1 development.
My mental model is that Stage 1 would ideally be a time for integrating
branches, rather than a time for development per se. Joseph's new C
parser is a great example; it was very thoroughly tested and completely
ready to go before Stage 1 started.
I'd like to think that the fact that I've expressed willingness to
reconsider Nathanael's patch would be encouraging to those who might try
to game the system. If I'm wrong about the risk level of Nathanael's
patch, then I made the wrong decision, and I'll fix it.
I'd like to see us let the process play out. It's hard if we start
second-guessing before we give it a try.
--
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com
(916) 791-8304