Description of problem: If you boot a Server/Everything ISO, the boot menu only says "Install Fedora 40". It doesn't identify neither edition nor milestone. This is contrasted with the boot menu for Workstation/KDE, where it says "Start Fedora-Workstation-Live 40_Beta" (both edition and milestone are included). The following release criterion says: "Any component which prominently identifies a Fedora release version number, code name, milestone (Beta, Final), or Edition (Workstation, Server, CoreOS) must do so correctly. " https://fedoraproject.org/wiki/Basic_Release_Criteria#Self-identification It looks like Server/Everything images might violate this criterion. (I'm aware that the criterion doesn't say that edition+milestone must be included each time a version is included, but in all other areas this seems to be the case. And currently the boot menu seems misleading, implying a final version by not even including the "beta"/"prerelease" term). This issue is present for both BIOS and UEFI boot mode. PS: I haven't checked all release-blocking deliverables, like e.g. Cloud images. More images than those listed here might be affected. PS2: This is not a new problem. I checked Server images for F39 Beta and F38 Beta, and both of them look the same as described here. Version-Release number of selected component (if applicable): Fedora-Server-dvd-x86_64-40_Beta-1.10.iso Fedora-Server-netinst-x86_64-40_Beta-1.10.iso Fedora-Everything-netinst-x86_64-40_Beta-1.10.iso
Created attachment 2022897 [details] server beta boot menu
Created attachment 2022898 [details] workstation beta boot menu
This broke between Fedora 23 and Fedora 24. Let nobody say we are not right on top of things here in the Fedora Quality team!
discussed at the F40 Beta Go/No-Go meeting, acting as a blocker review meeting, on 2024-03-21 - https://meetbot-raw.fedoraproject.org/meeting_matrix_fedoraproject-org/2024-03-21/f40-beta-go-no-go-meeting.2024-03-21-17.03.html . We decided to reject this. The entry doesn't outright *misidentify* the compose's number or milestone - it doesn't claim it's a final release, it just fails to note it's a Beta. It gets the release number right. We noted that the user will inevitably encounter several places later where the Beta status is noted, and in 16 releases, this does not appear to have actually confused anyone, which is what the criterion intends to avoid happening.
What is the right component to reassign this to, if we want to improve the current state? Pungi?
lorax.
actually...well, this is a bit more complicated than I thought. we *could* 'fix' this in lorax by using the product.isfinal property and appending "Pre-release" to boot entries if it isn't final, but that's not what we were doing before, I don't think. We were just telling lorax the "version" was something like "23_Beta_RC1" or "23_Beta_TC5", not "23". In 24, we changed to just telling lorax the version was "24", even for pre-releases. I think this is actually a Pungi 4 change, as according to some idiot's blog - https://www.happyassassin.net/posts/2016/02/15/pungi-4-the-new-generation-of-the-fedora-compose-tools-and-what-it-means-for-qa/ - Fedora 24 was the release where we switched to Pungi 4. Before that, we had the whole thing with TCs and RCs, and what we did was this: * For Beta TCs, we told lorax the "version" was e.g. "23_Beta_TC2" * For Beta RCs, we told lorax the "version" was e.g. "23_Beta" * For Final TCs, we told lorax the "version" was e.g. "23_TC3" * For Final RCs, we told lorax the "version" was e.g. "23" For nightlies, we just set the "version" to "23". We *could* go back to doing something like that; for Beta candidates we could tell lorax the "version" is "40_Beta" or "40 Beta". But it does have consequences beyond just the boot menus. The string is also used on the first page of anaconda (it says "WELCOME TO FEDORA (VERSION)"), and in the top-right corner ("FEDORA (VERSION) INSTALLATION"). It also gets written into the .treeinfo and .buildstamp files. I guess anything that used those files at least up to Fedora 24 should be OK with finding a version string that isn't just an integer any more, but it's *possible* something's been added since then which doesn't expect it...
This should already be possible. It is possible to set version in the lorax_options section: It would go here: https://pagure.io/pungi-fedora/blob/f40/f/fedora.conf#_87
Yes, I know it's possible, the question has become more "is it *desirable*, and if so, when should we do it".