-
Notifications
You must be signed in to change notification settings - Fork 94
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Better config management #21
Comments
https://docs.espressif.com/projects/esp-idf/en/v4.4.4/esp32s3/api-reference/kconfig.html#using-sdkconfig-defaults There is an option to generate this sdkconfig.defaults automatically but it's only in ESP-IDF v5: idf.py save-defconfig |
Curious why not a web UI configuration like other ESP8266/32 projects where you connect to an open WiFi network to enter actual WiFi details and then after that you can change all the other configuration. With this approach a firmware can be distributed for those who are much less technically inclined. Obviously if providing a binary firmware, a checksum should be provided as well. |
This issue is intended to track the configuration of the build system. No matter where a firmware image comes from, or how it's configured by the end user, it needs to be built by a build system somewhere. We are evaluating a variety of approaches for easier end-user onboarding and configuration such as those mentioned on the wiki. We have a larger issue than a firmware image and checksum. All a checksum assures is that it wasn't modified from the time we built and when the checksum was generated. It in no way assures the user that we didn't modify the code to stream their audio to some server we host (or who knows what), build it, generate a checksum, and hand them a binary. The ideal approach is to use reproducible builds which we are also investigating given our focus on user privacy as a voice assistant. We take our responsibility of powering a device with microphones present in the private lives of our users very, very seriously. We understand our primary differentiator is the trust of our users. For issues such as these we are going to approach them very methodically, deliberately, and with the involvement and feedback of the community and user base. |
Oh apologies, I didn't realize the intention for this. |
Use sdkconfig.defaults instead of maintaining a full sdkconfig in git. The sdkconfig resulting from running `./utils.sh install` with this commit should be the same as before this commit. We can re-evaluate some of these values at a later stage, but we should first start with identical sdkconfig. This will make bisecting easier. If we were to change sdkconfig values in this commit, reverting the commit would completely revert the use of sdkconfig.defaults. Fixes: #21
Use sdkconfig.defaults instead of maintaining a full sdkconfig in git. The sdkconfig resulting from running `./utils.sh install` with this commit should be the same as before this commit. We can re-evaluate some of these values at a later stage, but we should first start with identical sdkconfig. This will make bisecting easier. If we were to change sdkconfig values in this commit, reverting the commit would completely revert the use of sdkconfig.defaults. Fixes: #21
Instead of depending on using one gigantic sdkconfig.willow we should probably have at least three:
The text was updated successfully, but these errors were encountered: