#1849 [gdm] Support for GNOME X sessions was dropped outgrowing the previously accepted scope of the Wayland transition | rhbz#2358741
Closed by blockerbot. Opened by blockerbot.

Bug details: ** https://bugzilla.redhat.com/show_bug.cgi?id=2358741 **
Information from BlockerBugs App:
2358741

Current vote summary

Commented but haven't voted yet: frantisekz, adamwill

The votes have been last counted at 2025-04-10 17:34 UTC and the last processed comment was #comment-965208

To learn how to vote, see:
https://pagure.io/fedora-qa/blocker-review
A quick example: BetaBlocker +1 (where the tracker name is one of BetaBlocker/FinalBlocker/BetaFE/FinalFE/0Day/PreviousRelease and the vote is one of +1/0/-1)


I'm not certain how I feel on this one. I understand the need for a discussion but is it worthy of being a blocker? I'm on the fence but I cannot see anything in the criteria that says X11 MUST be supported. I'll go with my gut and say.

FinalBlocker -1

I'm not certain how I feel on this one. I understand the need for a discussion but is it worthy of being a blocker? I'm on the fence but I cannot see anything in the criteria that says X11 MUST be supported.

Yeah, the outcome can be just a simple release note so users know what to do if they want to run Gnome/Xorg, or statement, that this is no longer supported, depending on what stakeholders think/vote for.

I don't think the blocker process is necessarily the correct venue for this. I can't see a release criterion it violates. We already weren't shipping the X-enablement packages on media, so we can't really say that fixing this would make the media work on systems where Wayland doesn't work (assuming we can even identify any). The upgrade case can't apply because the X-enablement packages aren't default, and the upgrade criteria say "For each one of the release-blocking package sets, it must be possible to successfully complete a direct upgrade from a fully updated, clean default installation of each of the last two stable Fedora releases with that package set installed." - note clean default installation. That limitation is intentional.

I don't see how we can plausibly vote +1 to this as a blocker under the criteria. It feels more like an 'engineering design' decision, which is FESCo's province. FESCo has the power to simply declare bugs to be blockers.

So I'm saying: file a FESCo ticket for this, ideally now, so FESCo at least has a vague chance to make a decision on this ahead of or during the go/no-go meeting. If we just bring it up at the meeting, I doubt there'll be a quorum of FESCo members present, who could legitimately declare it a blocker.

just waiting here to join the go/no-go meeting tomorrow (today) :blush:

We don't block on incomplete Changes, and we don't block on overdone Changes either (unless it hits one of our criteria) :-) If you think we shouldn't release in this state, please file a FESCo ticket regarding an unannounced important change.

FinalBlocker -1

Metadata Update from @blockerbot:
- Issue status updated to: Closed (was: Open)

Release F42 is no longer tracked by BlockerBugs, closing this ticket.

Log in to comment on this ticket.

Metadata