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 <[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.
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, and then I suppose toss in my own copyright too, because now I've made some change to the file. Since you mentioned the kernel, I just popped open git log -p in the kernel and I do not see a flood of "made a change, add/update copyright". -- Tom
signature.asc
Description: Digital signature
_______________________________________________ U-Boot mailing list [email protected] http://lists.denx.de/mailman/listinfo/u-boot
