This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Automated testing framework (was: V3: SPARC bug and tree freeze)
- To: Richard Stallman <rms at gnu dot org>
- Subject: Re: Automated testing framework (was: V3: SPARC bug and tree freeze)
- From: "Joseph S. Myers" <jsm28 at cam dot ac dot uk>
- Date: Tue, 14 Nov 2000 19:11:55 +0000 (GMT)
- cc: <aoliva at redhat dot com>, <guerby at acm dot org>, <gcc at gcc dot gnu dot org>
On Tue, 14 Nov 2000, Richard Stallman wrote:
> >> Please send this paragraph to rms@gnu.org and he'll send you the
> >> appropriate forms.
>
> Please don't ask me, ask the GCC maintainers. Telling contributors
> what forms to use is part of a package maintainer's job.
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.
> It is much more reliable for the maintainer to do this, because the
> number of GNU package maintainers is much smaller; once a maintainer
> understands the criteria (by asking me questions if necessary), he can
> do the job easily and reliably.
Here are some questions:
Does assign.future also cover changes to the GCC manual? I've been told
in July that
> I have on file an assign.future for "GNU CC".
>
> If further assignements are needed for changes to manuals / web pages /
> testsuite / ..., then let me know what to put on what assignment forms
> (and add some explanation to contribute.html).
It's definitely sufficient for the manuals and also the web pages; I am
not completely sure about the testsuite -- Jeff is our assignment expert,
I believe...
but the GNU maintainers instructions say that
You do not need to ask for separate papers for a manual that is
distributed only in the software package it describes. But if we
sometimes distribute the manual separately (for instance, if we
publish it as a book), then we need separate legal papers for changes
in the manual. For smaller changes, use
`/gd/gnuorg/disclaim.changes.manual'; for larger ones, use
`/gd/gnuorg/assign.changes.manual'. To cover both past and future
changes to a manual, you can use `/gd/gnuorg/assign.future.manual'.
and I thought that the FSF do publish the GCC manual as a book.
Does assign.future cover the web pages? Does it cover the testsuite?
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)? If the
testsuite is covered, should all testcases created afresh for the GCC
testsuite (rather than code fragments from bug reports from the net) have
copyright notices included? Should they have a licence notice included?
The instructions for maintainers say that
The list of year numbers should include each year in which you
finished preparing a version which was actually released, and which
was an ancestor of the current version.
How does this apply with anoncvs access to current development? 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?
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? That is,
should the new dates on F2 be (D2 union {Y}) or (D1 union D2 union {Y}),
or something else?
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)?
--
Joseph S. Myers
jsm28@cam.ac.uk