[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [groff] 01/01: Update copyright

From: Bertrand Garrigues
Subject: Re: [groff] 01/01: Update copyright
Date: Sun, 25 Oct 2020 22:53:31 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux)

Hi Ingo,

On Sun, Oct 25 2020 at 06:16:44 PM, Ingo Schwarze <> wrote:
> Bertrand Garrigues wrote on Sat, Oct 24, 2020 at 07:54:43PM -0400:
>> bgarrigues pushed a commit to branch master
>> in repository groff.
>> commit a2e955e07354c83939fabffebcf720d3333d1f6b
>> Author: Bertrand Garrigues <>
>> AuthorDate: Sun Oct 25 01:11:38 2020 +0200
>>     Update copyright
>>     Use gnulib's update-copyright script.
> Please don't blindly rely on defective scripts.
> Before you commit something, you always have to check it.
> I think at least part of this commit must be reverted.
>> diff --git a/COPYING b/COPYING
>> diff --git a/FDL b/FDL
>> diff --git a/bootstrap b/bootstrap
>> diff --git a/doc/fdl.texi b/doc/fdl.texi

Yes those files should not be updated.

The script is not to blame (it updates the copyright notice on a single
file), only the way I used it was wrong.  I could not remember how I
filtered out the files to be modified during the previous release and I
completely overlooked some files yesterday.  Only today I found out that
3 years ago in a private discussion Werner gave me his update-copyright
integration in his 'ttfautohint' package (a list of file that must not
be modified should be defined, but for some reasons I did not commit

> I did not scrutinize all 500 files, there are likely several more
> errors that must be reverted.
> If you feel that you must edit 500 files, i think it is your
> repsonsibility to make sure that your change to every single one
> of them is correct.  Yes, that is a lot of work.  But committing
> unchecked and illegal changes is not OK IMHO.

I reverted completely the commit; I'll work to correctly integrate

> I still think that keeping the Copyright notice of each single file
> up to date whenever one adds non-trivial changes to an individual
> file is not only more useful but also causes less work, in particular
> in a project with very large numbers of files that rarely change.

I agree but it is too late: this was the case up to version 1.22.2, but
starting from version 1.22.3 all the sequences of years with gaps were
converted to a single range.  We can't go back to the previous mode now,
it would be inconsistent.

> But i do realize that some groff developers want a uniform Copyright
> statement across all groff files.  Still, those who want that must
> make sure it is done correctly.

I guess that it is a GNU recommendation:

"When you add the new year, it is not required to keep track of which
files have seen significant changes in the new year and which have
not. It is recommended and simpler to add the new year to all files in
the package, and be done with it for the rest of the year"

Bertrand Garrigues

reply via email to

[Prev in Thread] Current Thread [Next in Thread]