Time to talk about https://www.fedoraproject.org/wiki/Fedora_36_Final_Release_Criteria#Defau... again! Lots of desktop-app-related blockers this time around, and last time too. I think we're hitting a symptom-of-our-success problem here: increasing popularity and reviews noting how polished everything is makes us very much want to build on that. So I understand why this is here, including the expanded "all installed applications" Workstation criteria. But I think we might be using the wrong tool for some of this polish, and I think we also need to give ourselves some escape hatches. By way of concrete example, the Photos application is meant to be a photo organizer, so "album picker duplicates fields, preventing photo organization" https://bugzilla.redhat.com/show_bug.cgi?id=2081291 is easy to classify as failing the basic functionality test currently. But, it's really painful for that to be blocking the release. So, ideas for discussion: 1. I know we have had GNOME Test days, but this stuff didn't come up. Presumably, it would have if someone had happened to look at GNOME Photos. Can we formally go through https://www.fedoraproject.org/wiki/QA:Testcase_desktop_app_basic and https://www.fedoraproject.org/wiki/QA:Testcase_desktop_app_basic_others much, much earlier (probably when the GNOME pre-release is available), either as part of a test day or some other formal thing? Or is there something else going on here that I'm not looking closely enough to see? (Same for KDE and any other theoretical release-blocking desktops!) 2. "Basic functionality" seems scoped too broadly currently. I propose, for the release criteria, we change this to: A) "the app doesn't crash on launch", and B) "the app's behavior does not seem immediately embarrassing with a few minutes of playing around with it". As a barometer for "embarrasing", you can imagine me trying to explain the issue to a tech reporter, and weigh how awkward I will feel saying "this is fine" vs. how I will feel explaining that we delayed the whole release for that same issue. 3. Problems found which are not regressions should not be blockers. We're just hurting ourselves when we make this our forcing function to get something fixed. Some of these could be Prioritized Bugs, but I don't want to overload that too much. I propose that the teams responsible for blocking desktop deliverables keep their own prioritized lists of this kind of problem that the team agrees should be fixed for a good user experience. Not just add to the general queues of bugs or tickets, but specific lists of "application experience issues". These lists, of course, could include problems which also don't qualify for point #2 but which seem important. Like the Photos app issues. (This could also extend to "desktop experience issues" rather than just "application". Or for that matter there could be a similar mechanism for non-desktop blocking deliverables.) I could be convinced either way on having these in the teams' issue trackers in pagure or whereever _or_ having it as more targets in the blockerbugs app. I tend towards the latter: I think it might help with the problem where blockers feel like the only obvious way to bugs tracked and fixed. But either way, there should be lists! 4. Desktop application problems discovered during at the last minute should not be blockers. If the problem is really going to impact a lot of people, it should have been discovered in the beta. (Exception for _new_ regressions, of course.) By the time we're in final freeze, this ends up being hero work for everyone. I don't know how to phrase this in a way that doesn't make Adam sad with me, but maybe something like: Desktop application blockers discovered during the final freeze are automatically waived unless the relevant Spin or Edition team decides otherwise. That lets us still block if something is really bad and just happened to slip through. 5. Okay, and... bigger: we should aim for more approaches which let us decouple as much as possible from the Release. (My grand hope is that we can release every deliverable on its own schedule, but I also understand the _highly aspirational_ nature of that idea. But...) What if we could just easily ship GNOME Photos from GNOME 41 until a fix is found in the updated one? -- Matthew Miller <mattdm(a)fedoraproject.org&gt; Fedora Project Leader