[Top][All Lists]

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

Copyright update script

From: Urs Liska
Subject: Copyright update script
Date: Tue, 21 Mar 2017 13:56:02 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.6.0

Am 21.03.2017 um 11:21 schrieb Urs Liska:
> Am 21.03.2017 um 11:11 schrieb Phil Holmes:
>> "Urs Liska" <address@hidden> wrote in message
>> news:address@hidden
>>> lilypond --version
>>> GNU LilyPond 2.19.57
>>> Copyright (c) 1996--2015 by
>>>  Han-Wen Nienhuys <address@hidden>
>>>  Jan Nieuwenhuizen <address@hidden>
>>>  and others.
>>> This program is free software.  It is covered by the GNU General Public
>>> License and you are welcome to change it and/or distribute copies of it
>>> under certain conditions.  Invoke as `lilypond --warranty' for more
>>> information.
>>> Spot the error?
>>> The copyright notice gives 2015 instead of 2017. I did a git grep on
>>> Copyright but it seems there's much more to that than simply replacing
>>> one occurence, as (varying) copyright statements are scattered
>>> throughout the code.
>>> So, what's the procedure to update the copyright notice(s)?
>>> Urs
>> I think this is the last time it was done:
>> http://git.savannah.gnu.org/gitweb/?p=lilypond.git;a=commitdiff;h=47db9a3883d726ca53e2133a3b2298f78dd6a32e
> Ah, so it actually *does* involve changing all these occurences ...
> Thanks for the pointer.
> This should be quite easily done with sed.
> BUT: If I'm not mistaken Copyright should only be updated when there are
> actual changes to a file, isn't it? So globablly changing all occurences
> to --2017 wouldn't be accurate but should only be applied to files that
> have last been modified in 2017.
> If that's correct that we should maybe update files that have been
> modified in 2016 and then those that have already been modified 2017.
> And if these assumptions are correct I suggest to create a script that
> is regularly applied (maybe as part of the staging->master merge?)
> checking for files that have been updated in the current year and have
> an outdated copyright in it. I think we can't rely on contributors to
> update the copyright of changed files manually as part of their commits,
> and I think we shouldn't rely on "someone" doing the job occasionally.
> Especially as Werner's commit from Jan 4 globablly updated everything
> (which probably hadn't updated in these four days ...)
> Opinions?

I've now uploaded a patch for review
This contains two commits, updating the copyright notice for files that
have last been changed in 2016 and 2017.

In addition (but hidden in the huge number of files) is the file

This is a script that finds the last commit of each tracked file and if
that has been modified in the target year (or the current year) it does
a sed replace of the copyright notice.

It did so properly for the two commits, at least I did a number of
random checks (i.e. checking if the affected file had actually been
modified in the given year), but I'm absolutely not confident about.

So please review this script carefully and look for unintended behaviour
or even security issues.
Also I find it's pretty slow and I think there should be a faster way to
retrieve the interesting commits, but I didn't find any.

If the script is found working (maybe after some updates) I think we
should incorporate this in the automated process somewhere.
If we'd want to run such an update automatically in the staging->master
merge we can make it much faster by limiting the search to the files
that differ between staging and master.


> Urs


reply via email to

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