FinalFE +1

By a strict reading of our criteria, I should probably vote +1 for a blocker here, but this feels so inconsequential that I just... can't.

FinalFE +1

Blocker vote comes down to whether we consider this "basic functionality", which gets pretty subjective. I'm probably a weak +1 blocker but I'd also probably vote to waive it as a late blocker.

Blocker vote comes down to whether we consider this "basic functionality", which gets pretty subjective. I'm probably a weak +1 blocker but I'd also probably vote to waive it as a late blocker.

Even if we'd found it three weeks ago, I think I would have disagreed with it as a blocker. It just doesn't pass the "last blocker at Go/No-Go" test for me.

FinalFE +1
FinalBlocker -1

FinalFE +1
FinalBlocker -1

AGREED AcceptedFinalFE

The following votes have been closed:

• Accepted FinalFreezeException (+4, 0, -0)
  • +1 by sgallagh, adamwill, kevin, frantisekz

settings alarms with GNOME Clocks does not appear to be a basic or critical system functionality.

FinalBlocker -1

It just doesn't pass the "last blocker at Go/No-Go" test for me.

There is no such test. But you can propose it as an official rule, if you can put it into writing.

settings alarms with GNOME Clocks does not appear to be a basic or critical system functionality.

It's not about system functionality, but app functionality. The criterion is here:
https://fedoraproject.org/wiki/Fedora_41_Final_Release_Criteria#Default_application_functionality

GNOME Clocks has 4 different types of clock operation, all of them are very visible in its top bar (world clock, alarms, stopwatch and timer). And one of those is broken - alarms. I don't see any way around it, the basic functionality criterion is violated.

I agree that it feels minor to block the whole release. One easy way out is to apply the last minute blocker exception (which currently speaks about 5 days, not minutes), provided that we give F41 a GO this week. But if people feel this kind of bug should never block the release, we should modify the criterion instead (we can do it post-release, not right now). Or create some new general rule/exception, like Stephen likes to mention. I would love to hear concrete suggestions.

Btw, compared to the past, we have much weaker requirements/opinions on what "basic functionality" means. That was on request from the Workstation WG, who wanted to keep it applied to all apps, but no so strict, especially for apps with lots of different functionality (e.g. Nautilus). But for very simple apps like gnome-clocks, I don't see where to lower the bar even more. So perhaps, if people don't want to block on it (and I'd like to see opinions from the Workstation WG), a different approach is needed. All I want is a systematic approach, because we created release criteria to avoid constant arguing over how important is X or Y, and I don't want to go back to that era.

At this moment, it seems that this warrants a blocker:
FinalBlocker +1

FinalFE +1

It's not about system functionality, but app functionality. The criterion is here:

It's basic functionality is to "display clock/world clock", that's it, for me at least, and it works.

I agree with Kamil that we need consistency here. And by the way, if I have ever used Clocks on desktop, it was to set up the alarm so that I would not miss something, so I must back it with

FinalBlocker +1

However, we can decide to waive it and document it is a common bug, if we so want.

I agree with Kamil: even though blocking on this seems harsh, the basic functionality test is very clearly failed.

FinalBlocker +1

(I also agree that a late blocker exception seems appropriate. It's not so horrible for alarms to be broken in the initial release so long as we fix it promptly with an update.)

It just doesn't pass the "last blocker at Go/No-Go" test for me.

There is no such test. But you can propose it as an official rule, if you can put it into writing.

I call it a "test" rather than a "rule" because it's about the definition of a blocker. A blocker bug is one that we would refuse to ship the distribution over. Yes, we have special cases like "learned about it too late" and "practically impossible to fix in a short time" that are still blockers, but they get deferred to the next release and block that release.

My "test" is whether a ticket is sufficiently important that we must delay the release of Fedora by a week (or more) unless it's fixed. If we know in advance that we'd reasonably decide to waive it if it's the only bug not fixed at the time of the Go/No-Go, then it's by definition not a blocker.

whether a ticket is sufficiently important that we must delay the release

Yes, that's exactly the definition of a release criterion. And we decided that an app basic functionality breakage IS sufficiently important. In Workstation for any pre-installed app. If you don't agree, then we might need to re-evaluate that criterion.

What you're proposing is "let's ignore the criteria if we agree", but provide no guidance on how to agree (how to judge the "importance"). Which pulls us back into opinion battles without any justification grounds. You might not care about gnome-clocks, desktop folks might not care about active directory.

(At the same time, a blanket opinion-based right to waive anything might still be a workable approach, if the owners of the product decide to waive it, not everyone. So e.g. if Workstation WG decide that a problem in gnome-clocks is OK to not block, this time. That would make the QA life a bit harder because of decreased consistency, but at least the potential for conflict between multiple parties would be lessened).

It's basic functionality is to "display clock/world clock", that's it, for me at least, and it works.

It's homepage seems to disagree:

A simple and elegant clock application. It includes world clocks, alarms, a stopwatch, and timers.
* Show the time in different cities around the world
* Set alarms to wake you up
* Measure elapsed time with an accurate stopwatch
* Set timers to properly cook your food

https://apps.gnome.org/Clocks/

FinalFE +1
FinalBlocker -1

FinalFE +1
FinalBlocker -1

It's easy to provide this as a zero day update.

FinalFE +1
FinalBlocker -1
0Day +1

AGREED RejectedFinalBlocker

Discussed during the 2024-10-24 Go/No-Go blocker review meeting [1]:

Consensus could not be reached that this violates the proposed criterion "https://fedoraproject.org/wiki/QA:Testcase_desktop_app_basic" as discussed by the stakeholders. While alarm is an important function of a Clocks application, it wasn't deemed that it fits the basic functionality criterion.

[1] https://meetbot.fedoraproject.org/meeting_matrix_fedoraproject-org/2024-10-24/f41-final-go-no-go-meeting.2024-10-24-17.02.log.html

The following votes have been closed:

• Rejected FinalBlocker (+3, 0, -6)
  • +1 by kparal, lruzicka, catanzaro
  • -1 by kevin, frantisekz, augenauf, vwbusguy, pbrobinson, geraldosimiao

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