On 04/25/2016 06:14 PM, Tom Rini wrote:
On Mon, Apr 25, 2016 at 05:34:55PM -0600, Stephen Warren wrote:
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 <571e733a.1060...@wwwdotorg.org> 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.
OK. This should make any quick sanity checks easier, rather than
harder. Generate the lists, diffstat your series, for F in series, grep
-q year-list && echo touched $F;done
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.
I agree in spirit, with a caveat about meeting a significance threshold.
I think you need to push back on your legal department if they are
asking that every change requires a copyright notice, regardless of
length or complexity. I _cannot_ start having patches conflict because
the contents are fine but now I have to fixup the copyright notices
added since the patch was generated,
I'm not sure why. Let's say the two conflicting patches are both
unambiguously significant works, by two different people/entities.
Surely there's no issue with the copyright notices both being
added/updated in that case? If so, then the only difference is the
volume of conflicts. Volume doesn't seem a great argument since it's not
a problem with the core issue itself.
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
