This is the mail archive of the
mailing list for the GCC project.
Re: Mistaken change in GCC (fwd)
- To: mrs at windriver dot com (Mike Stump)
- Subject: Re: Mistaken change in GCC (fwd)
- From: Joe Buck <jbuck at racerx dot synopsys dot com>
- Date: Mon, 27 Nov 2000 21:48:08 -0800 (PST)
- Cc: zackw at stanford dot edu, dewar at gnat dot com, gcc at gcc dot gnu dot org, gerd at gnu dot org, pfeifer at dbai dot tuwien dot ac dot at
> > Date: Wed, 22 Nov 2000 22:42:36 -0800
> > From: "Zack Weinberg" <zackw@Stanford.EDU>
> > To: Joe Buck <firstname.lastname@example.org>
> > > 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?
> > 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.