@leandrolanzieri I have a more general question. A number of configurations are currently being exposed by a number of PRs. All these PRs follow the same scheme, they just replace all occurences of XYZ_DEF with CONFIG_XYZ_DEF in source code, documentation and makefiles.

For example

#ifndef ESP_WIFI_SSID
#define ESP_WIFI_SSID    "RIOT_AP"
#endif

would become

#ifndef CONFIG_ESP_WIFI_SSID
#define CONFIG_ESP_WIFI_SSID    "RIOT_AP"
#endif

My concern is that such a change might also affect the Makefiles in user projects. Since ESP_WIFI_SSID has been documented as a required setting for using the WiFi interface on ESP boards, I have already seen these definitions in a couple of Makefiles of some user projects.

So I wonder if there wouldn't be an acceptable approach to introduce Kconfig variables without changing all source files, the Makefiles and the documentation, e.g.,

#if !defined(ESP_WIFI_SSID) && defined(CONFIG_ESP_WIFI_SSID)
#define ESP_WIFI_SSID    CONFIG_ESP_WIFI_SSID
#elif !defined(ESP_WIFI_SSID)
#define ESP_WIFI_SSID    "RIOT_AP"
#endif

While it would make each definition more complex, it would preserve the compatibility with previous definitions.

So I wonder if there wouldn't be an acceptable approach to introduce Kconfig variables without changing all source files, the Makefiles and the documentation, e.g.,

#if !defined(ESP_WIFI_SSID) && defined(CONFIG_ESP_WIFI_SSID)
#define ESP_WIFI_SSID    CONFIG_ESP_WIFI_SSID
#elif !defined(ESP_WIFI_SSID)
#define ESP_WIFI_SSID    "RIOT_AP"
#endif

I think it makes sense to actually do the changes in the code and documentation, and translate the current macros to the new ones:

#ifndef ESP_WIFI_SSID
#define ESP_WIFI_SSID    "RIOT_AP"
#endif

#ifndef CONFIG_ESP_WIFI_SSID
#define CONFIG_ESP_WIFI_SSID   ESP_WIFI_SSID
#endif

This way if the user uses the new names, they take precedence, if not we fall back to the legacy. We should also start a deprecation process of the old macros by announcing this in the documentation.

What do you think @gschorcht?

@gschorcht I addressed your comments

So I wonder if there wouldn't be an acceptable approach to introduce Kconfig variables without changing all source files, the Makefiles and the documentation, e.g.,

#if !defined(ESP_WIFI_SSID) && defined(CONFIG_ESP_WIFI_SSID)
#define ESP_WIFI_SSID    CONFIG_ESP_WIFI_SSID
#elif !defined(ESP_WIFI_SSID)
#define ESP_WIFI_SSID    "RIOT_AP"
#endif

I think it makes sense to actually do the changes in the code and documentation, and translate the current macros to the new ones:

#ifndef ESP_WIFI_SSID
#define ESP_WIFI_SSID    "RIOT_AP"
#endif

#ifndef CONFIG_ESP_WIFI_SSID
#define CONFIG_ESP_WIFI_SSID   ESP_WIFI_SSID
#endif

This way if the user uses the new names, they take precedence, if not we fall back to the legacy. We should also start a deprecation process of the old macros by announcing this in the documentation.

What do you think @gschorcht?

That is, we already make all changes when exposing the configuration, but keep some legacy definitions for compatibilty reasons in the way you suggest and declare them as deprecated in the documentation? I could live with that approach.

That is, we already make all changes when exposing the configuration, but keep some legacy definitions for compatibilty reasons in the way you suggest and declare them as deprecated in the documentation?

Exactly

@fjmolinas I think it would be good to have this in the release, since we are introducing Kconfig for several modules. Could you take a look as well?

And I tested make doc. No errors and the site looks good

@PeterKietzmann thanks for reviewing, I addressed your comments.

Offline @leandrolanzieri asked if this one could be backported to have the new kconfig doc present in the release branch. AFAIK documentation falls in the category of features that can be backported so go ahead.

@PeterKietzmann fixed and squashed

Green lights. ACK & go

Backport provided in #13153

Since it's not a bug, just documentation, it doesn't need to be backported (and the corresponding label was not set).

Since it's not a bug, just documentation, it doesn't need to be backported (and the corresponding label was not set).

@fjmolinas agreed that documentation improvements can be backported for the release

Doesn't make sense (sorry @fjmolinas): the online documentation always points the latest master, so the new section should be online soon. From my experience, documentation PR doesn't fall into the needs backport case, only bug fixes do.

Doesn't make sense (sorry @fjmolinas): the online documentation always points the latest master, so the new section should be online soon. From my experience, documentation PR doesn't fall into the needs backport case, only bug fixes do.

The hard-feature free\e email we send out says:

We've created the [YYYY.MM] release branch, so we are now officially in
feature freeze. This means from now only bugfixes will be backported to
the `[YYYY.MM]-branch`. If anyone has any bugfixes or documentation
improvements that they feel should be part of this release please let me know.

Online documentation is not versioned, so if I want to see documentation that matches my version of RIOT I would check the documentation in code. I see no issue with backporting this.

The hard-feature free\e email we send out says:

Not saying its a rule, but it seems like the closest thing to it that we have IMO.