Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
|WindowOverlay Icons 37 incompatible with GNOME 40
|Audrey Yeena Toskin <audrey>
|Audrey Yeena Toskin <audrey>
|Fedora Extras Quality Assurance <extras-qa>
|Fixed In Version:
|If docs needed, set a value
|2021-04-03 00:04:03 UTC
|RHEL 7.3 requirements from Atomic Host:
|Target Upstream Version:
|Bug Depends On:
Description Audrey Yeena Toskin 2021-03-12 01:02:44 UTC
Looks like someone already filed a bug report with the developer. https://github.com/sustmi/gnome-shell-extension-windowoverlay-icons/issues/23 And I'm updating my RPM package to mark version 37 as incompatible with GNOME 40. GNOME 40 implements some of WindowOverlay's features -- app icons are placed over the bottom edge of windows in the task overview by default now, though the appearance and placement isn't configurable as far as I can tell. Still, the new default might be sufficient to discontinue the extension, which would mean I would need to end-of-life this package for Fedora 34+. Hopefully the upstream decides either to discontinue or update before Fedora 34 gets out of beta.
Comment 1 Miro Hrončok 2021-03-20 11:39:52 UTC
Please make sure to retire the packages on the f34 branch at least 2 days before the final freeze if they are not fixed in time. If you do, also open a bugzilla for fedora-obsolete-packages to obsolete them. Keeping uninstallable packages in the (frozen) fedora repo brings no benefit, only confusing error messages.
Comment 2 Audrey Yeena Toskin 2021-03-21 02:20:15 UTC
Okay sure, I've added retiring any still-broken packages to my calendar. Rawhide and Beta users finding broken extensions obviously isn't great. I'm starting to think updating the dependencies, to show that WindowOverlay Icons and my other GNOME Shell extensions are incompatible with GNOME 40, was a mistake... but I'm not sure how I could have handled it better. In the past, I just didn't think to test on GNOME prereleases, and there were no reports on Bugzilla unless someone else complained. But leaving the package alone while waiting for upstream to fix -- allowing users to install and then discover they can't enable it -- seems like worse UX than just not allowing them to install it in the first place. And the process of retiring/obsoleting and then *unretiring* packages with every new version of GNOME seems kinda tedious. Since the GNOME APIs make extension-breaking changes so often, I think it would have been better if my packages weren't automatically rebuilt in the first place, when creating the f34+ branches. I don't suppose there's a way to *opt out* of those automatic rebuilds or something? That way I could wait and test to confirm each GNOME Shell extension actually works on the new GNOME version before any users can even see the possibly-broken packages.
Comment 3 Miro Hrončok 2021-03-21 10:52:28 UTC
It is possible if you work with releng, but not sure if worth it.
Comment 4 Audrey Yeena Toskin 2021-03-23 19:57:34 UTC
Any other ideas about how to handle this sort of situation, then? Retiring and unretiring my packages seems like it might be inevitable for GNOME 40 if the rest of the extension developers don't all update soon. And I'd rather avoid that for future GNOME versions.
Comment 5 Audrey Yeena Toskin 2021-04-03 00:04:03 UTC
Upstream developer sustmi has not pushed any updates, nor commented on that GitHub issue in a while. Since vanilla GNOME 40 now implements at least WindowOverlay Icons's main feature, I imagine maintaining the extension just to add slightly more display options doesn't seem worth the effort anymore. With the f34 final freeze approaching, I guess I will have to retire this package after all. Retired as of commit 28e3797b03.