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

[Tom Rini]

On Tue, Apr 26, 2016 at 10:21:08AM -0600, Stephen Warren wrote:
> 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.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,
> 
> 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.

The problem here is that much of this series is not making unambiguously
significant changes.  I do not have a problem with (but maybe I need to
chat with the Software Freedom Conservancy folks more) adding /
extending copyrights when adding significant changes to existing files
nor adding them to new files.

-- 
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/20160426/f697cadc/attachment.sig>