For the moment it looks like a misunderstanding rather than a bug. Let's wait for more details.

FinalBlocker -1

I can't get a good position on this.

FinalBlocker 0

If situation remains as described at the moment,

FinalBlocker -1

FinalBlocker -1

I'm gonna let this one sit a bit longer till we're sure we know what's going on for lili.

My current understanding is that there might be something wrong, or not, it's hard to guess when Lili likes to crash the whole session (thus perhaps creating many individual crashes) instead of just a single app. But I've tested the underlying general workflow in detail, and it's working as expected for me. It's not purging everything, just deleting one directory at a time, when the max size is reached.

FinalBlocker -1

FinalBlocker -1

Lili likes to crash the whole session
Er,I crashed the whole session because gnome-shell crash isn't a rare
case,and deleting all the data on gnome-shell crash sounds like a blocker
to me.
There is something wrong,abrt should Not delete firefox crash data if
there is more than half of the maxsize space left.
Though I'm not able to reproduce the original gnome-shell-crash->
all-data-gonna issue with the new version of gnome-shell,
but it sounds like a blocker to me that abrt starts to delete data when
there is more than 5 crash, even if there is more 80% maxsize space left.
I'd like to highlight the known truth:problems of bug report tools will
discourage users to report ugly crash bugs,which may result in the
newcomers of linux have a bad impression on Fedora.
Please click into the bug for more information if you have interest,thanks.

On Fri, Mar 17, 2023 at 8:20=E2=80=AFPM Kamil P=C3=A1ral pagure@pagure.io=
wrote:

kparal added a new comment to an issue you are following:
``
My current understanding is that there might be something wrong, or not,
it's hard to guess when Lili likes to crash the whole session (thus perha=
ps
creating many individual crashes) instead of just a single app. But I've
tested the underlying general workflow in detail, and it's working as
expected for me. It's not purging everything, just deleting one directory
at a time, when the max size is reached.

FinalBlocker -1

``

To reply, visit the link below or just reply to this email
https://pagure.io/fedora-qa/blocker-review/issue/1104

Reproposing due to a new info: https://bugzilla.redhat.com/show_bug.cgi?id=2177153#c25

REVOTE FinalBlocker

FinalBlocker -1

ABRT is frankly extremely buggy and this has been the case for at least a decade now. It doesn't make sense to block Fedora release on it. We don't even agree on a suggested resolution to this issue (I think it's unacceptable for ABRT to delete problem reports that are less than 6 months old regardless of max configured problem dir size, it should only delete big data and not everything).

I checked on a f35 VM with 120G disk space, setting maxsize to 30G, I feel
a little shocked( This weird ,confusing, serious bug has been there for
years) but yes, just like Michael said,it's not a new issue.
I feel sorry about the fact that we may have lost many valuable bug data
which would have helped Fedora to be better.
Even if the decision is to reject this as a blocker,I still like to know
why abrt acts this strangely.

On Tue, Mar 21, 2023 at 11:17=E2=80=AFPM Michael Catanzaro pagure@pagure.i= o wrote:

catanzaro added a new comment to an issue you are following:
``
FinalBlocker -1

ABRT is frankly extremely buggy and this has been the case for at least a
decade now. It doesn't make sense to block Fedora release on it. We don't
even agree on a suggested resolution to this issue (I think it's
unacceptable for ABRT to delete problem reports that are less than 6 mont=
hs
old regardless of max configured problem dir size, it should only delete
big data and not everything).
``

To reply, visit the link below or just reply to this email
https://pagure.io/fedora-qa/blocker-review/issue/1104

I see the point for fixing this and else, but reading the criterion it seems that this is not really basic funcionality.

 Default application functionality
 For all release-blocking desktop / arch combinations, the following applications must start successfully and withstand a basic functionality test:...problem reporter
 ...
 Additionally, for Fedora Workstation on the x86_64 architecture, all applications installed by default which can be launched from the Activities menu must meet this requirement.
 ....
 Basic functionality means that the app must at least be broadly capable of its most basic expected operations, and that it must not crash without user intervention or with only basic user intervention."

FinalBlocker -1

changing to
FinalBlocker 0
after clarifications of @kparal's comment below

ABRT is frankly extremely buggy and this has been the case for at least a decade now. It doesn't make sense to block Fedora release on it. We don't even agree on a suggested resolution to this issue (I think it's unacceptable for ABRT to delete problem reports that are less than 6 months old regardless of max configured problem dir size, it should only delete big data and not everything).

Let me be clear what we're voting on in this new vote.

Problem: The default disk space for crashes (about 1GB) is too low for ABRT to work meaningfully and satisfy basic functionality requirements.

Anything else - "doesn't make sense to block Fedora release on ABRT" or "it's unacceptable for ABRT to delete problem reports that are less than 6 months old" - is not part of this vote. You can propose them separately if you wish.

I'm personally somewhere in the middle here, probably leaning towards +1 blocker. The 1GB space is enough to report a single crash, if you do it immediately. If there's a second crash, or multiple apps crash at once (like when a session crashes), it's likely that your first/primary crash gets removed immediately. This prevents you from doing the main task of ABRT - reporting a crash.

how likely is it to fix the MaxCrashReportsSize with an update later?

That shouldn't be a deciding factor when voting on blockers. If the fix can't be done, we have ways to waive the blocker. In this particular case, the cause of the bug might be quite simple, and the fix as well, as described in https://bugzilla.redhat.com/show_bug.cgi?id=2177153#c28 . And of course it can also be trivially fixed by providing the value directly in the config file.

FinalBlocker +1

I don't like this, but it's pretty clearly a violation of the existing criterion. Importantly, if the stated default was 1 GB then I would not consider this a bug. The bug here is that the documented and observed behavior are not the same. If the docs said the default limit was 1 gb and that made abrt not particularly useful, then I would not consider it a violation of the criterion because it would be working as intended.

FinalBlocker +1

Well... after reading all discussion here and what is described at the ticket again, I revert my vote to 0.

FinalBlocker 0

FinalBlocker -1

I mean it's broken, sure, but does purging core dumps too frequently really violate the basic functionality criterion? You can still report crashes, as long as you're relatively quick to do so before more crashes come in. And it seems we're only off by a factor of 5 here?

If abrt can't handle a session crash without running out of space, it can't satisfy it's basic functionality requirements for the Workstation case.

FinalBlocker +1

FinalBlocker +1

from the criteria list:
"The installer must be able to report failures to Bugzilla, with appropriate information included. "

This does not really affect the installer.

Discussed during the 2023-03-27 blocker review meeting: [0]

The decision to delay the classification of this as a blocker bug was made as we don't have a clear enough vote here. We'll delay the decision in the hopes of getting more votes and/or a fix.

[0] https://meetbot.fedoraproject.org/fedora-blocker-review/2023-03-27/f38-blocker-review.2023-03-27-16.00.txt

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