This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Stan Shebs, new Objective-C maintainer
- To: gcc at gcc dot gnu dot org
- Subject: Re: Stan Shebs, new Objective-C maintainer
- From: David Edelsohn <dje at watson dot ibm dot com>
- Date: Tue, 13 Mar 2001 14:12:56 -0500
- cc: Joe Buck <jbuck at synopsys dot COM>
>>>>> Joe Buck writes:
Joe> The maintainer's job is not to provide individual support to the whole
Joe> net, so we wouldn't want to encourage people to mail their questions to an
Joe> individual maintainer directly. People sending private mail to
Joe> maintainers demanding schedules or attention to their specific bugs is
Joe> particularly harmful; it just makes people really sorry that they ever
Joe> volunteered.
Joe> So, don't send private mail to Stan asking him to do something for you.
Joe> Feel free to send private mail if you're offering to do something for him.
Joe> Bugs in GNU Objective-C should go to gcc-bugs; other issues
Joe> specific to the GNU implementation can go here; questions about the
Joe> language itself should go elsewhere (sorry, I don't recall the name
Joe> of the Usenet Objective-C group).
Let me re-iterate that this is not just a statement about the role
of the Objective-C maintainer or front-end language maintainers or ...,
but about maintainers of all components of GCC. Questions and bug reports
should be sent to the public mailinglists.
Sometimes it is useful to cc: a maintainer of a particular
component in GCC to ensure that he or she is aware of a bug report or
question that is specific to that maintainer, but the primary contact
should be sent to the public mailinglist. Contacting a maintainer of a
component of GCC does ensure any sort of response or any help with the
issue.
As Joe said, the maintainer's responsibility is not to provide
individual support to the entire Net. There are commercial companies
which provide support services for the GNU toolchain. The maintainer's
role is to coordinate the free software development process as much as
performing the development work himself or herself. The maintainer is not
persnally responsible for shouldering all of the development work.
David