To add some context, the 32-bit ARM minimal image was a release blocking image. 64-bit was never added as a blocking image, so once we dropped 32-bit ARM, there was no remaining minimal image on the blocking list.

Adding the 64-bit image as a replacement makes sense, but that was not in the proposal. (Probably because no one explicitly thought about including that). I have no objections to adding it from a program management perspective if the ARM SIG thinks it's sugnificantly valuable for their use cases. The question is if the minimal image offers a sufficiently important use case for aarch64 users not covered by the Cloud, IoT, Server, and Workstation images which are aarch64 blockers.

The question is if the minimal image offers a sufficiently important use case for aarch64 users not covered by the Cloud, IoT, Server, and Workstation images which are aarch64 blockers.

I think the real question is "Does the minimal image ever fail when the Cloud, IoT, Server and Workstation blocking images succeed, and if so, why?"

"I think the real question is "Does the minimal image ever fail when the Cloud, IoT, Server and Workstation blocking images succeed"

Yes. That's literally the situation that resulted in me filing this ticket. See the linked bug report.

"if so, why?"

The answer boils down to "well, because it's minimal". A thing was minimized off of it which made localed sad (after a change to the localed code caused the sad-making thing to happen before an early bailout which we were hitting previously).

+1 to make it blocking

Honestly, I don't want to add more blocking media if we don't have an explicit use-case for it. Does the ARM SIG want to own this?

I didn't have an opinion before reading the discussion, and I still don't have an opinion afterwards. I'll let others make the choice here.

+0

In the ARM ecosystem, the ISOs are relatively useless compared to the disk images. While I don't see a particular use-case for it, if there's someone willing to give it the care and feeding required as a release-blocking deliverable, I don't have a problem with it.

+1

I suppose there's a question how often ARM users use the disk images vs. the installer ISOs. I don't know the answer to that question.

For SBC style devices like the Raspberry Pi the raw images are the primary means over the installer so I would almost say they're used a lot more than the installer, they're definitely as important.

I had honestly thought that we had discussed this previously

Honestly, I don't want to add more blocking media if we don't have an explicit use-case for it. Does the ARM SIG want to own this?

We have always owned it even prior to this so I don't expect that to change as a result of this.

The question is if the minimal image offers a sufficiently important use case for aarch64 users not covered by the Cloud, IoT, Server, and Workstation images which are aarch64 blockers.

They are used a lot for devices like the Raspberry Pi, users also use them as basis to build up other images so they're pretty widely used. For me personally I use them an order of magnitude more than all the other images.

+1 to make it blocking.

It sounds like there is now a consensus between QA and ARM SIG, and any questions of responsibility and importance are generally resolved. Does anyone still have unresolved questions or concerns?

It sounds like there is now a consensus between QA and ARM SIG, and any questions of responsibility and importance are generally resolved. Does anyone still have unresolved questions or concerns?

I’ll take the silence as a “no” and throw in my +1.

After slightly more than a week, the result is:
APPROVED (+4,1,0)

Announced.

Added to release blocking list for F38 and beyond.