So the 3000+ files Alan is referring to are all files which have been
modified but which haven't had their year updated? If we're not worried
about files which haven't been modified then a pre/post-commit script
will suffice and depending on how we implement it we might not need
periodic updates.
Darryl
On 11/02/2012 09:47 AM, Phil Race wrote:
> but ultimately there are files which never get touched which will
need processing to update the year.
The policy has varied over the years, but presently the policy is not to
update the year in files that have not been updated code-wise.
-phil.
On 11/2/2012 9:37 AM, Darryl Mocek wrote:
Alan,
I was responsible for updating the copyrights for JavaME. I used
a Perl script to update the copyright year in the source files. I
can point you to the relevant information if you like. There were
challenges as there are various copyrights in the source files
(Oracle, Oracle + 3rd-party, 3rd party only, and no copyright), all
with different formats, and even within the Oracle copyrights, people
used subtle differences which caused difficulties. I ended updating
all copyrights to a few formats and adding a post-commit script which
scrubbed the copyright and notified the committer if the copyright
wasn't in the correct format and didn't have an ending year (or sole
year) which is the current year.
There are plenty of options here:
- Do nothing (policy)
- Pre-commit script which changes the year automatically
- Pre-commit script which rejects commit with wrong year
- Post-commit script which flags a bad copyright, but accepts commit
- Others
Updating the copyright year as you commit is a good habit to get
into, but ultimately there are files which never get touched which
will need processing to update the year. I think doing this at the
end/beginning of the year is good, we just need to make sure we get
the copyright correct when processing.
Darryl
On 11/02/2012 05:46 AM, Alan Bateman wrote:
Now for some noise.
The copyright date in the source files needs updating. The man
behind the curtain is Steve Sides from the Quality and Release
Engineering team in Oracle. Jon pushed, on Steve's behalf, the
update to the langtools files recently [1], and Mikael updated
hotspot [2]. The elephant is the jdk repository as there are 3000+
files that need their headers updated.
To keep the disruption to a minimum I propose that we do the jdk
repository in two steps: non-client area now to jdk8/tl, and then
the client-area later in jdk8/awt once the changes get there. I use
the term "client-area" loosely to mean the source files for awt,
swing, font, java2d, etc. (and I appreciate that there is also a
jdk8/2d forest in use). To that end here is the proposed patch for
today:
http://cr.openjdk.java.net/~alanb/7197491/copyright.patch
This patch updates the headers on 2370 files. I don't propose to
publish a webrev as it's just too big.
This patch was created with:
cd jdk
sh ../make/scripts/update_copyright_year.sh 2011
sh ../make/scripts/update_copyright_year.sh 2012
hg revert --no-backup `cat clientdirs.list`
hg diff -g > copyright.patch
where clientdirs.list is most of the directories corresponding to
the client area.
Note that I ran the update_copyright_year.sh script twice, once for
2011 and then a second time for 2012. The reason for this is that
there are several hundred files in the jdk repository that were last
updated in 2011 but have an older date on the header.
Reviewer welcome but I should say that I don't have cycles to spend
on this. Also the patch has an a very short shelf life.
Finally, I think that there needs to be wider discussion as to how
to keep the headers from falling behind too much. Some people do
update the headers when editing files, some people (including
myself) do not. It seems to me that it should be done regularly
anyway, perhaps every few months or at integration time every so often.
-Alan.
[1] http://hg.openjdk.java.net/jdk8/tl/langtools/rev/9d47f4850714
[2] http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/b9a9ed0f8eeb
