Rename nanostack configuration (.cfg) files

[artokin]

Description

• Rename nanostack configuration files .cfg to .h files to fix LPC1768 cannot build blinky in uVision5 due to nanostack errors #7615.
• Update license and copyright years in configuration files.

Pull request type

[x] Fix
[ ] Refactor
[ ] Target update
[ ] Feature
[ ] Breaking change

[artokin]

@SeppoTakalo , @kjbracey-arm , @deepakvenugopal , @mikter would you please review?

[cmonr]

@artokin Thanks for providing the PR.

However, would you mind updating the commit such that the files that were moved don't appear as newly created files? It's the difference between doing a git mv <file> vs git rm <file>; git commit; git add <file>

Doing git mv preserves the file history.

[cmonr]

Could you also update the commit description, since the commits indicate more changes than just those to fix the issue?

[artokin]

@cmonr , all the files were changed similary using git mv <file>, no new files were created. Could it be so that github tool shows some file as new file instead of rename?

[cmonr]

...huh. Interesting. I wonder if the squash commit could have something to do with it.

[geky]

It looks like, besides merges, there's only two commits on the subtree. Can you cherry-pick those commits onto a new branch based on master? This is required to make it into a patch release. Future subtree merges will not have any conflicts if the cherry-picked changes match.

[cmonr]

@artokin Conversely, if you don't mind on having this fix wait until 5.10, we can simply move this PR forward asis.

[SeppoTakalo]

@cmonr This change is applied here as a git subtree pull --squash as we have always done with Nanostack changes. We don't want to apply local changes, or cherry-picks into the Git subtree within Mbed OS repository, it might complicate things later on.

From Mbed OS release point of view, it needs to be threaded as a merge commit. Directly applying it as a patch won't work. Anna has been able to apply these changes to patch release as well, so I assume that it works.

And I would prefer if this goes out into the patch release, as the export builds are broken currently.

[kjbracey]

git mv is just a convenience helper and equivalent to removing then adding - Git doesn't actually store any tracking information for moves and copies, it's always deduced by the log viewer. The addition of the licenses makes some of the differences too big to deduce the move in the squashed result - it would have been clearer in the internal repo.

I thought Anna had had problems cherry-picking these subtree merge PRs in the past, although I reckon it should in theory possible by cherry-picking just the merge commit with the -m option.

But as this follows the already-merged 5.10 release PR won't the 5.9 backport likely conflict anyway? So maybe it would be best to make a separate PR targeting the 5.9 branch.

[adbridge]

As @kjbracey-arm noted, if this is based on top of changes earmarked for 5.10 then yes we are likely to get merge conflicts, so a separate PR would be best. However I don't like this kind of thing happening in general... Should only be for urgent fixes.

[kjbracey]

I think this is okay to go now

[cmonr]

/morph build

[mbed-ci]

Build : SUCCESS

Build number : 2832
Build artifacts/logs : http://mbed-os.s3-website-eu-west-1.amazonaws.com/?prefix=builds/7780/

Triggering tests

/morph test
/morph uvisor-test
/morph export-build
/morph mbed2-build

[mbed-ci]

Exporter Build : SUCCESS

Build number : 2461
Build artifacts/logs : http://mbed-os.s3-website-eu-west-1.amazonaws.com/?prefix=builds/exporter/7780/

[mbed-ci]

Test : SUCCESS

Build number : 2582
Test logs :http://mbed-os-logs.s3-website-us-west-1.amazonaws.com/?prefix=logs/7780/2582

[0xc0170]

And I would prefer if this goes out into the patch release, as the export builds are broken currently.

Me as well, will review the release label during today's gatekeeping

[kjbracey]

As this PR is built on previous full release and is all subtree-y, this PR is not pickable to 5.9.6.

But fear not, there's already a 5.9-rebased easily-pickable version here: #7789.

[NirSonnenschein]

/morph uvisor-test