FinalBlocker +1

This is outside the realm of 'basic functionality' for me.

FinalBlocker -1
FinalFE +1

FinalBlocker -1

yeah, seeing more carefully I agree with you both.

FinalBlocker -1
FinalFE +1

AGREED RejectedFinalBlocker

The following votes have been closed:

• Rejected FinalBlocker (+0, 0, -3)
  • -1 by geraldosimiao, adamwill, catanzaro

This is outside the realm of 'basic functionality' for me.

I'm a bit confused by this. We have an "archive manager" clearly listed as one of the app types that we block on in all release-blocking desktops, and creating a zip file consisting of a folder and a file seems like basic functionality to me...?

Of course, this is not a basic functionality of a file manager. But in Workstation, Nautilus is the default archive manager as well, because file-roller was dropped from the default installation.

FinalFE +1

I'd also revote the blocker if I swayed some people with my comment (currently I see it as +1 blocker).

The nautilus file manager mostly works. It's unfortunate that compression is broken in this case, but most users probably won't notice if we fix it quickly in a post-release update.

(Workstation WG has expressed interest in qualifying fewer blocker bugs under the basic functionality criterion. The cutoff for what counts as basic functionality and what doesn't is inevitably going to be subjective, but blocking a Fedora release is a big deal. We certainly do want to block in cases where an app is so broken as to cause serious embarrassment to Fedora; e.g. a couple weeks ago Loupe did not support any image formats and Snapshot didn't have permission to access webcams.)

File manager mostly works, but archive manager mostly doesn't. I was talking about the latter, you replied about the former. Workstation WG intentionally decided to use Nautilus to serve both purposes.

I can propose a standalone archive manager criterion, or I can clarify the existing criterion regarding the case where one app serves multiple purposes, but it feels a bit like unnecessary paperwork to me.

Or are you saying that basic archiving capabilities are not required to work in Fedora Workstation? That even a standalone criterion for it (if really necessary) would be rejected by you? It seems that you're saying this, but I find it hard to believe, to please help me understand, thanks :-)

We really only want to block Fedora release if the app is obviously extremely broken. It's "OK" for ancillary functionalities to be not work. Of course it's not good, but there will always be bugs with basic functionality, and we probably don't want to delay Fedora 40 over them all.

nautilus is not primarily an archive manager; I'd call that an ancillary functionality.

AGREED AcceptedFinalFE

Discussed during the 2024-04-15 blocker review meeting: [0]

The decision to classify this bug as an "AcceptedFreezeException (Final)" was made as the fix is targeted and well tested.

[0] https://meetbot.fedoraproject.org/blocker-review_matrix_fedoraproject-org/2024-04-15/f40-blocker-review.2024-04-15-16.00.txt

The following votes have been closed:

• Accepted FinalFreezeException (+3, 0, -0)
  • +1 by adamwill, geraldosimiao, kparal

nautilus is not primarily an archive manager; I'd call that an ancillary functionality.

I feel like we still don't understand each other. I agree that the basic functionality of nautilus as a file manager isn't affected. But while nautilus is not primarily an archive manager, it is the primary and only archive manager in Fedora Workstation. And therefore, it has to fulfill the role of an archive manager satisfactorily as well. And packing some files and folders together seems to be a basic functionality of an archive manager. Saying that archive management role doesn't need to be fulfilled just because it doesn't have a dedicated app for it feels like cheating out of the criterion, for me.

So I'll try to propose a clarification of that criterion, and let's see if your WG and people in general are in favor or not.

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