16:01:23 #startmeeting F39-blocker-review 16:01:23 Meeting started Mon Oct 2 16:01:23 2023 UTC. 16:01:23 This meeting is logged and archived in a public location. 16:01:23 The chair is coremodule. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions. 16:01:23 Useful Commands: #action #agreed #halp #info #idea #link #topic. 16:01:23 The meeting name has been set to 'f39-blocker-review' 16:01:23 #meetingname F39-blocker-review 16:01:23 The meeting name has been set to 'f39-blocker-review' 16:01:23 #topic Roll Call 16:01:40 Hello all, who is around today for a blocker meeting? 16:01:46 .hello2 kparal 16:01:47 kparal: kparal 'Kamil Páral' 16:03:20 .hello thebeanogamer 16:03:21 thebeanogamer: thebeanogamer 'Daniel Milnes' 16:03:34 .hello 16:03:34 amoloney: (hello ) -- Alias for "hellomynameis $1". 16:03:46 .hello amoloney 16:03:47 amoloney: amoloney 'Aoife Moloney' 16:07:44 hmmm, we're running a bit thin on attendance 16:08:02 Frantisek should be here in 30 minutes 16:08:13 That doesn't help us now... 16:08:27 is there enough here to make decisions? or should this be rescheduled? 16:08:45 we have 3+ people, so we meet the minimum requirement 16:08:49 of course more people is better 16:09:12 with the current attendance, I'm inclined to adjourn for today with a caveat that we'll vote on these in the blockerbugs app 16:09:58 I'll shout out in the qa channel 16:10:03 thanks kparal 16:10:13 let's wait for a few more minutes before making a call. 16:10:48 it would be a shame to waste a chance to discuss the bugs so hopefully a few more folks wander in :) Im good to wait a bit too 16:14:07 coremodule: if you don't want to vote, we can still at least discuss the proposed blockers, and then ask people to cast their votes in blocker tickets 16:14:44 sorry for being late 16:14:50 amoloney, is there a bug you're here for in particular? 16:15:08 tflink is here! 16:15:32 I didn't want to start with such low attendance and have people drop mid-meeting leaving us stuck or causing the meeting to hit the time limit 16:15:33 not one, all of them :) Im here to listen and learn how things are generally discussed and decided on 16:15:40 alright, lets go 16:15:51 #topic Introduction 16:15:51 Why are we here? 16:15:51 #info Our purpose in this meeting is to review proposed blocker and nice-to-have bugs and decide whether to accept them, and to monitor the progress of fixing existing accepted blocker and nice-to-have bugs. 16:15:51 #info We'll be following the process outlined at: 16:15:52 #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting 16:15:53 coremodule: btw use #chair, just in case you get a disconnect 16:15:53 #info The bugs up for review today are available at: 16:15:55 #link http://qa.fedoraproject.org/blockerbugs/current 16:15:59 #info The criteria for release blocking bugs can be found at: 16:16:01 #link https://fedoraproject.org/wiki/Basic_Release_Criteria 16:16:03 #link https://fedoraproject.org/wiki/Fedora_39_Beta_Release_Criteria 16:16:05 #link https://fedoraproject.org/wiki/Fedora_39_Final_Release_Criteria 16:16:16 #chair kparal tflink 16:16:16 Current chairs: coremodule kparal tflink 16:16:19 #info 6 Proposed Blockers 16:16:19 #info 5 Accepted Blockers 16:16:19 #info 0 Accepted 0-day Blockers 16:16:19 #info 0 Accepted Previous Release Blockers 16:16:20 #info 5 Proposed Freeze Exceptions 16:16:21 #info 2 Accepted Freeze Exceptions 16:16:35 #topic Proposed Blockers 16:16:43 #topic (2241632) Netinstall ISO renders a black screen when using kickstart install (bare metal and VM) 16:16:43 #link https://bugzilla.redhat.com/show_bug.cgi?id=2241632 16:16:43 #link https://pagure.io/fedora-qa/blocker-review/issue/1354 16:16:43 #info Proposed Blocker, anaconda, NEW 16:16:43 #info Ticket vote: FinalBlocker (+4,0,-0) (+nielsenb, +nixuser, +geraldosimiao, +kparal) 16:17:10 ah, who will secretarialize this meeting? 16:17:12 not sure why ngompa doesn't see it in a VM, I see it every time 16:17:48 Im happy to do that part coremodule 16:17:52 I can try to secretarialize on the fly, but I'm not sure if I can stay the whole time 16:18:41 amoloney: do you know the basics? 16:18:43 thanks amoloney, have you done it before? 16:18:48 https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting#Secretary_Duty 16:19:06 kparal, I don't think that doc mentions anything about the blockerbugs part of the process 16:19:20 no, Ive lurked a few times and will try pick it up as we go 16:19:24 I'll add it to the list of things to update 16:20:01 I did one go/no-go meeting so I assume its not too different from that - summarise the proposed outcome, and post whats agreed 16:20:37 #info amoloney will act as secretary. 16:20:41 So. 16:20:44 Thoughts on this bug? 16:20:55 amoloney: ideally with a link to the meeting, which is https://meetbot-raw.fedoraproject.org/fedora-blocker-review/2023-10-02/ 16:21:11 it's already +4, does anyone have a dissenting opinion? 16:21:29 thank you both1 16:21:30 so for me, this is a clear blocker. It's easy to reproduce (for me), and completely kills the process 16:21:43 okay. I'm +1 blocker here 16:21:53 +1 blocker 16:22:31 amoloney: the comment in bugzilla should also link to the blocker review ticket (the second #link above), thanks 16:22:43 .hello2 16:22:45 frantisekz: frantisekz 'František Zatloukal' 16:22:55 frantisekz: evening! 16:23:15 +1 blocker 16:25:11 proposed #agreed 2241632 - AcceptedBlocker (Final) - This is accepted as a violation of the following criterion: "The installer must be able to complete an installation using all supported interfaces." as the user cannot reasonably complete installation using the supported kickstart+graphical interface. 16:25:28 hi frantisekz 16:25:34 ack 16:25:40 would you be willing to help amoloney with secretary duty if he has any questions? 16:26:07 sure sure 16:26:14 I'll take that coremodule 16:26:16 frantisekz, thank you! 16:26:23 thanks for leading the meeting! 16:26:50 coremodule: I think it's "she" 16:26:59 but feel free to correct us amoloney :-D 16:27:17 I am a 'she', but I've been called worse so no offence taken :-D 16:28:02 frantisekz, amoloney already offered to take the secretary duty, but feel free to work it out with her 16:28:17 sorry amoloney, not intentional 16:28:26 frantisekz if you want to secretarialize this first bug, then I can go in and see the format you used and can do the next/another bug if that suits? 16:28:28 okay, we need two more 'ack's here 16:28:49 sure sure, works for me amoloney 16:28:55 thank you 16:29:08 will ping you of meeting room once it's secretalized :) 16:29:15 ack 16:29:38 amoloney: now you basically add some intro text like "after discussion at [blocker review ticket link] and at the blocker review meeting [link] this was accepted as a blocker: [copy #agreed text]" to bugzilla, and add AcceptedBlocker to the Whiteboard 16:29:44 the 2241632 is the first bug dealt with here? 16:29:53 frantisekz, yes 16:29:56 ty 16:30:12 amoloney, I can email you the template that I use for secretary duty, it makes it a whole lot easier 16:30:44 that would be very helpful, thank you - amoloney@redhat.com 16:30:55 amoloney: we'll need to update the blocker review ticket ourselves, because you don't have permissions to use AGREED at the moment, but we can change that in the future, if you plan to participate more often ;-) 16:31:06 :) 16:31:09 these are my notes for it: https://paste.centos.org/view/c96a672e 16:31:15 including the template 16:32:07 am I the only one writing it manually every time? :-D 16:32:30 frantisekz: I'd like if you template always contained a link to the blocker-review ticket, even if the final agreement is done in the meeting 16:32:53 amoloney, sent! 16:32:54 perhaps we should add the "best template" to the wiki :) 16:33:06 we should make it automatic... 16:33:18 we should finish the first bug .... :-P 16:33:20 can't disagree on that 16:33:33 kparal, yes, I have a template and I never do it on-the-fly so that the meeting logs can be shared as well 16:33:40 anyway 16:33:43 ONE MORE ACK 16:33:55 kparal: for the discussion link, I've made a blockerbugs PR for that about a year ago... 16:34:12 does mine count coremodule? :) 16:34:13 ack 16:34:24 #agreed 2241632 - AcceptedBlocker (Final) - This is accepted as a violation of the following criterion: "The installer must be able to complete an installation using all supported interfaces." as the user cannot reasonably complete installation using the supported kickstart+graphical interface. 16:34:28 frantisekz: I know! very appreciated :D 16:34:30 frantisekz, consider it counted 16:34:39 #topic (2241761) cancelling partition editing by Esc doesn't cancel, but CONFIRMS the dialog 16:34:39 #link https://bugzilla.redhat.com/show_bug.cgi?id=2241761 16:34:39 #link https://pagure.io/fedora-qa/blocker-review/issue/1358 16:34:39 #info Proposed Blocker, blivet-gui, NEW 16:34:58 this is a facepalm one I discovered today 16:35:02 oof 16:35:04 when debugging a different bug, as always 16:35:25 I don't like this 16:35:45 now we don't have an exact criterion here :-) but I think we can agree this is extremely bad :-D 16:36:07 yeah, it's bad but I was trying to figure out the criteria violation 16:36:14 we have this one: https://fedoraproject.org/wiki/Fedora_39_Beta_Release_Criteria#Data_corruption 16:36:18 it's close enough I think 16:36:49 or we can target some of the installer criteria, saying it doesn't work as expected when partitioning 16:37:11 https://fedoraproject.org/wiki/Fedora_39_Beta_Release_Criteria#Custom_partitioning 16:37:28 "it works if you don't screw up" is ... not the best look 16:37:30 any of those fail if you cancel the dialog with Esc, they do a different thing than instructed 16:37:44 does it work if you click on cancel instead of hitting esc? 16:37:52 yes, that cancels fine 16:38:40 definitely +1 FE 16:38:51 +1 blocker from me 16:39:37 debating the "would this slip release if it was the last unresolved blocker" test and having some trouble 16:39:38 just a note, not verified, but I assume this is not a new bug 16:39:56 I would say that if the Cancel button works, but the ESC key doesn't, it's not *as* bad in my mind, but still probably a blocker 16:40:02 I'd still be +1 even as the last blocker 16:40:06 do we have any idea if it is the same behavior in F38? 16:40:13 I can check 16:40:56 but still, even if it hsa been present all along, I'm still +1. This is just bad. 16:41:26 yes, it's present in F38 16:41:38 Yeah, I think regardless, I'm +1 blocker on a loose interpretation of the Data Corruption criterion 16:41:55 -1 for me, +1 FE 16:42:04 it was just a pure luck that I spotted this. If I actually had data on that partition, I'd be furious. 16:42:38 but the criterion says "must be fixed or documented". if it's been around for at least a release and nobody has raised a stink about it, I'm inclined to say not a blocker even if it is bad 16:43:15 when you reformat a partition in blivet-gui, you don't see it marked in any way. The display doesn't change. So if you don't look at the pending log closely, you just don't know 16:43:23 people won't spot it 16:43:30 I would be curious to know how long this one has been in there 16:43:35 "fixed or documented" is our choice, I believe 16:43:41 It's bad, but if it's not new then should it actually block? 16:44:03 that's a recurring question and I believe the answer is "it depends" in general, and "yes" in this case 16:44:12 kparal, are you spinning up an f38 machine to test? 16:44:18 it sounds like he already did 16:44:19 I already did 16:44:30 ah, okay 16:44:30 it's present in F38 16:45:13 -1 blocker, +1 FE - it's bad but it's not new and I have trouble seeing it pass the "would it block release if it was the last unresolved blocker" test 16:45:34 can't be fixed with an update 16:46:10 to tflink's point, if present in f38, it does show that it's not been reported, so potentially not been found up to this point. 16:46:28 or just anyone who hit it effectively rage quit Fedora 16:46:31 well we haven't heard about it 16:46:33 I think I agree with -1 blocker, +1 FE 16:46:39 doesn't mean it didn't eat users data 16:46:40 well, it can be fixed for blive-gui usage on an installed system at least, can't it? 16:46:45 kparal, right, why I said hasn't been reported 16:47:05 frantisekz: I care about the installation use case here. Blivet-gui itself is not blocking. 16:47:09 as a standalone app 16:47:26 coremodule: might have been, I didn't see it :) 16:47:42 anyway, what's the count? 16:47:50 sounds like I haven't convinced you 16:47:54 +2/-3 as it stands 16:47:59 if you were installing a linux distro and it ate your data, would you take the time to report it or just never use that distro again and switch to something else? I'm still -1 blocker but I can easily see someone not reporting it if they hit the bug, other than rant on social media 16:48:08 so +1FE currently and punt the blocker decision? 16:48:14 tflink, that would be my approach, for sure 16:48:56 yeah, sounds like we don't have enough votes to decide blocker, punt to ticket 16:49:01 or next week 16:49:34 I'd also be interested to see how quickly they can turnaround a fix 16:49:47 this should be trivial to fix 16:51:12 coremodule: writing the proposal? 16:51:25 does it make sense to take this as an FE if it can't be fixed with an update? 16:51:34 of course 16:51:38 sure sure 16:51:38 why? 16:51:40 fe is for that 16:51:40 the freeze is tomorrow 16:51:51 if there's a fix, it has to have an FE to go through 16:52:02 just "blocker - light, zero sugar variant" 16:52:13 FE is for fixes that can be fixed with an update, not a tracker for what could be potentially a blocker? 16:52:19 okay 16:52:49 FE is universally agreed and it means we can take it in even if we don't agree whether to block the release on it 16:52:52 fe is for not bad enough to block the release, but still good to be fixed for the release 16:53:03 FE is for stuff that we'd allow through freeze but doesn't hit release criteria, no? 16:53:11 yes 16:53:19 especially for stuff that can't be fixed post release and/or affects live media/installation process/etc. 16:53:46 right 16:53:53 proposed #agreed 2241761 - punt (delay decision) AcceptedFreezeException (Final) - While we see this a bad issue, it's presence in F38 tempers our ability to make an outright decision at the moment. We do grant it FE status. 16:54:13 ack 16:54:32 patch - make it clearer that we're punting on blocker "punt blocker (delay decision" 16:55:03 proposed #agreed 2241761 - punt blocker (delay decision) AcceptedFreezeException (Final) - While we see this a bad issue, it's presence in F38 tempers our ability to make an outright decision at the moment. We do grant it FE status. 16:55:06 but that's just my pedantic side coming through, I suppose 16:55:08 ack 16:55:21 ack 16:55:29 #agreed 2241761 - punt blocker (delay decision) AcceptedFreezeException (Final) - While we see this a bad issue, it's presence in F38 tempers our ability to make an outright decision at the moment. We do grant it FE status. 16:55:38 #topic (2239128) pop-up screen is stuck when try to format a partition 16:55:38 #link https://bugzilla.redhat.com/show_bug.cgi?id=2239128 16:55:38 #link https://pagure.io/fedora-qa/blocker-review/issue/1342 16:55:38 #info Proposed Blocker, gnome-shell, ASSIGNED 16:55:38 #info Ticket vote: FinalBlocker (+3,0,-3) (+imsedgar, +kparal, +lnie, -lruzicka, -nielsenb, -geraldosimiao) 16:56:14 another divisive one ;-) 16:56:26 I actually didn't want to block on it until I tried it myself today 16:56:55 my comment is in the ticket 16:57:51 -1 Blocker, +1 FE (racy enough not to block for me) 16:58:06 I'd also like to say that this is nothing compared to the Esc bug. This one at least doesn't eat data. 16:58:31 but might make you end up in a messy state, if you try to kill the installer because it seems stuck 16:59:59 frantisekz: I'd argue with that. It's not "racy enough". It's extremely common. If this happened once in 10 or 50 times, that would be a sad race. But in this case you basically are guaranteed to hit it, if you format multiple partitions. 17:00:23 at least in my and Lili's experience 17:00:24 lnie is offering to do more testing on baremetal if we can wait until she's back before next meeting. I'm inclined to be punt blocker, +1 FE here 17:00:36 and Lukas and Vojtech confirmed the likelihood as well 17:00:52 coremodule: I don't think it makes sense to wait for more data 17:01:04 we have enough data from at least 4 people 17:01:58 kparal, did you test on baremetal? 17:02:19 the minimum reported occurrence is somewhere around 25%, the maximum at 100% (Lili) 17:02:27 coremodule: no, just VM 17:02:38 it seems that lnie is the only one who did, and in all three attempts, it showed 100% failure rate. 17:02:38 there was no time to test bare metal, sadly 17:03:18 yes, it seems so 17:03:42 for me, even 25% is good enough to +1 blocker from me 17:04:10 yeah, you know what, I think I agree with you 17:04:17 I'm going to amend my vote to +1 blocker 17:04:31 it's always important to remember that races produce wildly different numbers. Even if we test it a lot, it might behave completely differently on a different hardware or just at a different time 17:04:52 well yes, but that can go the other way too :) 17:05:21 any other votes? 17:05:22 yes. But we're concerned about the bad case :) 17:06:05 we're at +5/-4 17:06:24 I'm definitely +1 FE, will defer to folks who have been more active in the blocker process in recent releases for blocker - +0 17:06:25 looks like we're going to do the FE+punt dance again 17:06:38 +0 blocker / +1 FE 17:07:57 proposed #agreed 2239128 - punt blocker (delay decision) AcceptedFreezeException (Final) - This does appear bad, but we can't reach a consensus. We're going to punt for now and perhaps have more testing done in the meantime. We do grant it FE status. 17:08:06 ack 17:08:09 ack 17:08:10 ack 17:08:17 #agreed 2239128 - punt blocker (delay decision) AcceptedFreezeException (Final) - This does appear bad, but we can't reach a consensus. We're going to punt for now and perhaps have more testing done in the meantime. We do grant it FE status. 17:08:25 #topic (2241274) initial-setup text fails on hardware 17:08:25 #link https://bugzilla.redhat.com/show_bug.cgi?id=2241274 17:08:25 #link https://pagure.io/fedora-qa/blocker-review/issue/1353 17:08:25 #info Proposed Blocker, initial-setup, ASSIGNED 17:08:25 #info Ticket vote: FinalBlocker (+2,0,-0) (+nielsenb, +nixuser) 17:08:53 doh, I should've seen this comment earlier: "Adam Willamson: I vote for whatever kparal votes for" 17:08:57 I have 2 votes now! 17:09:01 :-D 17:09:40 looks like a clear-cut blocker to me 17:09:47 agreed 17:10:09 +1 blocker, also looks like mkolman is working on it 17:10:18 +1 blocker 17:10:25 the criterion is hit exactly, +1 blocker 17:10:30 it's weird that it doesn't show up in automation 17:10:44 but that's an issue for not this process 17:10:49 +1 blocker 17:11:17 proposed #agreed 2241274 - AcceptedBlocker (Final) - We accept this a blocker as it violates the following criterion: "Release-blocking ARM disk images must boot to the initial-setup utility." 17:11:24 ack 17:11:24 ack 17:11:28 ack 17:11:31 #agreed 2241274 - AcceptedBlocker (Final) - We accept this a blocker as it violates the following criterion: "Release-blocking ARM disk images must boot to the initial-setup utility." 17:11:39 #topic (2240490) Using shift lock on character with accent produces lower case character with accent 17:11:39 #link https://bugzilla.redhat.com/show_bug.cgi?id=2240490 17:11:39 #link https://pagure.io/fedora-qa/blocker-review/issue/1350 17:11:39 #info Proposed Blocker, mutter, NEW 17:11:40 #info Ticket vote: FinalBlocker (+0,1,-2) (nielsenb, -lruzicka, -geraldosimiao) 17:11:41 #info Ticket vote: FinalFreezeException (+1,1,-0) (+augenauf, nielsenb) 17:12:05 so this is a fun one, which I assume EN-based people will have just a fuzzy idea about 17:12:21 it seems pretty straight forward 17:12:27 but which criterion does it hit? 17:12:28 but even though currently it has -1s, I think we should consider +1 blocker 17:12:46 this one is somewhat related: https://fedoraproject.org/wiki/Fedora_39_Final_Release_Criteria#Keyboard_layout_configuration 17:12:53 but not really well 17:13:23 we don't have a criterion for "keyboard must work", because it's such a basic thing that we haven't really specified it 17:13:56 I see this as bad if a user has a password with an accented character in it. 17:14:06 however, if you want to input a long text in capital letters, FOR WHATEVER REASON, it's extremely unpleasant when half of your letters don't work 17:14:13 well, produce a lowercase letter 17:14:29 yeah, that's the case that concerns me the most - breaking disk encryption 17:14:41 coremodule: that's probably not a problem, actually, if he can see what he's typing 17:14:52 and also it's unlikely that people have their passwords all in uppercase 17:14:58 so that they would use capslock 17:15:04 as in see the keyboard as he types, or see the input on the screen? 17:15:33 dis encrypt - you mean on bootup? 17:15:34 if you type a single letter, you don't have this problem. Because you use Shift to make the accented letter uppercase, and that works 17:15:41 disk* 17:15:49 this problem is only when you want to use capslock to write a longer text in uppercase 17:16:01 ahhh 17:16:04 which is not common, but still I think it should be a baseline that just must work 17:16:20 kparal, what did you say at the beginning about EN keyboard users not really knowing what's going on here? :D 17:16:31 only with capslock on, the accented letters are written in lowercase when they should be in uppercase 17:16:49 so the workaround is to use Shift a lot, and write them individually 17:17:09 for the non-encryption case, it could be solved post-release with an update? no? 17:17:17 sure 17:18:19 the case that worries me the most is passwords and disk encryption, even if using caps/shift lock for those isn't likely 17:18:20 I think you can imagine that for an EN keyboard, one line of letters would produce lowercase, the rest uppercase 17:18:26 would that be a blocker? 17:18:50 (with capslock on. Shift would work as expected) 17:19:20 I mean I would always check the password used for encryption, and it a worst case, you could reinstall the OS, it wouldn't eat data or so 17:19:22 while annoying, I'm not sure it's a blocker for the general case 17:19:24 I am -1 Blocker here 17:19:42 I'm onboard with blocking due to the possible issue with encryption password or login password 17:20:04 I'm not concerned about that, because I don't believe anyone logs in with caps lock on intentionally 17:21:06 I've seen people use caps as shift - "CAPS LOCK + letter + CAPS LOCK" but I acknolwedge that it's very rare 17:21:34 kparal, what's your vote? 17:21:39 but then again, I don't use caps lock. it's remapped on the keyboards I use frequently 17:22:05 -1 blocker, +1 FE 17:22:15 I'm a bit more towards +1, just because I think these things shouldn't be compromised on, but I do agree that the severity here is not that high 17:22:39 so if you're -1, I won't cry :) 17:23:06 so I think we're -6/+2 17:23:17 +1 FE here 17:23:19 FWIW, I think I'd be -1 blocker for something like 'caps lock doesn't work at all' as well 17:23:23 who's the second +1? 17:23:43 adam? 17:23:44 adam... 17:23:45 :D 17:23:46 heh 17:23:54 :) 17:23:58 alright, let's close this as rejected 17:24:19 do we want it as an FE? 17:24:27 definitely 17:24:30 I feel like that's fair 17:24:32 +1 FE 17:24:39 +1 FE 17:25:02 proposed #agreed 2240490 - RejectedBlocker (Final) AcceptedFreezeException (Final) - After mulling it over, we find that the severity of this bug is low enough to not warrant blocking the release. We grant it FE status. 17:25:17 ack 17:25:24 sorry 17:25:25 patch 17:25:26 proposed #agreed 2240490 - RejectedBlocker (Final) AcceptedFreezeException (Final) - After mulling it over, we find that the severity of this bug is low enough to not warrant blocking the release on it. We grant it FE status. 17:25:44 * kparal plays spot 5 differences 17:25:44 just added "on it" 17:25:54 ok 17:26:00 thanks, I was looking for the change 17:26:00 ack 17:26:02 ack 17:26:14 #agreed 2240490 - RejectedBlocker (Final) AcceptedFreezeException (Final) - After mulling it over, we find that the severity of this bug is low enough to not warrant blocking the release on it. We grant it FE status. 17:26:23 #topic (2239121) the second part of btrfs volume is shown as not-mounted 17:26:23 #link https://bugzilla.redhat.com/show_bug.cgi?id=2239121 17:26:23 #link https://pagure.io/fedora-qa/blocker-review/issue/1335 17:26:23 #info Proposed Blocker, util-linux, NEW 17:26:23 #info Ticket vote: FinalBlocker (+0,0,-3) (-kparal, -nielsenb, -geraldosimiao) 17:26:47 this is not going to make Lili's happy, but I'm still -1 here 17:26:48 this already has -3 in blockerbugs, but we're here, let's talk about it one last time 17:27:17 this is the problem in the whole stack, from lsblk all the way up to gnome-disks and blivet-gui 17:27:30 and it worked like this for ages 17:28:03 and unlike the other bug in blivet-gui we talked about, I think the chance to accidentally lose data here is much lower 17:28:36 kparal, I just like the part where lnie called you the "picky revenge monster" 17:28:46 because if you installed btrfs on two drives, you probably remember that you did it and don't just erase partition on one of them without thinking about it 17:29:28 not sure why I earned that :-D 17:30:30 iow, the fact that the partition is not shown as mounted doesn't imply it can be simply deleted, you probably still want to examine its contents first. So I don't think the data loss scenario is that likely here. 17:31:01 -1 blocker, -1 FE 17:31:02 and realistically, a lot would have to change in the stack to make it display differently, I think 17:31:27 it's a problem, for sure but it's about post-install behavior and could be fixed with an update 17:31:28 -1 Blocker 17:33:19 proposed #agreed 2239121 - RejectedBlocker (Final) - 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 moot. We also acknowledge that a lot would probably have to change in the stack to fix it. 17:33:39 tflink: well Lili complains about the installer too 17:34:05 coremodule: those are just my theories :) 17:34:21 but I don't mind, ack 17:34:56 kparal, yes, but I agree, at least with the part about it being a more advanced use case than a basic user who is new would ever run into 17:35:15 I wouldn't go so far as to render the bug moot - it's still a bug and a problem but it does seem less likely that someone with multiple disks would go blindly deleting partitions without confirming that they're unused first 17:35:36 moot in that context, but i can make it read differently 17:35:53 proposed #agreed 2239121 - RejectedBlocker (Final) - 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. 17:36:36 I might just be slow but I don't understand how this bug affects the install process 17:36:54 ack 17:37:05 I think Lili removed one partition of an installed system by accident 17:37:16 because it was not shown as belonging together 17:37:33 one more ack? 17:37:49 frantisekz: poke 17:37:58 sure but if you're in anaconda, the existing partitions aren't going to be mounted. in order to act on the bad information, you'd have to be in the machine after install, no? 17:38:55 it's a rough equivalent of doing a 'sudo rm -rf /home' in the example case 17:39:15 I think you're right, Lili's just talking about the case of booting into the installed system 17:39:20 and then cleaning up partitions 17:39:35 frantisekz, thebeanogamer, amoloney, one more ack? 17:40:26 coremodule: you can vote too 17:40:48 I can vote, but can I ack? seems like a conflict of interest 17:40:52 ack 17:40:56