#931 [gnome-photos] Memory exhaustion when editing a cropped photo | rhbz#2130937
Closed by blockerbot. Opened by blockerbot.

Bug details: ** https://bugzilla.redhat.com/show_bug.cgi?id=2130937 **
Information from BlockerBugs App:
2130937

Current vote summary

Commented but haven't voted yet: adamwill, frantisekz

The votes have been last counted at 2022-10-10 08:49 UTC and the last processed comment was #comment-820635

To learn how to vote, see:
https://pagure.io/fedora-qa/blocker-review
A quick example: BetaBlocker +1 (where the tracker name is one of BetaBlocker/FinalBlocker/BetaFE/FinalFE/0Day/PreviousRelease and the vote is one of +1/0/-1)


FinalBlocker +1

The [GNOME wiki] says

Enhance, crop and edit in a snap

Which makes me think this should be considered basic functionality. On the other hand, it appears to be a specific type of editing that triggers this, and the affected actions are outside of what I'd consider basic functionality, so I'm definitely open to being convinced this is -1.

FinalBlocker -1

I'm just going to repeat Ben's argument: " the affected actions are outside of what I'd consider basic functionality".

I'm going to interpret cropping as "basic functionality" since it's one of the primary advertised features of this app, and not something that's hidden or hard to get to.

FinalBlocker +1

@catanzaro well, I'd agree if it was just cropping, but you have to do the particular sequence "crop, then do something with shadows/highlights" to trigger the bug. For me this is a very close call, not sure which way to go.

OK, good point. Since there are two steps involved here, I've changed my mind. This is more advanced functionality that most users will probably not encounter.

FinalBlocker -1

I agree that these are very specific steps and I'd likely vote -1 on this. On the other hand, consuming all available memory is one of the worst things that can happen, because it makes your whole system unresponsive for a long time (especially if you have swap on a hard drive) and many people might resort to a hard-reboot just to end it.

FinalBlocker 0
(but if I had to choose, I'd likely lean to -1)

It's a mixed bag. Cropping is pretty basic functionality. Adjusting the crop arguably not.

FinalBlocker 0
FinalFE +1

AGREED AcceptedFinalFE

Discussed during the 2022-10-03 blocker review meeting: https://meetbot-raw.fedoraproject.org/fedora-blocker-review/2022-10-03/f37-blocker-review.2022-10-03-16.00.log.txt

The following votes have been closed:

  • Accepted FinalFreezeException (+1, 0, -0)

FinalBlocker -1
FinalFE +1

FinalBlocker -1
FinalFE +1

FinalBlocker -1
FinalFE +1

The workstation working group discussed this issue yesterday. The consensus there was that the issue doesn't affect basic functionality, on the basis that it requires a fairly specific sequence of steps to trigger.

I just found out that Fedora 36 is affected by this problem as well. More details here:
https://gitlab.gnome.org/GNOME/gnome-photos/-/issues/205#note_1567287

Given that this is not a new problem and we haven't seen people complaining about this (there's nothing about it in the upstream tracker), I don't think this should be a blocker.

FinalBlocker -1

@bcotton @lruzicka @geraldosimiao @augenauf
Does the recent information change your blocker vote? Thanks.

I am now

FinalBlocker -1
FinalFE +1

I wasn't feeling that great about my +1, and this pushes me over the edge.

It does. I was a small +1 anyways.

Now
FinalBlocker -1
FinalFE +1

Seeing that we have plenty of other issues with GNOME atm, this one is the least worthy to block on:

FinalBlocker -1

AGREED RejectedFinalBlocker

The following votes have been closed:

Metadata Update from @blockerbot:
- Issue status updated to: Closed (was: Open)

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

Log in to comment on this ticket.

Metadata