FinalBlocker +1

Depending on the extent of the impact, I may be willing to waive it under the "late blocker" exception, but it's hard to argue against this being a blocker.

I'm actually not sure, because it's probably triggered only in some specific circumstances. It doesn't apply to all crashes. Also, if this turns out to be systemd-coredump bug, that's actually a good outcome. I was more worried about some even lower-level issue, which could be involved in the whole area of "calendar crashes and everything that tries to touch it gets stuck". But perhaps I just don't understand how to use gdb properly in these cases (I don't use it too often directly).

FinalBlocker -1
FinalFE +1

Based on the current findings in the BZ, I think this is likely to have low impact prior to being fixed by an update. IMHO, it would fail the "last blocker at Go/No-Go" test.

@zbyszek says "I don't think it'll be super-common. You need a program linked to way too many libraries for the issue to occur."

On that basis I'm:
FinalBlocker -1

we don't really need to block on "not 100% of crashes are caught correctly", the requirement is for the mechanism to basically work.

Okay, I trust zbyzek's judgment on this. I'll change to

FinalBlocker -1

I'll also toss in a

FinalFE +1

Just in case we're no-go on Thursday

FinalBlocker -1
FinalFE +1

AGREED RejectedFinalBlocker AcceptedFinalFE

The following votes have been closed:

• Rejected FinalBlocker (+0, 0, -4)
  • -1 by bcotton, sgallagh, adamwill, geraldosimiao
• Accepted FinalFreezeException (+3, 0, -0)
  • +1 by sgallagh, bcotton, geraldosimiao

You need a program linked to way too many libraries for the issue to occur.

Well, I just found a crash in gnome-control-center, and it's also affected by this systemd bug. So it's definitely not that rare. And it's very inconvenient that I can't trace that crash.

Should we re-propose this?

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