On 2024-12-09 21:39, Joseph D. Darcy wrote:
FWIW, when I've thought about the topic of copyright and licenses
before, I think there are several aspects that can be separated.
One is a syntactic-only check, as the in-flight Skara PR may provide.
I think having a syntactic-only check is Skara is reasonable.
Agreed.
A semantic check is "does file F have the proper license for its role
in the project?" For example, GPL vs GPL w the classpath exception or
"@test /nodynamiccopyright/" for certain langtools tests, etc.
These checks are complicated enough and have enough change over time
that I don't think they are appropriate for Skara. However, they could
be accommodated by check/test that lived in the repository and was
evolved with the repository.
Agreed. Note that this check can be done by only having access to the
source code; no git metadata is required.
But there is a third kind of check, and that is if the year should be
updated. This check can only be done with some additional metadata
present. Skara is in a unique position to enforce this, since it knows
when a commit is being added and the current year at that time. This
cannot be checked by a test that has only access to the source code. It
*can* be done locally if you have the git repo available, but that is
not the case for e.g. how we run tests in the Oracle CI.
So I believe that, if we can -- as Archie described it -- find a
"well-defined and algorithmically decidable" rule for copyright year
updates, that it should be enforced by Skara.
/Magnus
-Joe
On 12/9/2024 11:32 AM, Archie Cobbs wrote:
OK thanks. Apologies for getting confused, I'm not familiar with the
skara code so I'm not always sure what I'm looking at.
I personally think Skara shouldn't do that, but it is a topic
that might be worth discussing for a future Enhancement.
I think it's a good idea, but only to the extent that "the right
thing to do" is well-defined and algorithmically decidable (so the
likelihood of false positives is virtually zero).
There seems to be some debate about whether copyright updates are
required for "significant" changes or all changes; only the latter
case is "well-defined" so this idea would depend on confirmation of
an "all changes" policy - that is, unless someone can encode
"significant" into an algorithm.
In other words, it seems like a sufficiently conservative
implementation (zero false positives) would be a net win.
-Archie
On Mon, Dec 9, 2024 at 1:16 PM Kevin Rushforth
<kevin.rushfo...@oracle.com> wrote:
No, The Skara PR in question isn't proposing to do this. Rather
it is checking that _if_ the Copyright header is updated, it is
syntactically correct.
It would be an item for further discussion to have Skara actually
get into the business of whether the copyright header should be
updated and what the copyright year(s) should be. I personally
think Skara shouldn't do that, but it is a topic that might be
worth discussing for a future Enhancement.
-- Kevin
On 12/9/2024 10:37 AM, Archie Cobbs wrote:
Bleh, ignore my comment. I didn't realize the PR#1702 you
referenced is already proposing doing this!
-Archie
On Mon, Dec 9, 2024 at 10:45 AM Archie Cobbs
<archie.co...@gmail.com> wrote:
Thanks for working on this... something of a thankless task :)
I'm sure you've considered this but I'll ask anyway. Would
it make (more or less) sense to try and enforce the policy
on the front-end?
By that I mean adding another checkbox requirement to
skara's handling of PR's: "🔲 Change must update copyright
dates where applicable"
The check could start out being conservative:
* Only applies to files with certain extensions and/or
matching some filter list
* Only applies to files containing a recognizable
copyright text line
-Archie
On Mon, Dec 9, 2024 at 7:06 AM Magnus Ihse Bursie
<magnus.ihse.bur...@oracle.com> wrote:
I felt responsibility for the .github files, and wanted
to check if there were more build system files needed
updating. So I ran a more comprehensive script, and
discovered a *lot* more files that needed updating. Like
a thousand or so...
I have opened a series of issues starting at
https://bugs.openjdk.org/browse/JDK-8345793 and going up
to https://bugs.openjdk.org/browse/JDK-8345805 to update
these headers.
I agree, this should be automated. We're starting to
slowly get there, see
https://github.com/openjdk/skara/pull/1702 for a first step.
/Magnus
On 2024-12-03 16:45, Archie Cobbs wrote:
Dumb question...
It seems like the thing with updating copyright years
in source files could be better automated. At least,
couldn't there be a test that fails if you forget?
FWIW my little updater script says that these files
still need to be updated to 2024:
.github/actions/config/action.yml
.github/actions/do-build/action.yml
.github/actions/get-bootjdk/action.yml
.github/actions/get-bundles/action.yml
.github/actions/get-msys2/action.yml
.github/scripts/gen-build-failure-report.sh
.github/scripts/gen-test-summary.sh
.github/workflows/build-cross-compile.yml
.github/workflows/test.yml
src/java.base/share/classes/jdk/internal/org/xml/sax/Attributes.java
src/java.base/share/classes/jdk/internal/org/xml/sax/InputSource.java
src/java.base/share/classes/jdk/internal/org/xml/sax/SAXException.java
src/java.base/share/classes/jdk/internal/org/xml/sax/SAXParseException.java
src/java.base/share/classes/jdk/internal/org/xml/sax/XMLReader.java
src/java.base/share/classes/jdk/internal/org/xml/sax/helpers/DefaultHandler.java
src/java.base/share/classes/jdk/internal/platform/Metrics.java
test/hotspot/jtreg/compiler/vectorization/runner/BasicIntOpTest.java
test/hotspot/jtreg/compiler/vectorization/runner/BasicLongOpTest.java
test/hotspot/jtreg/compiler/whitebox/DeoptimizeFramesTest.java
-Archie
--
Archie L. Cobbs
--
Archie L. Cobbs
--
Archie L. Cobbs
--
Archie L. Cobbs
