Re: [PATCH RFC] Character set support

Kevin Buettner
2002-09-20T21:58:33Z

On Sep 20, 12:08pm, Andrew Cagney wrote:

> The place to give credit for a work is either the top of a new file,
> and/or in the doco. Suggest updating the (C) entry to include:
>
> Contributed by Red Hat, Inc.
> Written by Jim Blandy.

While I certainly have no objection to changing the copyright text in
the manner that you suggest, in my opinion, the names at the top of
a source file often end up being quite irrevelvant. Many times,
people who made substantial contributions to a file don't appear at
the top of the file, but only in the ChangeLog entries. In my
opinion, names that appear in ChangeLog entries are frequently more
important than the names at the top of a particular source file.

> 10 years from now, people won't be looking in the ChangeLog.

I disagree. When I want to find out who it was that was responsible
for a particular file, I look in the ChangeLog files. I even have
ChangeLog summarization scripts that can help me with this task.

> > If you really need to know who committed a change, the CVS logs and
> > mailing list traffic are available. Also, I believe there is ample
> > precedent in other projects (e.g. gcc) for the way I did things.
>
> The accepted GDB convention is per the above.

I did not realize that this was the accepted convention. Was there some
communication on this matter that I missed? If it is the accepted
convention, then I think it ought to be reconsidered.

First, I believe it is important to give credit where credit is due.
Changes contributed by someone without write after approval permission
ought to look the same as those contributed by someone who is given
permission to commit the changes themselves.

Second there are a number of automatic tools which read ChangeLog
files. I believe the output from these tools will be better if the
name of the contributor (and not the committer) appear in the header
line.

> It means that the ChangeLog stands on its own and does not depend on
> access to either the CVS repository or the mailing lists. It leaves
> no confusion over who committed and who authored the change.

I think the detail regarding who committed a change is largely
irrelevant unless there happens to be a problem with the mechanics of
the commit. But these problems are usually found fairly quickly and
it is usually clear who should get the blame in such cases. (Again,
cvs logs and mailing list traffic are helpful.) The ChangeLog should
be viewed as a longer term record of who has done what and why. When
viewed in this way, the person who happened to commit the patch is
unimportant.

As I stated earlier, I think it's appropriate that the following form
be used when non-trivial changes to the contributor's patch need to be
made:

YYYY-MM-DD Committer <committer@committer.org>

From Contributor <contributor@contributor.org>:
* somefile (somefunction): Something was done.

OTOH, when a contributor's patch can be applied without change, I think
it's appropriate to use the following form:

YYYY-MM-DD Contributor <contributor@contributor.org>

* somefile (somefunction): Something was done.

I have consulted the GNU coding standard regarding this matter. See:

http://www.gnu.org/prep/standards_42.html#SEC42

According to this document, the header line says who made the change.
I suppose we could interpret this to mean the committer of the change,
but I think it's more meaningful to interpret this as the actual author
of the change.

I've discussed this matter with Jim Blandy, and he suggested that the
following form might be useful in some cases:

YYYY-MM-DD Contributor <contributor@contributor.org>

Committed by Committer <committer@committer.org>.
* somefile (somefunction): Something was done.

I'm willing to add a "Committed by" line if you wish, but I strongly
believe that Jim's name should remain on the header line.

Finally, I should note that I missed adding in the include of
"gdb_string.h" in c-lang.c when my update prior to the commit turned
up a conflict that needed resolution. What I should have done in this
case is to create a separate Changelog entry crediting/blaming me in
my attempt to resolve the conflict. I appreciate David Carlton's
efforts at fixing this problem. Anyway, I am also willing to add an
entry which notes my efforts at resolving the merge conflict.

Kevin