#802 [gnome-photos] album picker duplicates fields, preventing photo organization | rhbz#2081291
Closed 2 years ago by blockerbot. Opened 2 years ago by blockerbot.

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

Current vote summary

The votes have been last counted at 2022-05-04 17:05 UTC and the last processed comment was #comment-795874

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)


The duplicated entries go away when you hit OK. Therefore I tend to be

FinalBlocker -1

FinalBlocker -1
If the duplicate entries go away when you hit OK.

The duplicated entries go away when you hit OK.

That's NOT the point, this is not just a small graphical glitch. The point is, you have no idea which albums you selected. Try it yourself. Each time I try this, I'm completely in the dark about what actually happens. And even if you "cancel" the dialog with Escape, it actually performs the changes as if you hit OK.

So you:
1. start making changes
2. get absolutely confused because the fields start multiplicating, each with a different state (e.g. you'll see your 'nature' album several times selected and several times unselected)
3. if you want to cancel it, you end up confirming it
4. your albums are messed up, your photos are god knows where and you have to search for them, and try to figure out how to fix that chaos.

This is a disaster. If I had some actual real data in gnome-photos, I'd be furious.

//Edit: Edited out some strong language which might have offended somebody. Tried to find some minor swearwords in the dictionary.

Someone can tell me if albuns on gnome photo are real directories or not.
As I see, they're just tags on files, because the files remain on the directories you already save them.

I agree with @kparal, it's a bad bug and doesn't meet the literal meaning of "basic functionality". But also Photos is currently unmaintained, there's a good chance it doesn't get fixed any time soon. The WG did recently agree to keep Photos in the default installation due to some image editing features it has that Eye of GNOME lacks. So it's really a catch-22.

As suboptimal as it sounds: +1 final blocker, +1 exception for both late blocker and difficult to fix, and Common Bugs.

If it's agreed to waive it, it'll become blocking for Fedora 37 beta as the next milestone. And by then QA and Workstation WG discuss removing Photos if it will continue to be unmaintained, and also clarifying/narrowing the scope of the "basic functionality".

+1 FinalBlocker

There really isn't much you can do with Photos if you can't reliably interact with albums, and yeah, this bug means you really can't do that.

+1 FinalBlocker

(and let's waive it at Go/No-Go, given the lateness and difficulty)

As suboptimal as it sounds: +1 final blocker, +1 exception for both late blocker and difficult to fix, and Common Bugs.

@chrismurphy , blockerbugs bot is not yet smart enough to parse this as a vote ;-)

FinalBlocker +1
(and +1 to waive for late and too hard to fix due to being currently unmaintained)

if it will continue to be unmaintained

I am fine with this being a blocker that is being waived. I just wonder how things break if the application is not maintained and nobody does anything with it. How does it break between releases?

How does it break between releases?

External libraries might cause this. But gnome-photos doesn't actually look completely dead. There were not many changes last year except translation updates, but in 2022 there were some changes made:
https://gitlab.gnome.org/GNOME/gnome-photos/-/commits/master

AGREED AcceptedFinalBlocker

FWIW, it looks like these problems were likely caused by changes in tracker.

The following votes have been closed:

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

2 years ago

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

Login to comment on this ticket.

Metadata