On 04/25/2016 05:26 PM, Tom Rini wrote:
On Mon, Apr 25, 2016 at 05:11:16PM -0600, Stephen Warren wrote:
On 04/25/2016 05:05 PM, Tom Rini wrote:
On Mon, Apr 25, 2016 at 04:43:34PM -0600, Stephen Warren wrote:
On 04/25/2016 04:37 PM, Tom Rini wrote:
On Mon, Apr 25, 2016 at 11:52:53PM +0200, Wolfgang Denk wrote:
Dear Stephen Warren,
In message <[email protected]> you wrote:
[snip]
Unfortunately we've (NVIDIA at least) been a little lax making sure the
NVIDIA copyright messages are kept up-to-date when editing files, hence
why this series had to change a lot of them for the first time recently.
If we went back and re-wrote all of git history paying strict attention
to the copyright notice dates and formatting, I imagine the set of
copyright-related changes in this series would be much smaller.
I'm quoting Wolfgang's email here, but, yes, keeping the copyright
notices correct is important. Now, what do you mean by would be
smaller?
Personally I want to spend my time coding rather than dealing with
licensing. As such, it's easy to forget to update the dates in
copyright notices when changing files, or to put the correct
information into new files when creating new ones (often by just
cutting/pasting some other file with similar issues). If we had done
that 100% correctly in every commit across history, my inclination
is that more files would already have an NVIDIA copyright message,
and/or already have 2016 in the date, and hence this series wouldn't
include an edit to those messages since they'd already be
up-to-date. Still, I have no searched all history to confirm that;
it's just my gut instinct.
Right, OK. So you're saying you may, in some cases, be adding 2016 to
files you haven't touched this year yet?
Yes, I'm sure there's a mix.
OK. And I assume you're globbing on file paths to check / update?
Doing you can do 'git log --since=YYYY-01-01-YYYY-12-31' to find the
first/last commits in a given year, git diff a..b | diffstat > Y.txt to
get a diffstat and check your numbers vs that. This doesn't feel like
an undue burden on making sure copyright stuff is year-correct for
last-touch.
Well, by "yet" I assumed you mean "before this patch set". There are no
changes in the patch set that do nothing but edit/add a copyright notice
without making other changes. The only edits to copyrights in this
series are because I've edited files for the purpose behind the patch,
and then have updated the copyright while doing so.
What I did was:
a) Make all the changes.
b) Go through all the patches with "git rebase -i", get the list of
files edited in the patch, and ensure the copyright date reflected the
edit made in that patch.
BTW, while code re-org is not the most involved of coding, I don't see a
reason to make developers decide legal issues such as what amounts to a
change that's large enough to change the copyright date, or add a
copyright header. The rule should be simple and unambiguous (edit a file
-> change the copyright); anything else is asking for different people
to argue over interpretation, which just everybody's wastes time. Let's
leave that to lawyers and just deal with code.
_______________________________________________
U-Boot mailing list
[email protected]
http://lists.denx.de/mailman/listinfo/u-boot
