From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stephen Warren Date: Tue, 26 Apr 2016 10:21:08 -0600 Subject: [U-Boot] [PATCH 02/60] mmc: tegra: move pad init into MMC driver In-Reply-To: <20160426001415.GJ29322@bill-the-cat> References: <1461099580-3866-3-git-send-email-swarren@wwwdotorg.org> <20160424102046.4082710028B@atlas.denx.de> <571E733A.1060208@wwwdotorg.org> <20160425215253.8B4EA100386@atlas.denx.de> <20160425223739.GF29322@bill-the-cat> <571E9D96.4000306@wwwdotorg.org> <20160425230531.GG29322@bill-the-cat> <571EA414.50705@wwwdotorg.org> <20160425232623.GI29322@bill-the-cat> <571EA99F.7030602@wwwdotorg.org> <20160426001415.GJ29322@bill-the-cat> Message-ID: <571F9574.1040008@wwwdotorg.org> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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@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.