my initial instinct was to merge them, but on reflection the potential problem I see with that is the apparent possibility for the release schedules/processes to diverge. what if we decide IoT releases don't follow the beta/final milestone approach that the release criteria are written around, for e.g.?

I've no opinion either way. I'm happy for QA to do what ever is the easiest for them, will leave QA and @pwhalen to work out the easiest for all involved.

@adamwill @kparal well before this ticket was opened, I changed some thing here. https://fedoraproject.org/w/index.php?title=Basic_Release_Criteria&oldid=567011
I am sorry, if it's something that shouldn't be there. Feel free to let me know thoughts, if it was at all okay.

@adamwill @kparal well before this ticket was opened, I changed some thing here.

Here's a proper link to the diff:
https://fedoraproject.org/w/index.php?title=Basic_Release_Criteria&type=revision&diff=567011&oldid=540393

I am sorry, if it's something that shouldn't be there. Feel free to let me know thoughts, if it was at all okay.

That's fine, let's make it part of this ticket. Whatever the solution is, let us then keep or adjust this change you just did. Next time, though, I think none of us should make sneaky changes to criteria pages. Send the diff either before you do it or after you do it to the test list (or some relevant ticket) so that others can verify it.

the potential problem I see with that is the apparent possibility for the release schedules/processes to diverge. what if we decide IoT releases don't follow the beta/final milestone approach that the release criteria are written around, for e.g.?

That's a good thought. I assume the milestones are the same for F32 at least. After that, they might diverge. If they have a different timeline, or if they want to skip Beta completely, is that a problem? If there are clearly marked sections "Fedora IoT" in our Basic and Final criteria, they don't need to make use of Beta, that's their choice. They don't even need to use the Basic criteria, if they don't want to have something guaranteed all the time (as much as our automation can guarantee that currently). But they'll always have at least Final releases, I think :)

The separate location would make a lot of sense in one particular case - if they wanted their criteria be completely standalone, and not subject to our "generic" QA criteria. I don't think that is a good idea, though.

I think we can quite safely use Basic and Final as long as there's a concept of releasing at all, yeah. Using Beta would be the most vulnerable to release process changes.

@adamwill We need to make a decision. I have a medium preference to merge it. If anything, it will make "search in all our criteria" easier, than knowing you have to follow some link in certain cases. But I leave it up to you, our ultimate criteria guru.

No issues with merging, and agree it will make searching for specific criteria a little easier.

@coremodule Can you please prepare a draft of merging the existing IoT criteria into our standard release criteria wiki pages? If it is not clear which requirements should go into which milestone, please work with IoT folks to figure it out.

@kparal Sure, I'll work on that this week.

After a discussion with @coremodule last week, we concluded we can wait a bit on this ticket, to see how IoT "official edition" status looks like in F33 (it was rough and unfinished in F32). Hopefully the details for F33 will be known well in advance this time.

@kparal what do you mean by "rough and unfinished"?

@kparal what do you mean by "rough and unfinished"?

Things like these:
https://pagure.io/fedora-iot/issue/24
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/EVX6OCY5HKW7HYS6VO5VFNW4C3ZNVOWS/

To this day, getfedora.org lists IoT and CoreOS as emerging editions, while the Council announced them to be primary. It's messy and we get very little response when we ask around. I hope this all gets much clearer in F33.

This is now being worked on by @coremodule. He'll propose a patch that would merge existing IoT criteria into our official wiki-based criteria, and remove/redirect the original location. I'm not sure if we'll make it before Beta, but we certainly want it done before F33 Final.

The temporary criteria-page changes have occurred and they are now up for review. Respectively, they are as follows: Basic, Basic diff, F33 Beta, F33 Beta diff, F33 Final, F33 Final diff [0] [1] [2] [3] [4] [5].

[0] https://fedoraproject.org/wiki/Coremodule/Basic_Release_Criteria
[1] https://fedoraproject.org/w/index.php?title=Coremodule%2FBasic_Release_Criteria&type=revision&diff=589189&oldid=589163
[2] https://fedoraproject.org/wiki/Coremodule/Fedora_33_Beta_Release_Criteria
[3] https://fedoraproject.org/w/index.php?title=Coremodule%2FFedora_33_Beta_Release_Criteria&type=revision&diff=589193&oldid=589192
[4] https://fedoraproject.org/wiki/Coremodule/Fedora_33_Final_Release_Criteria
[5] https://fedoraproject.org/w/index.php?title=Coremodule%2FFedora_33_Final_Release_Criteria&type=revision&diff=589191&oldid=589190

Thanks, I'll review this next week.

Basic:

{{hidden|header=Supported IoT devices|content=Supported IoT platforms are those listed by the IoT team [https://docs.fedoraproject.org/en-US/iot/release-criteria/ here].|headerstyle=background:#e5e5e5|fw1=normal|ta1=left}}

I know this is being discussed at #615, but I think we should at least change to link to go directly to https://docs.fedoraproject.org/en-US/iot/reference-platforms/ , because https://docs.fedoraproject.org/en-US/iot/release-criteria/ will get removed or redirected to https://fedoraproject.org/wiki/Fedora_Release_Criteria once this ticket is resolved (at least that's my current plan).

• See [https://docs.fedoraproject.org/en-US/iot/reference-platforms/ IoT reference platforms]

This is added under Installer must run. But it's already linked under Release-blocking images must boot and it is references there from Installer requirements. Do you think we need to repeat it here? I'd keep it just in one place only, and remove this line.

- Test cases: [[QA:Testcase_base_update_cli]], [[QA:Testcase_package_install_remove]]
+ Test cases: [[QA:Testcase_RpmOstree_Upgrade]], [[QA:Testcase_package_install_remove]]

(under Installing, removing and updating software). Why was Testcase_base_update_cli link removed? I don't understand. I think we should keep it there and just add the Testcase_RpmOstree_Upgrade one.

==== Zezere user provisioning (''IoT'')====
==== rpm-ostree (''IoT'') ====

I'd shove both of these under IoT Edition requirements, the same way we have the Server Flavor requirements section (let's rename it to Edition as well, the Flavor word is no longer used I believe). So the section would be at "2.7" level (see TOC). And of course we can then drop the ("IoT") suffix.

==== rpm-ostree (''IoT'') ====

Perhaps rename this to "rpm-ostree requirements", to make it sound the same way as the other sections, wdyt?

• When a new ostree is composed and made available, it must be possible to upgrade an existing host using rpm-ostree upgrade.
• After upgrading to the latest ostree, it must be possible to rollback to an older version using the rpm-ostree rollback command.
• It must be possible to rebase to a different IoT release by using the rpm-ostree rebase command.
• It must be possible to install additional software with rpm-ostree install command. Software installation must also include dependencies where necessary and installed software should provide the intended functionality.

This sounds fine, but the original formatting makes it clear what the command it, while the new text is without formatting. Please use syntax like it must be possible to upgrade an existing host using the <code>rpm-ostree upgrade</code> command to make it obvious what exactly the command is, thanks.

• It must be possible to rebase to a different IoT release by using the rpm-ostree rebase command.
• It must be possible to install additional software with rpm-ostree install command. Software installation must also include dependencies where necessary and installed software should provide the intended functionality.

We should consult the milestone of these two with IoT folks. They don't sound Basic to me. Rpm-ostree rebase is basically a system upgrade (e.g. F32->F33), correct? We currently have that in Beta, so it would make sense to put the IoT variant into Beta as well. Package layering also sounds like something that's not an absolute basic system functionality. I don't know how important it is, but it sounds Beta or Final to me. Again, please consult IoT folks (on the iot list), thanks.

It must be possible to install additional software with rpm-ostree install command. Software installation must also include dependencies where necessary and installed software should provide the intended functionality.

I wonder if we can sneak "Layered Package Installation" somewhere in there. In the original page, it's a headline, but we don't have it anywhere, and people might search for "layered" on our page, because it's a frequent term.

Beta:

=== [https://iot.fedoraproject.org/ IoT] Product requirements ===
These requirements apply only to the IoT product.

Damn, we're poor in consistency :-) In Basic we used the 'Flavor' word, in Beta we use the 'Product' word. Similarly to my review of the Basic diff, can you please use 'Edition' and also replace it everywhere else in the page? Thanks.

Final:

{{anchor|IoT-image-requirements}}
=== IoT image requirements ===

Again, I'd rename this to "IoT Edition requirements" (and also replace "Server product" with a "Server edition"). I'd also move this to the end, after Server requirements, as item 2.9 in TOC (Server becomes 2.8). I know there is "Cloud image requirements" section as 2.5, but I believe the reason for its placement (and naming - "image") is that because it really covers only the Cloud image status (it must be present and bootable in cloud env), and therefore it makes sense to couple it with installer requirements and place it before post-install requirements. However, these IoT requirements, similarly to Server ones, are post-install requirements, and therefore should be placed towards the end. Makes sense?

==== Greenboot ====
==== Clevis ====

I'd probably rename this to "Greenboot service" and "Automatic partition decryption" (or "unlocking") respectively, to make the titles a bit more descriptive.

Except for this bikeshedding (sorry), the rest looks OK to me.

@kparal, thanks for the feedback. I made all the changes you suggested, save for changing the "Basic" rpm-ostree criteria to "Beta". I am going to leave this as-is, as I spoke with @pwhalen about this and was told it was the IoT team's intention to have all rpm-ostree bits working at all times as IoT is ostree based and not having these functions would defeat the purpose of the edition.

Seeing as these changes have been available for feedback for two weeks, I have merged the criteria above into the mainline QA criteria list and will now close the ticket.

Thanks, I did a very small adjustment:
https://fedoraproject.org/w/index.php?title=Basic_Release_Criteria&type=revision&diff=590210&oldid=590190
https://fedoraproject.org/w/index.php?title=Fedora_33_Final_Release_Criteria&type=revision&diff=590209&oldid=590192

I'm not sure why we use custom anchors, honestly, because while it's great that they can be stable (renaming the criterion title doesn't change the anchor name), we don't really use them much, because getting the ToC-provided anchor is easier than our custom anchor. Perhaps @adamwill can enlighten us. Anyway, made anchors url-friendly.

I'm reopening this, because I think there's still one action remaining. We either need to remove the original criteria page completely:
https://docs.fedoraproject.org/en-US/iot/release-criteria/
or we need to redirect it to our pages, probably to:
https://fedoraproject.org/wiki/Fedora_Release_Criteria

Can you please make that happen, Goeff? Thanks.

@pwhalen, @pbrobinson, With the recent merge of IoT release criteria into the mainline QA criteria, we (QA team) find the inclusion of the "Fedora IoT Release Criteria[0]” on the IoT docs page to be dubious. If, at a later date, a change is made to one of the two, it will not be reflected in the other page without changing both, and we see this as potential to cause confusion down-the-line. We are therefore suggesting either editing the current IoT docs to link to the current mainline QA criteria page[1], or completely removing the current “IoT Release Criteria” page.

I have submitted a PR[2] to the IoT Release Criteria page removing the existing criteria and instead linking it to the Fedora Release Criteria, should you find that the better of the two options.

[0] https://docs.fedoraproject.org/en-US/iot/release-criteria/
[1] https://fedoraproject.org/wiki/Fedora_Release_Criteria
[2] https://pagure.io/fedora-iot/iot-docs/pull-request/57

+1 , things should only exist in one place.

This ticket is waiting on https://pagure.io/fedora-iot/iot-docs/pull-request/58 . I asked @coremodule to resolve it.

See https://pagure.io/fedora-iot/iot-docs/pull-request/60.

Done! PR is merged, changes are applied! See https://pagure.io/fedora-iot/iot-docs/pull-request/60.

:tada: :smiley: