From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tom Rini Date: Tue, 26 Apr 2016 19:29:21 -0400 Subject: [U-Boot] [PATCH 13/60] ARM: tegra: sort some board file include directives In-Reply-To: <571FD328.50301@wwwdotorg.org> References: <1461099580-3866-1-git-send-email-swarren@wwwdotorg.org> <1461099580-3866-14-git-send-email-swarren@wwwdotorg.org> <20160424102050.AD0C110028B@atlas.denx.de> <571E75E2.6020008@wwwdotorg.org> <20160425215939.C82CD100386@atlas.denx.de> <20160425232226.GH29322@bill-the-cat> <571F94BE.2030106@wwwdotorg.org> <20160426181536.GW29322@bill-the-cat> <571FD328.50301@wwwdotorg.org> Message-ID: <20160426232921.GA29322@bill-the-cat> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On Tue, Apr 26, 2016 at 02:44:24PM -0600, Stephen Warren wrote: > On 04/26/2016 12:15 PM, Tom Rini wrote: > >On Tue, Apr 26, 2016 at 10:18:06AM -0600, Stephen Warren wrote: > >>On 04/25/2016 05:22 PM, Tom Rini wrote: > >>... > >>>I know company lawyers come up with various policies and some are more > >>>restrictive than others. Anything about the exact guidelines you can > >>>share would be appreciated. > >> > >>They're simple and I would assume quite standard: > >> > >>1) When creating a new file, add an NVIDIA copyright header. > >> > >>2) When performing a non-trival edit to an existing file, if it has > >>an existing NVIDIA copyright header, update the data, and if not, > >>add one. > >> > >>Guidance on "non-trivial" isn't given. I would take it to mean > >>anything other than typos and whitespace fixes. > >> > >>Re-ordering your email slightly: > >>>I want to echo my agreement on this point. Re-ordering includes does > >>>not rise to the level of adding copyright/author/etc lines. > >> > >>I can see your argument re: copyright headers in the individual > >>files, although again I'd echo my previous comments re: a simple and > >>unambiguous process being preferable. > > > >Here's where I hope I don't get everyone at NVIDIA that's doing Linux > >Kernel or other F/OSS work in trouble. Point #1 above is quite > >understandable. Point #2 is something I can see but has totally not > >been done by the folks doing Linux Kernel work. > > Admittedly compliance is spotty; the last thing someone wants to do > when having completed a patch is think about all kinds of nit-picks > like updating copyrights, checkpatch, testing, even compiling:-) > > However, it's certainly not unheard of. Here are a few examples I > was able to spot quickly: > > NVIDIA: > af6313d61a78 (Alex Courbot) > 08acae34e8da (Paul Walsmley) > 891846516317 (Thierry Reding) > 783c8f4c8445 (Peter De Schrijver) > 0ffdd4b61b13 (Stephen Warren) > > Red Hat > 1363074667a6 (Hans De Goede) > 25462f7f5295 (Wei Huang) > 54cea3f6681a (Milan Broz) > > Texas Instruments > 2f67864b6d5b (Andrew F. Davis) > 0d6fa53fd805 (Andy Gross) > > Denx > 88eeb72ec4c1 (Stefan Roese) > > Admittedly those don't look like refactoring changes, but it sounded > to me like you were arguing completely against point (2) in my > original email above. That's not reasonable. Arguing against (2) for > simple refactoring could be. I'm arguing in favour of what all of those commits did, extending existing copyright notices. I'm fine with that. To be clear, in _this_ patch what I object to is adding the NVIDIA copyright line to board/avionic-design/common/tamonten-ng.c and I am fine with extending it on all of the board/nvidia/ files and now wondering you didn't add it to board/toradex/. > >The review on this patch series itself has indeed been derailed, which I > >do not like either. With respect to copyright on individual changes and > >so forth, is this a concern you have, or a concern the lawyers at NVIDIA > >have? > > The lawyers have dictated the process which I should follow. I often > forget, so I made sure that for such a large series I'd follow the > process correctly this time. To be honest, I'm way beyond care about > anything to do with copyright at this point; I'd rather just work on > something where it wasn't an issue in any form at all. Indeed :( -- Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: