I'm with @bcotton and think we should communicate such things trough the Fedora change process. Obviously, it means there will be more popele complaining about it, but I think that's fair.

@churchyard I'm not clear what the next step is. Will this get discussed by FESCo on the next meeting? Or are you waiting for @pwhalen to create the Change proposal? As I understand it, it's too late now for change proposals for F32. But our current consensus with ARM team was that we'd like to see it changed for F32 already. (We were also not aware that changes in the release blocking list require change proposals, otherwise this would have probably been done way earlier).

I would very much welcome a self-contained change page for F32, a so called "late change". We can approve it even now, but the advantage is users will get a proper heads-up (which can be important if you're a user of the hardware in question).

@kparal I merely presented my own opinion. I have not decided to vote this -1 yet, but I won't +1 it without a change proposal. Other FESCo members can have different opinions.

Do you want this discussed by FESCo on the next meeting?

Also, we can approve changes that arrive late, if that is the consensus.

@kparal I merely presented my own opinion. I have not decided to vote this -1 yet, but I won't +1 it without a change proposal. Other FESCo members can have different opinions.

I'll get a change proposal up today.

Do you want this discussed by FESCo on the next meeting?

Yes please.

I would very much welcome a self-contained change page for F32, a so called "late change". We can approve it even now, but the advantage is users will get a proper heads-up (which can be important if you're a user of the hardware in question).

We're not stopping producing the images, and the bits for aarch64 have been produced for a number of releases, it's purely a change of which pieces block the release, so it's just a QA process change.

To be a stickler: it's not purely QA. The release process, including blocker decisions, is a collaboration between QA, releng, devel and project management, even if sometimes it's only QA that shows up to the meetings. :D

Also this will (should, at least) involve a small amount of work for other folks: releng will probably want to tweak the pungi config to reflect the change (so compose no longer fails on 32-bit ARM Xfce images, but does fail on 64-bit ARM Workstation images), and @bcotton would be responsible for updating the wiki page that tracks what's blocking.

Change proposal: https://fedoraproject.org/wiki/Changes/ARM_Release_Criteria_Changes

+1

Thanks for the change proposal. Could you mark it as ready for the wrangler, so @bcotton can process it ASAP?

I'm likely +1 for this, but I'd also like to hear from the Workstation WG if they are okay with making aarch64 blocking. I expect that they'll be okay with it so long as the ARM SIG is maintaining it, but it would be good to hear from them.

Pinging @catanzaro @mclasen @aday @ngompa @kalev @chrismurphy @petersen @tpopela @otaylor @langdon

If ARM SIG is maintaining it, it's not really a Workstation WG product. So I don't see why we should be involved. It also probably means we should probably strip it of the Workstation branding, since we don't do anything for ARM.

If ARM SIG is maintaining it,

I probably should have said "co-maintaining". As in, if the issue is ARM-centric, they will deal with it.

it's not really a Workstation WG product. So I don't see why we should be involved. It also probably means we should probably strip it of the Workstation branding, since we don't do anything for ARM.

I assume they very much want to retain the branding, which is why I pinged the Workstation WG.

I don't have much of a problem with this change, though I don't know what the justification would be for supporting AArch64 desktops. Are we even doing anything meaningful there? My understanding is that Fedora ARM is largely focused on the IoT case, not the "people can use it for normal stuff" case.

I'm also not terribly convinced that IoT and CoreOS add that much more to the release engineering workload (as they don't do a lot on their own...), but that's not my call.

I assume they very much want to retain the branding, which is why I pinged the Workstation WG.

Where in the proposal is there any part that states the arm sig is intending on changing anything to do with the branding for the arm side of things?

Where in the proposal is there any part that states the arm sig is intending on changing anything to do with the branding for the arm side of things?

@pbrobinson Sorry, I'm not absolutely sure what you are saying here. Could you state directly what branding you expect this deliverable to have?

The position of the Workstation WG currently is that we don't care about ARM. We don't do anything with it or for it. I was not aware until recently that Fedora even produced a Workstation image for ARM. I'm happy to be convinced otherwise, but if we don't care about ARM, I don't know why we're willing to have the branding of our working group associated with it.

I don't have much of a problem with this change, though I don't know what the justification would be for supporting AArch64 desktops. Are we even doing anything meaningful there? My understanding is that Fedora ARM is largely focused on the IoT case, not the "people can use it for normal stuff" case.

Well clearly you have not been following a lot of what the arm sig has been up to. The arm SIG covers an order of magnitude more than IoT, and does a lot of things from kernel, toolchain, various device enablement including things like arm laptops.

I'm also not terribly convinced that IoT and CoreOS add that much more to the release engineering workload (as they don't do a lot on their own...), but that's not my call.

I don't know if this is your wording, but IoT currently does all the release engineering related tasks, it's also COMPLETELY unrelated to this ticket.

Where in the proposal is there any part that states the arm sig is intending on changing anything to do with the branding for the arm side of things?

@pbrobinson Sorry, I'm not absolutely sure what you are saying here. Could you state directly what branding you expect this deliverable to have?

Exactly the same as that of Workstation, we have no intention to change anything from the vanilla Workstation experience etc.

@pbrobinson Sorry, I meant that the variants themselves don't have a lot in them. There's not much that those editions do. Not the IoT and CoreOS WGs (I know those people do a lot!).

Where in the proposal is there any part that states the arm sig is intending on changing anything to do with the branding for the arm side of things?
@pbrobinson Sorry, I'm not absolutely sure what you are saying here. Could you state directly what branding you expect this deliverable to have?

Exactly the same as that of Workstation, we have no intention to change anything from the vanilla Workstation experience etc.

Thank you for clarifying. I wanted to be sure my assumption matched reality.

The position of the Workstation WG currently is that we don't care about ARM. We don't do anything with it or for it. I was not aware until recently that Fedora even produced a Workstation image for ARM. I'm happy to be convinced otherwise, but if we don't care about ARM, I don't know why we're willing to have the branding of our working group associated with it.

Since aarch64 uses the same pointer size and endianness as x86_64, I expect minimal compatibility issues (certainly fewer than we had with i686). I'm fine with it being called Fedora Workstation. It's understood that architecture-specific bugs may exist. aarch64 is extremely popular (Raspberry Pi) and it's clearly the future of ARM, so if we had to support a second architecture in addition to x86_64, certainly aarch64 would be the least-disruptive choice. If we were proposing something like s390x, my opinion would be different....

That said, I agree the Workstation WG is likely not very interested in this (as discussed in fedora-workstation#128). I'd expect ARM folks will handle ARM-specific bugs.

Can we please move this discussion to https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/5UD4P6K76AHTMRLSZ3AMIEO5RZXODNZH/ ?

As I understood it,

It is not just the name or branding, it is the actual Workstation spin, which is managed by Workstation WG, which we are building for ARM architecture.

If we propose to add Workstation on ARM64 to be release blocking, this would mean that Workstation WG shouldn't make changes to Workstation spin, which are not compatible with ARM architecture.

This would mean that unlike today, Workstation WG should actually start to care about ARM when making changes. It is not about bugs alone, but also about future changes. features like earlyoom for example.

Of course the expectation is that there will be no such changes which are incompatible with ARM64. But in those rare cases, where there actually are, we need this agreement.

And we need Workstation WG to approve it.

As discussed in https://pagure.io/fedora-workstation/issue/128, it's unlikely that Workstation WG would agree to care for aarch64-specific issues. We're purely focused on x86_64.

Since aarch64-specific issues would be unusual, I'm not sure this is a problem as long as there are people caring for aarch64 issues when they arise.

And we need Workstation WG to approve it.

If it comes down to us needing to care and approve the AArch64 variant, I'm more likely to ask that the Workstation branding be removed from the GNOME variant for AArch64. I really don't see the WG caring that much about AArch64, especially given how bad the experience currently is for the majority of Desktop-on-ARM users (i.e. users of Fedora on single board computers).

The IRC log indicates this ticket was intended to be accepted, not rejected.

https://meetbot.fedoraproject.org/fedora-meeting-1/2020-02-17/fesco.2020-02-17-15.00.html

#2339 Proposal to change ARM Release Blocking Criteria - Drop XFCE (32bit), Add Workstation(64bit) - https://fedoraproject.org/wiki/Changes/ARM_Release_Criteria_Changes (dcantrell, 15:23:34)
AGREED: APPROVED (+7, 0, -0) (dcantrell, 15:35:33)

@psabata You actually voted +1 in that meeting :grinning:

@bcotton , https://fedoraproject.org/wiki/Releases/32/ReleaseBlocking needs updating to reflect this change. The release criteria and validation matrices also need updating; I will handle that.

PR's to change things in pungi config for rawhide and f32:

https://pagure.io/pungi-fedora/pull-request/808
https://pagure.io/pungi-fedora/pull-request/807

Updated the Release Blocking page. I kept the 8 GB max size, let me know if I need to adjust it.