On 7/11/2012 2:11 AM, Kelly O'Hair wrote:
On Nov 4, 2012, at 2:04 AM, David Holmes wrote:
On 3/11/2012 3:27 AM, Kelly O'Hair wrote:
All changes to JDK sources require a CR, an OpenJDK author name, and a review
by a second OpenJDK author.
So although you can automate the preparation of the commit, you cannot fully
automate this process.
There have been many discussions over the years about automating various
changes, anything from tag generation,
to whitespace normalization, and this copyright year change issue.
Our policy has been that changesets need human authors, and all changes need a
human review.
I think that is the tail wagging the dog. A simple change to a year value in a
comment by a sanctioned pre/post commit script can easily be accommodated in
the changeset for a given CR just as-if the engineer had done it themselves. In
the SCCS days we didn't require reviews for sccs tag updates in file headers -
I don't see that copyright update should be any different. If we need to tweak
the OpenJDK rules then lets tweak them.
But in SCCS days, you still needed an identity on the change, an informal
review, and a human to trigger the putback.
It would be no different with hg. In SCCS days you would only see the
sccs variable in the code. The update only happens when you "commit". In
neither case do the reviewers see the actual change; in both cases there
is an identity on the change and a human doing it.
Anyway I prefer manual updates with a jcheck check. There are times when
a change does not necessitate an update to the copyright year (mainly
changes to the copyright notice itself) but these are rare.
Cheers,
David
It is true that in the SCCS days there was less red tape, but in the SCCS days
there was much less tracking of
all changes, and identities could be fictitious. The SCCS history was generally
worthless.
Personally I don't see why it is so hard to have engineers be responsible for
this (if automation is considered so problematic). It only affects one
changeset per file per year and a pre-commit script (or jcheck enhancement?)
could warn you if you forget to do the update. I find these big periodic
changesets far more noisy and problematic.
The only issue would be that warnings tend to be ignored by most developers,
but I could accept this idea.
If jcheck blocked the commit when it detected a missing year change, that would
force the edit before the
changeset would be created, or before the changeset was integrated.
However, I'm not exactly sure we could make the copyright year check that
concrete, maybe, it's not as
cut and dried as the whitespace check jcheck does.
For the general audience: copyright years only get updated when there is a
substantive change to the material content of a file. I think we well and truly
established that when we went through the Sun to Oracle conversion process.
Yes. There are very rare situations where a file can change, and that change
should not trigger a year update.
So by default, we treat any change to a file as being one that needs a year
update.
---
Just to clarify it for others:
And there are 2 years. The first year is the initial creation, the second year
is the year of last change.
When they are the same, one year will be listed in the legal notice.
It's very important to preserve that first year, or year of creation.
-kto
David
-kto
On Nov 2, 2012, at 9:51 AM, Darryl Mocek wrote:
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
