This is the mail archive of the
mailing list for the GCC project.
Re: Automated testing framework (was: V3: SPARC bug and tree freeze)
- To: jsm28 at cam dot ac dot uk
- Subject: Re: Automated testing framework (was: V3: SPARC bug and tree freeze)
- From: Richard Stallman <rms at gnu dot org>
- Date: Thu, 16 Nov 2000 13:24:22 -0700 (MST)
- CC: aoliva at redhat dot com, guerby at acm dot org, gcc at gcc dot gnu dot org
- References: <Pine.LNX.firstname.lastname@example.org>
- Reply-to: rms at gnu dot 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 email@example.com.
Properly speaking, the maintainers of GCC are the people in the
steering committee--they are the ones who have accepted the post of
GCC maintenance. Other people participate, but these people have the
responsibility to make sure it is done right. The file MAINTAINERS,
despite its name, doesn't define who the maintainers are.
The 89 people listed there probably do various different kinds of
work. Some of them look at changes written by other contributors and
install them; those people need to check for papers, and normally
ought to know what to say to the other contributors to tell them how
to sign papers. I hope the number of these people is much smaller
than 89, though. It would be unreliable to have 89 people doing this
job--someone is sure to misunderstand.
As for the people who write and install their own changes, but don't
install other people's changes, we need papers *from them* but they
don't ever have to direct other people how to deal with the papers.
I hope this results in a number of people who tell others what papers
to sign which is large enough that there isn't too much work for each,
but small enough that teaching all of them is feasible and reliable.
That way the job can get done easily and reliably.
Does assign.future also cover changes to the GCC manual?
I asked our lawyer about this a month ago, and that is when I wrote
the text in maintain.texi about the subject. In the case of the GCC
manual, since it is published separately as a book, we should get
separate papers for the manual.
It would have been a good idea for me to have asked about this in the
past. I wish I had asked him earlier.
What exactly is the position on whether an assign.future for "GNU CC" or
"GCC" (assigning "... Developer's copyright in changes and/or enhancements
to the program <name of program> ...") covers all programs, libraries,
manuals and other files in the GNU Compiler Collection (GCC)?
Yes, but the test suite is not part of GCC. (If that is not entirely
clear in the distribution, the web site, etc, we need to make it
practice is that the first change made to any file in a year requires the
copyright dates to be updated (whether or not there is a release finished
that year). Is that correct?
It is reasonable. I myself would not update the year if there has
been only a trivial change since the beginning of the year, but
it does no harm to do so.
If file F1 has copyright dates D1, and file F2 has copyright dates D2,
and, in year Y, I copy or move code from F1 to F2, should the copyright
dates on F1 be added to those on F2, if not already there?
Yes, it should be.
Could the official version of the guidelines from Prof. Moglen on what can
go in the testsuite be put on the GCC web pages (rather than just the
summary at http://gcc.gnu.org/ml/gcc/2000-01/msg00593.html)?
I don't know; it depends what is in that message. (I am not sure that
the term "official version" really describes it properly; I would have
to see it again to judge that.)