Cmake issue

[Fabien Comte]

Hello,

With the last environnement version, there is a potential issue

CMake Error at F:/Git/YYY/Projects/ZZZ/TTT/nRF_SDK/ncs/zephyr/cmake/extensions.cmake:395 (file):
  Syntax error in cmake code at

    F:/Git/YYY/Projects/ZZZ/TTT/nRF_SDK/ncs/zephyr/cmake/extensions.cmake:395

  when parsing string

    F:\Git\YYY\Projects\ZZZ\TTT\nRF_SDK\ncs\nrf

  Invalid character escape '\G'.
Call Stack (most recent call first):
  F:/Git/YYY/Projects/ZZZ/TTT/nRF_SDK/ncs/zephyr/cmake/extensions.cmake:442 (zephyr_library_get_current_dir_lib_name)
  F:/Git/YYY/Projects/ZZZ/TTT/nRF_SDK/ncs/nrf/drivers/entropy/CMakeLists.txt:6 (zephyr_library_amend)

Do someone have an idea ?

[Einar Thorsrud]

The fix is here: https://github.com/NordicPlayground/fw-nrfconnect-zephyr/commit/0adfea4acb72d151237e2d65f89537a598119c25

[Torsten Rasmussen]

I agree, it is not good when things break, and we strive hard to reduce the risk of that happening. But even with CI and testing, things may slip through.

This is also the reason why there are:
- master branch, latest and greatest, but with additional risk.
- release tags, which has been thoroughly tested, e.g. https://github.com/NordicPlayground/fw-nrfconnect-nrf/releases/tag/v1.0.0

This give all developers a change to pick up the latest stuff as soon as it is ready, without waiting for an official release.

Or, developers can work with the official release tags, which is similar to older release versions.
https://github.com/NordicPlayground/fw-nrfconnect-nrf/releases

Both methods have their pros and cons, but if the requirement is a more thoroughly tested release, then I will advice to use the official tagged version.

[Fabien Comte]

I don t agree. There is a difference between risks and not working at all (just cannot be built). And if you try the tagged version 1.1.0rc1 it just not works so stop that attitude about explaining that a such quality epic fail is normal.

[Torsten Rasmussen]

I'm sorry I gave you a wrong impression with my last reply.
I don't know if this will help to clarify, but my intention with this answer is to provide both you and everyone else a better understanding of the new possibilities and risks associated with using github.

I see that you have worked with the nRF series since the beginning of nRF51, so you have also experienced the increased number of libraries , sample apps, and complexity of the SDK. With the existing SDK you face two issues with nRF5 with each release.
1) The hassle of merging code changes / bugfixes into you own VCS, because you don't have the code change history.
2) Having to wait for a new release before being able to get a bugfix.

With the use of github in the Nordic Connect SDK, NCS, those two issues should be much easier to handle.
But this also means that the developers at Nordic pushes the code directly to github for everyone to follow.
There is no internal repository, I see the exact same code as you do.

Now, this is a completely new way, both to you, and to us.
And we at Nordic also need to familiarize ourselves with this new way of working, cause all we do is being seen by customers.
Everything is fully transparent. Being fully transparent is one of the things I find great at Nordic.
From open access to the code - and now even on github, to devzone, and much more.

With nRF5 SDK the code is not exposed until the release is done - with NCS you have it immediately.
Of course developers test their code, and the CI is in place, but the CI is a trade of between how much to test, and how long does it take.
If CI was supposed to test each PR to the same level as a release it could spend hours, which would be a blocking factor in development.
However, a faster CI might not discover all issues, which is exactly why the still is the need for RC's before a release.
And RC1 is no more stable / unstable than master. It is tagged, and then the stabilization window starts. In this period all issues found is being fixed and afterwards a RC2 should be available. The RC2 and later should be more stable than master.
When no more issues are found in an RC, the final release is ready.
(all issues fixed in RCs also goes into master, but there could be new features going to master that is not accepted in the RCs afterwards)

Now, why would you care for `master` if you're developing a product?
`master` can be used for prototyping and examine new features in the making, BEFORE they enter a release.
It can be used to have early access to bugfixes.

If a bugfix is made to master, and you would like that fix in your codebase, then my suggestion will be to cherry-pick the commit(s) that fixes you issue. Do not switch to master completely, cause there could be new issues in master.

Now, taking a look back to the original issue that triggered this.
You consider that this issue should have been caught earlier, and I know those in charge of the CI constantly tries to improve and find the right balance.

But when such an issue occurs, then take a look at the process.
I was notified the 30th of October about the issue (I see that you reported it 29th, but after I left work)
The fix was committed on Oct. 30@14:19, and merged on October 31.

The final comment I would like to make, is that your long experience with using the SDK's makes your experiences and comments very valuable (to me at least). So I hope that you will continue to give feedback.
And I hope you understand that the new way of working is still new to most developers, but everyone is doing their best to make things better for everyone.