7197491: update copyright year to match last edit in jdk8 jdk repository
Kelly O'Hair
kelly.ohair at oracle.com
Fri Nov 2 22:15:33 UTC 2012
Include me on any review requests for these things, I'll be happy to be a reviewer.
-kto
On Nov 2, 2012, at 1:08 PM, Steve Sides wrote:
> On 11/2/2012 9:47 AM, Kelly O'Hair wrote:
>>
>> It looked fine to me.
>>
>> One of the reasons this has fallen through the cracks so much is because nobody has any time to do it.
>> Completely automating it is risky, and it needs to be reviewed. So it needs an official owner and
> I agree. You can't completely automate for reasons you mentioned earlier(or later?).
> RE is official owner since ultimately they are responsible and "must" make sure it is done prior to GA.
> So far developers only should check it, but RE must check it.
>
>> someone to automate the whole thing as much as possible.
>>
>> My recommendation would be that it should be done monthly, but I'd also like to see some stats generated
>> along with it, e.g. per repository: changesets created in the month, source files changed for the month,
>> lines changed, number of copyrights corrected, etc.
>> But of course that takes some resources, someone to own it, and someone to review the changesets.
> RE owns it and will put at least part of the process in place. It's not so hard to run a check, and create a patch..which then needs to be reviewed before going further.
> By our own processes, some of it will need human intervention. We'll have to see what the cost of ownership is. :)
>
> Until GA it wouldn't stop anything, just generate a report and that would set into motion some updates that need to be done for some "next time".
> It's just a matter of how often to do this...get an acceptable number for "periodically".
>
>> The more frequently it happens, the smaller the patch to review. :^)
> That's the hope.
>
> -steve
>
>
>> -kto
>>
>> P.S. I discovered that if you used 'hg diff -C 1' or somehow reduced the context lines to just one line, the
>> diff file becomes smaller, and easier to run through a grep looking for any non-Copyright lines that have changed.
>> That's usually what I am looking for here, changes to anything but the Copyright lines. ;^)
>>
>> P.P.S. The script being used assumes that a changeset that touches any source file means that the copyright year
>> needs updating. There are some exclusions, if the changeset comment mentions "rebranding" or "copyright" it
>> is ignored. So if people are paranoid about this, they should review the script
>> make/scripts/update_copyright_year.sh
>>
>> On Nov 2, 2012, at 9:22 AM, Alan Bateman wrote:
>>
>>> On 02/11/2012 16:08, Phil Race wrote:
>>>> Looks fine to me although I don't know how I can easily (ie not tediously)
>>>> verify that a particular file is correctly updated to 2011 vs 2012 ..
>>> Thanks, although I've already pushed it, just to get it out of the way. I looked at a few samples, as I think Chris and Kumar did, to make sure that they were okay.
>>>
>>>>
>>>> I don't think doing the updates at integration time is particularly desirable
>>>> as it would suggest that a file is updated once by the engineer who is
>>>> making the change and then again by the integration process, doubling
>>>> (approx) the number of changesets.
>>>>
>>>> I'm fine with once or twice a year. For infrequently touched files
>>>> it will maybe amount to the 2X changesets I suppose but still ..
>>> I think Steve should start a thread on jdk8-dev about this, I don't think it matters too much except that doing it every few months feels, perhaps at integration time, about right to me. The other approach is of course to insist that people change the header when changing files but arguably that just adds noise to patches.
>>>
>>>>
>>>> When you get around to the client changes will you be doing the closed sources too ?
>>> I'm just helping out today, I hadn't planned on running with this.
>>>
>>> -Alan.
>>
>
More information about the core-libs-dev
mailing list