On Sun, Feb 27, 2005 at 03:56:26PM -0800, Mark Mitchell wrote: > Daniel Jacobowitz wrote: > >On Sun, Feb 27, 2005 at 02:57:05PM -0800, Mark Mitchell wrote: > > >Nathanael said it did not interfere with any of the other _projects_, > >not that it would be disjoint from all Stage 1 _patches_. > > Fair point. > > >>I would certainly prefer that you hold off until Stage 2, as indicated > >>by the documented I posted. > > > >Could you explain what benefits from waiting? None of the other large, > > The primary benefit is just reduced risk, as you suggest. > > 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. No offense intended to Paolo, of course! I picked a recent example. We're less than a week into stage 1, so I don't have much in the way of samples to draw on. > 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. I appreciate your effort here, especially for collecting and organizing the project proposals. The sense of "what's coming" is extremely interesting to me - and hopefully extremely useful to those more active in GCC development than I am. 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. And it assumes quite a lot about folks' estimates of their delivery dates, which I'd take with a grain of salt and a shot of vodka. It also encourages projects to be done out of HEAD. For some of these that makes sense, but for some of them it doesn't seem to. And projects which are pushed to stage 2 have less chance of breaking the tree in stage 1, but more chance of remaining broken; for instance, I would have liked to see top-level bootstrapping switched on ASAP. We already know that the common cases work, and it's going to take time to shake out the obscure cases. -- Daniel Jacobowitz CodeSourcery, LLC
