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. >> >
