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]

Re: Mistaken change in GCC (fwd)


> 
> > Date: Wed, 22 Nov 2000 22:42:36 -0800
> > From: "Zack Weinberg" <zackw@Stanford.EDU>
> > To: Joe Buck <jbuck@racerx.synopsys.com>
I wrote:
> > > Documented features may not be removed from gcc without the agreement of
> > > 3/4 of the steering committee.  Period.  You are proposing to remove
> > > features.  Are you sure that you have the votes?

Zack wrote:
> > Excuse me, I have never heard this before.

I should clarify what I wrote, since it wasn't quite right -- as
you might have been able to tell, I was a bit angry when I wrote that.
I didn't care to be put in the situation of having people screaming
at me for a month.  I'm sorry, Zack, but you were treating RMS like
crap, and like it or not, it's still in the end his compiler.  In
the gcc2 days, there was one vote -- his.

The SC tries to avoid voting.  Consensus is better.  There's only a vote
when there is a dispute, because someone (an SC member or RMS) objects.
RMS has objected, and I decided to back him up, because I don't see a good
reason why we should break all the Emacs versions.  So, we need a 3/4
majority to make a change anyway.  But a vote will probably be avoided
since we'll probably find some consensus solution.

Zack erroneously believed that he had unilateral power to make whatever
decisions he thought appropriate.  I certainly don't want to micromanage
anyone, but instead of engaging in a discussion, Zack was talking like
he was cpp dictator.

> I disagree with the policy.  The can-write people should be free to do
> what they do. This means adding features, extending functionality,
> removing functionality and so on.  However, a good maintainer will
> known when to do something and when not to, they will know when to
> discuss an issue before checking in an idea, they will know when to
> abandon a bad idea and so on.  A new maintainer will be slightly more
> cautious, learning the customs, and why they are what they are, a
> seasoned maintainer will know when to change customs.

For 99% of the decisions maintainers make, this works.  But when a
significant group (in this case, the Emacs maintainers) object, then
the SC has to referee the dispute.

Furthermore the gcc manual is a promise that we have made to the users.
Breaking promises should not be taken lightly, though we might sometimes
decide that it is necessary.


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