Re: Automated testing framework (was: V3: SPARC bug and tree freeze)

[Richard Stallman <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 assign@gnu.org.

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
clearer!)

      The GCC
    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.)