I don't think this is a blocker. The installation works as expected, the system boots as expected. Just certain tools don't display disk layout information in a user-friendly manner. I understand the "potential data loss" argument. It could be argued that gnome-disks violates the basic functionality criterion, if it also fails to display the partitions on the second drive as used. But that would be a stretch, I think.

For the moment:
FinalBlocker -1

Though I always prefer cli (lsblk/mount) over gui(gnome-disks) ,if both of them could offer what I want:checking disks space,and even gnome-disks show the btrfs volume part on the second disk as not-mounted,but fine...,lovely Kamil^^,do you think FE makes sense to you?I really don't care about it is accepted as a FE or blocker,all I want is a fix,otherwise, we are really putting users in risk of the whole data loss.

Hi Lili. I'm not saying what you reported is not a problem :-) I'd love if the tools worked better in this case. I just don't see it as a release blocker. It has been this way probably forever, and we don't get complaints from people who installed btrfs to two drives and then deleted one of the partitions by accident, just because a tool didn't show it as mounted.

We can definitely talk about a FE, and I don't have anything against it, but that will not make the fix any more likely. Proposing a FE makes only sense if we the fix is ready (and we're in a freeze), or it's likely coming (and we're short of time, so we want to discuss it ahead of time), or the developer wants to know whether the FE would be granted and therefore whether to invest the time into it right now. None of it seems to apply at this moment (and we're also not in a freeze). So the FE would mostly be just a paperwork exercise now. And given that it might affect partitioning tools, we would probably want to know more about the fix and be careful not to take it in too late in the freeze anyway.

If you want this to be a more likely blocker, find a use case where this breaks installation. For example if blivet-gui/custom part didn't handle such a situation properly, confused users into deleting a wrong partition, etc ;-)

but that will not make the fix any more likely.

I consider FE as a less strong push to developer than Blocker,and the bugs on FE list will be more likely fixed than those Not on the list.No?

For example if blivet-gui/custom part didn't handle such a situation properly, confused users
into deleting a wrong partition, etc ;-)

Tears....，I should not challenge you picky revenge monster! for fun;)
Dear adorable Kamil,how about -1 cup of beer(compared to other guys)?,-2? No?Work is work?Then I'm gonna to spare 20 minutes of my finding bug time to see if I can come up with a criteria-violation case...

I consider FE as a less strong push to developer than Blocker,and the bugs on FE list will be more likely fixed than those Not on the list.No?

No, that's not how it works, sorry :-)

If you care very strongly about some bug which is not accepted as a blocker (or perhaps it already affects stable releases), and believe that it affects lots of users in a negative way, you can propose it as a Prioritized Bug. You can see currently accepted Prioritized Bugs at the bottom of any milestone in our BlockerBugs App. The project manager then tries to convince developers to focus on these issues (which doesn't happen for FEs). The downside is that this was used to be run by Ben Cotton, who has been let go, and I'm not sure if anyone picked it up yet (sigh, maybe we should).

Then,I guess I have to let it go,though I feel pretty sorry to the Few users who are going to be affected by this bug for their whole-data loss,sigh...

I feel so sorry to the users that I suddenly comes up with an idea,and get up from bed<sleepy face here...>, as you can see from the last screencast I attached, this bug clearly violates this criteria:
https://fedoraproject.org/wiki/Fedora_39_Final_Release_Criteria#Default_panel_functionality

Gnome-disks warn users and not allow them to delete the btrfs volume part on the first disk,while allow them to delete the btrfs volume part on the second disk,I think the basic function of gnome-disk include:1)show disks usage,mounted/not-mounted2)allow users to delete an unused device while reject it if it's not used.
As I mentioned in previous comment,it violates 1), and as I said in this comment,it violates 2).
So, dear kamil,if we don't consider this as a gnome-disk blocker,then I really don't know what bugs can we consider as gnome-disk blocker.
That being said,it might not be gnome-disk's fault,might be the tool it depend on's fault,so not reassign yet.

You mean this one:
https://fedoraproject.org/wiki/Fedora_39_Final_Release_Criteria#Default_application_functionality

OK, let's see what others think about it. You can vote as well, Lili ;-)

So...,still -1?Then,no,thanks...

Discussed during the 2023-09-25 blocker review meeting: [0]

The decision to delay the classification of this as a blocker bug was made as we would like to ask the GNOME Disks developers (and possibly util-linux too) for their opinion on this bug and how practical it is to try and address it.

[0] https://meetbot.fedoraproject.org/fedora-blocker-review/2023-09-25/f39-blocker-review.2023-09-25-16.02.txt

If push came to shove, I wouldn't block on this.

FinalBlocker -1

FinalBlocker -1

AGREED RejectedFinalBlocker

Discussed during the 2023-10-02 blocker review meeting [1]:

We find this to be a more advanced use case where the user would have a reason for having two btrfs drives, and would probably remember why they did it, thus making this bug less of an issue in this context. We also acknowledge that a lot would probably have to change in the stack to fix it.

[1] https://meetbot-raw.fedoraproject.org/fedora-blocker-review/2023-10-02/f39-blocker-review.2023-10-02-16.01.log.txt

The following votes have been closed:

• Rejected FinalBlocker (+0, 0, -3)
  • -1 by kparal, nielsenb, geraldosimiao

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