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 [EMAIL PROTECTED] (916) 791-8304
