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: Automated testing framework (was: V3: SPARC bug and tree freeze)


> Date: Tue, 14 Nov 2000 00:22:02 -0700 (MST)
> From: Richard Stallman <rms@gnu.org>
> To: aoliva@redhat.com

> Posting the criteria proved to be a bad idea, because a fair number of
> people don't fully understand them at first reading.

Posting the source to gcc is bad because a fair number of people don't
fully understand it at first reading.  :-( I do not understand your
point.  If people are not understanding what they read, that clearly
shows a lack of proper documentation.  Eliminating the documentation
while it helps them to not misunderstand it, doesn't help them
understand it better.

> To: rms@gnu.org
> From: law@redhat.com
> Date: Tue, 14 Nov 2000 09:29:17 -0700

> If people were making mistakes with the previous online instructions
> or forms, then that means those instructions need to be clarified.

I agree.

> Date: Tue, 14 Nov 2000 19:11:55 +0000 (GMT)
> From: "Joseph S. Myers" <jsm28@cam.ac.uk>
> To: Richard Stallman <rms@gnu.org>
> cc: <aoliva@redhat.com>, <guerby@acm.org>, <gcc@gcc.gnu.org>

> There still needs to be a system for all 89 GCC maintainers (the count of
> distinct people in MAINTAINERS, including those marked as being people who
> ought to have accounts for CVS write access but don't yet) to have the
> forms for sending to contributors, better than everyone individually
> getting them from assign@gnu.org.

I think it is easier for us to have a comprehensive web site that
includes all the subtle details that we learn about over time, that
can be reviewed by the FSF, to ensure that our understanding is
correct, and to have a place for updates to appear so that all of the
gcc maintainers can see the changes, instead of the one on one
conversations with various parties in the know.  I think this also has
the added benefit of getting people to actually file a disclaimer or
assignment.  If people have to ask for directions from someone, and if
that someone doesn't respond directly and in a timely fashion, we can
loose out on having another contributor.  The egcs project tried to
address the idea of loosing out on contributors, and I think they were
successful.  One aspect of this that was addressed was the inclusion
of the forms on the web site.  If we include example scenarios of
correct applications, and examples of what not to do, we can increase
the usefulness and accuracy of the web site, and hopefully the
accuracy of how people use the various forms.

Asking all the maintainers to be versed in all the detail is I think
asking too much.  Better to have it written down.  The fact that other
folks from other projects were getting advice from the gcc web site in
these matters shows that there is an existing need for such a web
site.

I think if we are to be tasked with solving the problem, then the
exact form of the solution to the problem ought to rest squarely on
our shoulders.  If we can improve the documentation so that it doesn't
confuse people from other projects, then I think we should.  It we can
improve it to be more understandable, then we should.  If we can alert
people to the 30 most common problems in the application of the
advice, well, even I would be educated by it.

I would think that a written system is better from a management
perspective, as then management can know what advice is being given
out and have a chance to correct it, update it and review it.  Also,
if people give out advice that is contrary to the documentation, it
offers the ability to have that corrected in a more timely fashion.
From a point of view of someone _giving advice_, I think it would be
better, as we can know that the advice we are giving is in fact the
best advice we can give.

Now, if we want to hide it down on a maintainers part of the web site
instead of having it on page 1 of the web site, that would be a
reasonable compromise I think.  This way, random folks are less likely
to stumble across is, yet people in the know can still find it.  Would
this compromise solution be acceptable to you?

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