15:00:05 #startmeeting FESCO (2019-05-06) 15:00:05 Meeting started Fri May 3 15:00:05 2019 UTC. 15:00:05 This meeting is logged and archived in a public location. 15:00:05 The chair is jforbes. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:00:05 Useful Commands: #action #agreed #halp #info #idea #link #topic. 15:00:05 The meeting name has been set to 'fesco_(2019-05-06)' 15:00:05 #meetingname fesco 15:00:05 The meeting name has been set to 'fesco' 15:00:05 #chair nirik, bowlofeggs, jforbes, zbyszek, bookwar, sgallagh, contyk, mhroncok, otaylor 15:00:05 Current chairs: bookwar bowlofeggs contyk jforbes mhroncok nirik otaylor sgallagh zbyszek 15:00:05 #topic init process 15:00:13 .hello psabata 15:00:13 contyk: psabata 'Petr Šabata' 15:00:29 .hello2 15:00:33 bcotton: bcotton 'Ben Cotton' 15:00:49 .hello2 15:00:51 sergiodj: sergiodj 'Sergio Durigan Junior' 15:01:17 .hello2 15:01:18 ignatenkobrain: ignatenkobrain 'Igor Gnatenko' 15:01:20 .hello2 15:01:23 .hello2 15:01:23 zbyszek: zbyszek 'Zbigniew Jędrzejewski-Szmek' 15:01:26 bowlofeggs: bowlofeggs 'Randy Barlow' 15:02:16 .hello2 15:02:17 sgallagh: sgallagh 'Stephen Gallagher' 15:02:22 morning 15:02:26 Yay quorum 15:02:42 jforbes: might be good to add a topic to the end for the election, since f30 is released 15:02:50 hey, sorry for being late 15:03:26 what sort of topic? 15:03:43 jforbes: maybe it's not a topic, but a reminder ha 15:04:00 #topic #2088 F31 Change – “dnf --best” as default behavior 15:04:00 .fesco 2088 15:04:00 https://pagure.io/fesco/issue/2088 15:04:02 jforbes: Issue #2088: F31 Change – “dnf --best” as default behavior - fesco - Pagure.io - https://pagure.io/fesco/issue/2088 15:05:33 So we said we wanted a response from jmracek and we got one 15:07:25 There is still the issue of whatever due diligence we do to ensure that our repositories are not broken, we have no control over any 3rd party repos that users have enabled 15:08:36 FWIW, I'm still -1. jmracek's answers did not change this. 15:08:36 is pagure down? i can't post on it :/ 15:09:10 seems so 15:09:31 sent an e-mail instead 15:09:55 it's fine here? 15:10:10 back up 15:10:12 bowlofeggs: e-mail to what address? 15:10:36 zbyszek: /dev/null 15:11:15 zbyszek: i replied to pagure via e-mail, hoping that a faithful SMTP server would eventually get it to the ticket ☺ 15:11:28 seems that it did not make it 15:12:05 honestly, i am +1 for a change, and I am ok with gnome software having different behavior. For me cli tooling is needed when I am looking for more precise and clear info than when I am using GUI, so my expectation is that gnome software tries to make it nice, but dnf should be honest about any error happening in the background 15:12:23 Does this mean we need to let this stew more in ticket? 15:12:48 jforbes: I don't think stewing more is going to yield a tastier ... ticket. 15:12:59 Let's just get on with it and make a vote. 15:13:04 bookwar: I agree that cli doesn't need to match gnome 15:13:07 and i would be worried if we put "the impression we make on users" over the "clear and honest reply in case of errors" at least in cli 15:13:26 i think there are two parts of the problem: 1) "broken upgrade paths in the Fedora repositories" - and we should really do our best to detect this before we ship it tot users 15:13:46 2) given that (1) is solved, what should be the default for 3rd party repos 15:13:55 * nirik doesn't think we should depend on users to file bugs about dep problems in our repos. ;( 15:14:37 mhroncok: we have zero control over 3rd party repos. We generally do a good job with 1. 15:14:47 otaylor seems to feel strongly about differences between cli and gui, but i personally think it's ok for them to have different behaviors - i'd be interested to hear his perspective more, as i think he's thougth about it more than i have 15:14:57 jforbes: we do a good job? 15:15:15 jforbes: no, not at all. Check how many broken upgrade paths we still have for F29 to F30. 15:15:32 There's even one in common bugs for ant/maven/something that we can't seem to solve. 15:15:35 zbyszek: upgrade paths are different than update paths 15:15:39 my personal worry here is that a user could miss a critical security update because ffmpeg can't install 15:15:45 we have plenty of uninstallable packages with broken depencnecies in the repos, some broken since Fedora 26 15:15:54 like, a security update in something from us 15:16:08 (i used ffmpeg since that's 3rd party, not because it fails to install - it works great ☺) 15:16:22 mhroncok: yep... but we should fix that 15:16:33 we totally should 15:17:02 i think we cannot approve this before we fix it 15:17:10 and even then, the 3rd party problem remains 15:17:19 best is global right? 15:17:33 it sounds global, but i'm not sure 15:18:02 it happens quite often for me that virtualbox kmod whatnot or chromium freeword libs get out of sync and are skipped in update 15:18:21 and i still get all other updates 15:18:44 this would just fail and stop, right? 15:19:09 yep 15:19:15 until you passed --no-best 15:20:09 that makes me say: -1 until we can mitigate our own problems server side, -0.5 after that 15:20:15 the proposal doesn't really clearly state what the user experience will be when there's a problem 15:20:28 I wonder if this could be a per repo setting... so we set ours to just best=false and 3rd party get default... and we switch to best=true once we have our repos better fixed? 15:20:53 bowlofeggs: I think it does. The expecations is that bugs will be filed, and the user will use --no-best after careful review of the problem. 15:21:03 not sure what the behavior would be there nirik 15:21:04 i get that they can say --no-best, but how will the user know to do this? will the user *understand* what is happening? 15:21:07 that's not realistic 15:21:25 will they know if they are missing an important security update if they *don't* use --no-best? 15:22:34 bowlofeggs: There isn't anything that lists CVEs in the default output, and even if there were, that wouldn't exactly convey the urgency 15:23:31 yeah, and today the user would get the security updates that can be installed, so it's less of a problem 15:23:34 for me it is not about triggering users to file bugs, but about providing proper feedback and reporting the error when it happens, not trying to make an impression that there wasn't anything about it 15:23:55 we don't require people to file bugs but we are open about what is going on 15:23:56 but this proposal will stop them from getting security updates when *any* repo has a problem, and it will not tell them they are missing those updates 15:24:01 i think i dislike that about this 15:24:27 if it gave a warning that they were missing security updates *and* told them they might be able to get them with --no-best that might assuage my fears 15:25:15 And what about automated runs of dnf update -y 15:25:30 where people don't ever look at the output 15:25:31 that should use dnf-automatic. ;) 15:25:36 yeah automated runs just won't get it, unless someone is reading their cron e-mails 15:25:55 but does dnf-automatic use --no-best? 15:26:00 and/or, can it? 15:26:06 not currently, but it coud 15:26:08 nirik: some of us are lazy, if it ain't broke... 15:26:22 you can override any dnf setting in automatic... so you could set best=whatever 15:26:27 bowlofeggs: do we have security updates configured by default? 15:26:34 (if you knew to) 15:27:18 nirik: but yeah, you'd have to know to as well 15:27:36 bookwar: default in what? 15:27:40 bookwar: we don't limit to security, but I am guessing most users simply run 'dnf update' to get everything 15:28:23 i mean automated security updates are not enabled by default in workstation, user needs to enable them explicitly? 15:28:51 yes, we don't enable any auto updating at all for rpms 15:29:02 (but we do for flatpaks) 15:29:38 bookwar: oh you mean for gnome software? 15:29:57 i dont' think this proposal should affect gnome software, though i could be wrong 15:30:22 bookwar: but yeah, i don't think we do any automated updates 15:30:32 (I would like to vote or move on) 15:30:34 (by default) 15:30:41 then i think we don't change that much: those who run `dnf update` manually will react on errors, those who configure security updates, need to configure them anyway, those who get updates from gnome software will use behavior from gnome software 15:31:10 bookwar: well it does change because today users will get security updates when possible 15:31:17 and that's my concern 15:31:35 now they get a hard to understand error, and won't be told the importance of using --no-best 15:31:48 it seems like a disservice to me 15:32:08 bookwar: people who do a 'dnf update' now will get security updates, they just may not know that they are security updates. And I would guess a lot of people see a failed command output and figure try again tomorrow. 15:32:52 perhaps they run --skip-broken if it is recommended in the output 15:33:59 i think i would not mind this if there were very clear messages to the user, including informing them of whether there are secuity updates that might apply if --no-best is used 15:34:15 but the proposal doesn't really talk about the user experience very explicitly 15:34:28 shall we vote? or punt down the road? 15:34:36 the peoposal is very clear: change the default 15:34:40 Either way, the change request isn't changing, so we need to vote or bring it back to the ticket 15:34:46 of course, the security updates could still fail even with --no-best, but that's a problem we can't fix here ☺ 15:34:50 I don't think thay planned to update the error messages, etc. at all 15:35:09 mhroncok: i think without better error messaging, i'm a -1 15:35:16 bowlofeggs: i understand that security update is important, but it is just one aspect. Imaging person who runs `dnf update`, doesn't get errors, goes away, only to realize that the update wasn't actually installed. I was that person, and i actually filed an issue about that in bugzilla couple of years ago, because it is confusing and misleading 15:35:43 bookwar: yeah i agree that is also a bad thing 15:35:58 i think this is making it worse though, unless it has better error messaging 15:36:24 it could in theory even do both... 15:36:26 i'd rather have today's problem than the problems i perceive with this proposal, if that makes sense 15:36:58 bowlofeggs: would you be able to write specific requirements to the ticket? 15:37:06 dnf update ... "foo-1.2-1.fc30 has broken deps" "continuing with --no-best to apply everything else" 15:37:24 ok, my vote is -1, but i can also express to the OP that i could be flipped to a +1 by amending the proposal to have a "what the user sees when there's a problem" section that addresses my concerns 15:37:36 mhroncok: yeah 15:37:40 nirik: or even interactivity 15:37:53 bowlofeggs: so let's do that and punt in the meantime? 15:38:07 but, if the other fesco members get +5, we can also just approve this and move on ☺ 15:38:08 I'm also -1 to the current proposal, but would ask the change owner to discuss with the community the best behavior here and revisit and resubmit. 15:38:26 bowlofeggs: they won't get +5 15:38:44 nirik: I like this above just rejecting... 15:38:45 cool. in that case i'll write up my thougths on the ticket and what it would take to get me to be +1 15:38:55 I'm -1 for the moment as well. I think `--best` is a better long-term solution, but I agree the messaging and current state of broken repos is problematic. 15:38:57 #action bowlofeggs will document how to get him to vote +1 15:39:05 proposal: bowlofeggs will update the ticket with concerns that need to be addressed before we vote 15:39:05 The latter is less of a problem for RHEL 15:39:16 jforbes: +1 15:39:27 jforbes: +1 15:40:07 +1 15:40:31 sure, +1 (I don't know that we need to vote on it) 15:40:43 ack 15:40:45 #agreed bowlofeggs will update the ticket with concerns that need to be addressed before we vote 15:40:59 ack 15:41:37 #topic #2125 F31 System-Wide Change: Set skip_if_unavailable default to false 15:41:38 .fesco 2125 15:41:38 https://pagure.io/fesco/issue/2125 15:41:39 jforbes: Issue #2125: F31 System-Wide Change: Set skip_if_unavailable default to false - fesco - Pagure.io - https://pagure.io/fesco/issue/2125 15:42:51 here it seems the dicussion that was supposed to happen on devel moved to the ticket 15:43:24 I'm happy to treat this as an internal detail under discretion of the DNF maintainers. Fedora already sets it for its own repos (with one exception), so the default doesn't change much. I don't think we need to micro-manage this. 15:43:46 zbyszek: I tend to agree 15:44:13 Though making it a change request also helps ensure the changed default gets communicated 15:44:29 I'd also argue that skip_if_unavailable=false is a better default. 15:44:50 jforbes: yep, and that's a totally reasonable use of the Change process 15:44:52 and again, UX is not part of the proposal 15:46:02 I have concerns, but I tent to agree with zbyszek 15:46:13 *tend 15:46:23 * nirik is fine just saying +1 here, let them handle UI (with input from interested parties for sure) 15:46:37 +1 15:46:53 +1 15:46:57 +1 15:46:59 UI could/should be improved. Right now it just says Error: Failed to synchronize cache for repo '...'. 15:47:02 +1 15:47:02 although kalev makes a good point 15:47:21 also +1 15:48:39 yeah i think kalev's argument is sound 15:48:45 nirik: some of the 3rd party repos explicitly set it anyway (negativo for instance) 15:48:50 also as a side note, copr also sets this true 15:49:12 as long as this is documented behavior, with proper actionable error messages, it doesn't matter 15:49:40 * nirik nods 15:50:29 bookwar bowlofeggs? 15:50:34 i'm on the fence 15:50:41 it seems pretty similar to the last ticket to me 15:51:08 again, a third party repo can cause a user not to get updates because of a default (obvs, they can cause it now by just having the setting in the repo file…) 15:51:25 bowlofeggs: no matter what the default is, they have that power 15:51:26 and again, security updates could be missed 15:51:39 jforbes: yeah, but the default makes it more likely to happen 15:51:44 the proposed default i mean 15:51:53 One can also argue that there are just as many security issues in 3rd party packages 15:52:08 jforbes: i am +1 15:52:10 well i wouldn't say "as many" just because we have way more packages than they do 15:52:25 i'm happy to be out voted, but i'm -1 unless there is also good messaging here too 15:52:34 bowlofeggs: we have a massive number of packages that are less exposed, and are not installed 15:52:57 and the messaging is pretty clear, the update errors out with which repository can't be reached 15:53:06 proposal: ... 15:53:25 looks like we have +5 anyway, so let's just accept and move on ☺ 15:53:26 change is approved, but the error message must be actionable by the user 15:53:47 we don't have to be unanimous 15:53:54 mhroncok: again, the error message is pretty clear. 15:54:07 failed to synchronize ? 15:54:18 yes 15:54:37 does it say how to disable the repo or make it skip if unavailable permanently? 15:54:45 mhroncok: no 15:54:52 like the last one, it doesn't tell the user that they are missing important security updates that might be retrievable with the flag though 15:54:54 then it's not actionable 15:56:17 mhroncok: proposal: change is approved on the condition that the error message must specify a hint how to skip the unavailable repo 15:57:08 and how to to restore the previous default for it 15:57:09 the "User experience" section of the change should show proposed dnf output of what the UX would be like 15:57:17 yes 15:57:23 zbyszek: while not a bad idea, I don't think the change should be contingent on it 15:57:44 mhroncok: i don't think we should put the whole "how to disable a repo" doc in error message 15:57:56 (we do have a majority +1, so we can just approve and move on) 15:58:09 I think we are getting to low level here... I don't think we want to do UX design for dnf here? 15:58:19 bookwar: the hint would essentially be 'Use --disablerepo=foo as a work-around.' 15:58:21 I mean, it could use some work, but... 15:58:21 nirik: exactly 15:58:23 nirik: well UX does matter when security updates are on the line 15:58:25 but adding smth like "failing due to skip_if_unavailable=false" would be nice 15:58:44 UX is part of any human interactive program spec 15:58:49 and this is a spec 15:59:04 so i think it is good to specify the UX 16:00:02 sure, but are we all on the dnf team? should we go over their PR's next? 16:00:07 bowlofeggs: but it isn't tied to this change. There have been security issues in rpmfusion packages, which could have just as easily been failed because fedora-repos weren't available 16:00:12 I guess they did submit the change, but still... 16:00:40 jforbes: i believe this change will make users more likely to miss security updates in fedora's repos, which is why i am concerned 16:00:45 it seems just like the last ticket to me 16:00:56 ok, let's count the votes for the change as is, and we can submit our unsolicited UX advice perosnally 16:00:59 i.e., i think it will raise the frequency of users missing security updates 16:01:09 mhroncok: +1 16:01:11 bowlofeggs: I disagree 16:01:13 mhroncok: ack 16:01:19 jforbes: ok 16:01:33 i'm -1 to the change as is, but we have a majority +1 so that's fine ☺ 16:01:41 FYI, another datapoint: rpmfusion repos don't seem to set this, so they would get the default currently 16:01:42 #agreed F31 System-Wide Change: Set skip_if_unavailable default to false is approved (+7,0,-1) 16:02:30 nirik: though they likely might change that if the default no longer meets their desired behavior 16:02:44 sure, they could... 16:03:27 #topic #2126 F31 Change: Minimal GDB in buildroot 16:03:27 .fesco 2126 16:03:27 https://pagure.io/fesco/issue/2126 16:03:28 jforbes: Issue #2126: F31 Change: Minimal GDB in buildroot - fesco - Pagure.io - https://pagure.io/fesco/issue/2126 16:03:44 * bowlofeggs is +1 in ticket 16:03:52 * mhroncok is +1 in ticket 16:03:56 +1 here 16:03:57 I am +1 16:04:07 do we want this to wait the usual week for ticket voting though? 16:04:17 * sergiodj is here in case you have any questions 16:04:20 I did, but sgallagh asked it be included 16:04:24 ah 16:04:41 sgallagh: did you have something you wanted to discuss on this one, or did you just want to fast track it? 16:04:47 (ticket wasn't even filed yet when I did the agenda) 16:04:52 I don't think there is much point in delaying things 16:04:54 * nirik is +1 16:05:54 +1 as well 16:06:47 #agreed F31 Change: Minimal GDB in buildroot is approved (+6,0,0) 16:07:13 bowlofeggs: The maintainers asked if it could be discussed. The ticket was just late. 16:07:22 ah cool 16:07:24 +1 16:07:26 would +6 demand a week has passed? 16:07:27 no worries 16:07:37 mhroncok: My +1 makes it +7 16:07:39 mhroncok: normally yes, but if we do it in a meeting it's fine 16:07:41 +7 makes it ok 16:07:54 #topic Next week's chair 16:08:00 me 16:08:11 #action mhroncok will chair the next meeting 16:08:14 I may not make it next week. Summit recovery 16:08:20 #topic Open Floor 16:08:27 I would appreciate if we can get +7 on https://pagure.io/fesco/issue/2122 16:08:30 #info FESCo elections are coming soon! 16:08:32 sgallagh: have fun at summit 16:08:58 ignatenkobrain: approved tomorrow anyway 16:09:28 ah 16:10:11 unless your bringing attention to it here gets someone on the fence to -1 it :) 16:10:31 * zbyszek votes _1 16:10:36 just joking ;) 16:10:53 Anything else for open floor? 16:11:36 Reviews of F30 are generally favorable. 16:11:40 It's always nice to see this. 16:11:48 Indeed it is 16:12:24 some are running into issues in #fedora over the hidden grub 16:12:48 Southern_Gentlem: actual issues, or just confusion? 16:13:04 both 16:13:09 yesterday I had issues with grub as well 16:13:24 bowlofeggs: is there anything special fesco should do before or during the elections? 16:13:27 anyway, don't want to extend the meeting 16:14:16 mhroncok: i don't think so, other than nominate and fill out interviews if your seat is up for grabs 16:14:21 mhroncok: I think they generally file a ticket for feedback on interview questions 16:14:35 i actually don't plan to run again this round, because i'm having a baby in like 2 months and will be MIA as a result for a long time 16:14:47 bowlofeggs: congrats! 16:14:52 but i think i will run again next round! 16:14:55 thanks! 16:14:58 bowlofeggs: congrats! 16:15:12 Okay, if nothing else for the meeting... 16:15:16 bowlofeggs: yeah, like the next 18 years ;-) congratulations, though 16:15:20 hahaha 16:15:20 bowlofeggs: Congratulations :) 16:15:35 bowlofeggs: congrats, will miss you 16:15:39 #endmeeting