[U-Boot] [PATCH 02/60] mmc: tegra: move pad init into MMC driver

[Tom Rini]

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.1060208 at 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, 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20160425/9fec52b6/attachment.sig>