This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: GCC 4.1 Projects


Mark Mitchell <mark@codesourcery.com> writes:

| Nathanael Nerode wrote:
| >>> Nathanael Nerode wrote:
| > It's in now, BTW.  Nothing broke.  :-)
| 
| We need to talk about that.
| 
| Independently of whether or not I made the right decision, your
| decision to check in the patch undermined the process.  Rather than
| convincing me I was in error, or developing a wider consensus that I
| was in fact in error, you chose to act preemptively.  Meanwhile, Dan
| Jacobowitz and David Edelsohn were spending time trying to develop
| that wider consensus, and I was devoting time to responding and
| investigating. That time was wasted, since you were not willing to
| wait for the result.

The consensus existed, except that it seems there was a selective
perception.  Noone, except you, actually argued in this thread -- after
consideration of the actual facts -- that Nathanael's patch should wait
till stage 2.  The only reasons I've seen were purely abstract
administrative. 

I appreciate organization, and I would be a fierce proponent for
rationalization of our development scheme, but I'm emphatically
unconvinced that the GCC team is in a crying need of pile of
administrative walls.

(Parenthetically, the bazard model is working not so bad for GCC,
since July 1997.)

Don't get me wrong.  I have no desire to undermine your Release
Manager work -- I appreciate how hard it can be.  Conversely, I do not
believe that we should develop process that actively incite people
*not* to contribute, because of unconvincing administrative reasons.
We should encourage branch for "experimental" work, but we should not
be forcing people to indefinitely maintain branches for no actual
benefits, when they are ready for merge, especially works as localized
and well tested ones as that of Nathanael at an early stage as 1. 

I guess what I'm trying to say is that: yes, we need rationalization,
but we do not miss blind rules.

| I'm glad that nothing broke, and it would serve no purpose to revert
| the patch, especially given that there's a lot of evidence I made the
| wrong call in the first place.  I admire your work, and I'm grateful
| for and impressed by the cleanups you've made over the years.
| However, I think that this was an inappropriate action on your part.
| I'd appreciate your assurance that you will not take this kind of
| preemptive action again.

In an earlier message, you spoke of trust.  It works both ways. 
Sure, the Release Manager has full authority -- and probably some form
of dictatorship needs to be exercised especially when people do not keep
the tree in a good shape or do not follow well understood and easy to
comprehend rules.
My view is that the Release Manager trust maintainers for their best
judgments.  Conversely, the Release Manager need to be trusted. That
works, when we all understand the decisions and some consensus are
reached. 

And, yes, I appreciate your work a lot.  That does not rule out
occasional disagreements. 

-- Gaby


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]