Hi, On Wed Jan 14, 2026 at 1:02 AM CET, Otavio Salvador via lists.openembedded.org wrote: [...] > 1. Generic Configuration → BitBake Setup Template > > The term "Generic Configuration" does not immediately convey that this is a > reusable template file used as input to create a build environment. The > word "generic" can be interpreted as "basic" or "non-specialized" rather > than "reusable template." > > We suggest *BitBake Setup Template* as an alternative. This clearly > communicates that the .conf.json file serves as a template for creating > setups. > 2. Specific Configuration → BitBake Setup Instance > > Similarly, "Specific Configuration" does not clearly indicate that this is > the *result* of applying a template with user choices. The relationship > between "Generic" and "Specific" is not immediately obvious. > > We suggest *BitBake Setup Instance* as an alternative. The "Template → > Instance" pattern is widely understood by developers and immediately > conveys the relationship: a template is used to create an instance.
I like the Template/Instance suggestion, but I'm not sure about removing the word "configuration" out of these terms. We are speaking about the _configuration_ of a Setup after all, and "BitBake Setup Instance" could be misinterpreted as a running bitbake-setup execution. So maybe: Bitbake Setup Configuration Template Bitbake Setup Configuration Instance or simply: Configuration Template Configuration Instance Would be enough. Having "BitBake Setup" prefixing every occurrence of this term is going to be too much otherwise? What do you think? > 3. Nested "configurations" → Variant > > Within a BitBake Setup Template, there are nested "configurations" (e.g., > poky, poky-with-sstate) that represent predefined bundles of fragments and > settings. Using "configuration" here creates confusion since the term is > already heavily overloaded in the Yocto ecosystem. > > We suggest *Variant* as an alternative. This conveys that these are > different flavors or variations of the same base template, similar to how > distributions have variants or flavors. That sounds good to me, but would you also define a Variant as its own term (in the glossary)? [...] > 2. Allow Empty Variants in Templates > > Currently, bitbake-setup init requires the user to select a variant when > one is defined in the template. There is no option to skip this selection. I believe this is already achievable with the --skip-selection option? > Allowing templates without variants (or making variant selection optional) > would reduce the number of questions during setup, making the process > faster and more approachable for newcomers. Instead of no variants, maybe we just want to instruct the user to run: bitbake-setup init --non-interactive choice1 choice2 ... Another idea would be to make it possible to define default choices in an existing template? The documentation would then instruct the user to simply execute: bitbake-setup init --non-interactive which, with no choices passed on the command-line, would provide the user with the default variant (the Poky Setup). The default choices would still have to be printed on the console to make it clear to the user what was selected. [...] > 5. Fragment Discovery on OpenEmbedded Layer Index > > The OpenEmbedded Layer Index (https://layers.openembedded.org) is an > excellent resource for discovering layers. However, there is no equivalent > discovery mechanism for configuration fragments. > > Adding a tab or section for fragments would help users discover available > fragments and understand what problems they solve. Good idea IMO, as we already have machines and distros there, fragments would be a nice addition. Thanks for looking into this! Regards, Antonin -- Antonin Godard, Bootlin Embedded Linux and Kernel engineering https://bootlin.com
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#229334): https://lists.openembedded.org/g/openembedded-core/message/229334 Mute This Topic: https://lists.openembedded.org/mt/117262508/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
