FinalBlocker -1

Problem reporting works, being able to save api key is definitely desired but I wouldn't count that as basic functionality (that is problem reporting).

FinalBlocker -1

As frantisekz said. Besides, one can fix that after installation, with an update.

Hmm, I don't know, I'm currently leaning towards +1. While technically problem reporting works, in reality I wouldn't use such a tool, because I can't really be bothered to create a new api key for each crash I encounter. I have better things to do with my life, right? I expect that the outcome of this will be considerably fewer crashes reported from KDE users.

Yeah, on an installed, permanent system I agree. But to block the release again, based on this behavior on a live session, for a thing that can be fixed later with an update...
I vote it for common bugs instead.

FinalBlocker -1

This is a behavior on an installed system. The argument "can be fixed with an update" almost always applies, and isn't used to circumvent criteria. It's used in an opposite fashion, to highlight problems which can't be fixed with an update and are highly problematic. The question here is not about whether it can be fixed with an update (of course), but it we want to consider it a basic functionality.

(Btw, even if this is accepted as a blocker, people can decide to waive it under the last minute blocker bug provision).

I'm with Kamil. It technically works but not in a way that's meaningful to the user. The release schedule isn't a factor in blocker determination. Additionally, the "can be fixed with an update" only applies in certain cases; it is not a general exception. That said, we can choose to waive it at the go/no-go under the late blocker exception, but that is different than "it doesn't violate the criteria"

FinalBlocker +1

I did not mean to say you're not testing on a installed system Kamil, I was meaning that this isn't a thing usually people use on a live session, but on an installed system instead, and can be fixed after the install.

I was meaning that this isn't a thing usually people use on a live session, but on an installed system instead, and can be fixed after the install.

Sure, but that's also true for all those gnome-calendar and gnome-photos and whatnot bugs, which were accepted as blockers. Release criteria don't apply just to Live sessions.

FinalBlocker +1

I believe this meets the criterion. That said, I hope it is waived. This was discovered much too late for the developers to have any reasonable chance of fixing it. We can't slip forever.

FinalBlocker -1

People can still report bugs, it is just inconvenient. Plus, it can be fixed with an update. In the alternative, if this ends up being voted a blocker, consider this a vote to waive.

FinalBlocker -1

This can be fixed later with an update. Bugs can still be reported.

FinalBlocker -1

I agree with others that have said that saving the password is nice-to-have but not core functionality of the bug reporting tool. I cannot see any situation where this would pass the "last blocker" smell test, even if the schedule was on-time.

As I already said, I'm closer to +1 than -1, but not completely convinced. In order to be in the votes list and not lost in the discussion thread, I'll cast the vote:

FinalBlocker +1

FinalBlocker +1

FinalBlocker -1

(What sgallagh said.)

If I was a decider, while I can see both viewpoints (although as bug reporting is not a normal functionality I would likely vote -1), even if the majority voted to approve a final blocker, I would also vote to waive this particular bug for final.

FinalBlocker -1

Agree with sgallagh and gtb. Therefore, after all the delays that have already occurred, this bug should not cause another delay. In the end, this is a tradeoff between 2 serious drawbacks.

FinalBlocker -1

This is not a big enough bug to cause another delay

FinalBlocker -1

(What sgallagh said.)

I understand Kamil's point that it is stupid to type the API key each time someone wants to report a traceback, however I do not agree that it is necessary to create a new API key each time I want to do it.

The API key can be added to /etc/libreport/evets/report_Bugzilla.conf and the whole API problems disappears like steam above the pot.

Therefore I am

FinalBlocker -1

The API key can be added to /etc/libreport/evets/report_Bugzilla.conf

That's a decent workaround (it's better to mention it in the bugzilla), I'll add it to the Common Issues entry, thanks. The main disadvantage is that you need to have root access and the file needs to stay world-readable.

The API key can be added to /etc/libreport/evets/report_Bugzilla.conf

That's a decent workaround (it's better to mention it in the bugzilla), I'll add it to the Common Issues entry, thanks. The main disadvantage is that you need to have root access and the file needs to stay world-readable.

The path however has events in it, not the suggested evets.
I know that it is not the best solution ever, but as a temporary workaround it will do, I suppose.

-1 This is not a big enough bug to cause another delay

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