15:00:27 #startmeeting FESCO (2019-07-22) 15:00:27 Meeting started Mon Jul 22 15:00:27 2019 UTC. 15:00:27 This meeting is logged and archived in a public location. 15:00:27 The chair is ignatenkobrain. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:00:27 Useful Commands: #action #agreed #halp #info #idea #link #topic. 15:00:27 The meeting name has been set to 'fesco_(2019-07-22)' 15:00:29 #meetingname fesco 15:00:29 The meeting name has been set to 'fesco' 15:00:29 #chair nirik, ignatenkobrain, jforbes, zbyszek, bookwar, sgallagh, contyk, mhroncok, otaylor 15:00:29 Current chairs: bookwar contyk ignatenkobrain jforbes mhroncok nirik otaylor sgallagh zbyszek 15:00:31 #topic init process 15:00:34 .hello2 15:00:35 .hello2 15:00:35 sgallagh: sgallagh 'Stephen Gallagher' 15:00:36 morning. 15:00:38 jforbes: jforbes 'Justin M. Forbes' 15:00:48 hey 15:01:07 .hello2 15:01:08 otaylor: otaylor 'Owen Taylor' 15:01:10 .hello psabata 15:01:11 contyk: psabata 'Petr Šabata' 15:02:46 Apologies for not double-checking the channel availability 15:03:03 so are we going to use this one from now on or just today? 15:03:12 It'll have to be from now on 15:03:19 #f-m is usually taken by QA 15:03:24 It just happened to be canceled this week 15:03:40 okay 15:03:44 .hello2 15:03:45 np 15:03:45 bookwar: bookwar 'Aleksandra Fedorova' 15:03:47 .hello2 15:03:48 zbyszek: zbyszek 'Zbigniew Jędrzejewski-Szmek' 15:04:12 yes, let's use this channel and I'll make sure it shows up in calendar properly 15:04:18 ignatenkobrain++ 15:04:21 .hello2 15:04:22 bcotton: bcotton 'Ben Cotton' 15:04:40 so, let's start 15:04:42 I think that's everyone 15:04:44 #topic #2165 F31 System-Wide Change: Golang 1.13 15:04:45 .fesco 2165 15:04:47 ignatenkobrain: Issue #2165: F31 System-Wide Change: Golang 1.13 - fesco - Pagure.io - https://pagure.io/fesco/issue/2165 15:05:35 it probably should have been auto-approved since we have +3, but just to double check if we all agree here 15:05:49 I haven't followed this one closely. What's the potential issue? 15:06:09 we were waiting to hear about a few things... but I am not seeing what they were in the end... 15:06:10 ignatenkobrain: It didn't have +3 at seven days, so it's not yet approved 15:06:24 I voted +1 in the ticket ... 15:06:25 sgallagh: as i got it, there are no issues, just the Go maintainers figuring out who does what 15:06:46 bookwar: It looked a little like they weren't all pointing the same way. 15:06:50 Has that changed? 15:07:37 sgallagh: we had +3 after 7 days after we agrred to wait a week 15:07:58 i'd say we should approve the change and let the Golang group talk to each other on the group level, without FESCo being part of it 15:08:06 Well, as I said, I haven't been following this, so I'll just vote 0 and trust the rest of you 15:08:08 they have some arguments, but none of them is about what this change has proposed 15:08:18 as bookwar says 15:08:19 bookwar: +1 15:08:23 bookwar: +1 15:08:24 * nirik is +1 15:08:28 Right, the ticket is a mess, but the change itself seems fine 15:08:30 +1 15:08:43 * contyk squints 15:09:05 I abstain, just like the last time 15:09:11 +1 to the change - moving forward to the next version of go is a no-brainer, and the details of macros need to be sorted out by the maintainers 15:09:50 * otaylor hopes very much that fesco will not have to get involved to sort out interpersonal conflicts here 15:10:00 bookwar: mhroncok I count you as +1, right? 15:10:10 ignatenkobrain: count mhroncok as +1 15:10:21 * mhroncok voted in the ticket 15:10:22 * nirik agrees with otaylor there. 15:10:28 ignatenkobrain: yes, +1 15:10:52 #agree APPROVED (+7, 2, -0) 15:11:10 #topic #2172 F31 Self-Contained Change: Limit Scriptlet Usage of core packages 15:11:11 .fesco 2172 15:11:13 ignatenkobrain: Issue #2172: F31 Self-Contained Change: Limit Scriptlet Usage of core packages - fesco - Pagure.io - https://pagure.io/fesco/issue/2172 15:11:45 This is in no way a self-contained change, but I think it's very worthwhile. 15:12:05 I think it's worthwhile, but I don't know what the change is. 15:12:22 it seems more like a initiative than a change, per se 15:12:27 zbyszek: I thought you were involved with it. Did I misunderstand? 15:12:51 I think it's good, but a bit handwavy last I looked. 15:12:55 otaylor: Well, as I understand it the intent is to have anything that appears in the container base image use no non-macro scriptlets by F31 15:13:05 Not directly. I was discussing scriplets possibilities, but that's about it. 15:13:18 i agree with comments on the issue, maybe it is worth limiting the scope of the change to particular subset of scriptlets, where we _know_ how to get rid of them, before we declare that we get rid of everything everywhere 15:13:41 sgallagh: yeah, "How to test" says that - I'm a bit skeptical that's going to happen :-) ... but the initiative seems worthwhile 15:13:50 I like the idea of this change, I don't know that it is fully baked, and F31 seems aggressive. 15:14:11 Let me ask the question differently: 15:14:19 And it certainly is not self contained. 15:14:21 Does anyone see a reason why they should *not* attempt this for F31 15:14:22 ? 15:14:25 as each of the individual changes is implemetation detail, I don't think that actually doing this rewuires a change 15:14:33 proposal: Require upgrade to System-Wide change and list of scriptlets and how they should be replaced" 15:14:36 it's nice that it gets tracked, but how it is written it makes no sense 15:14:36 I mean, it wouldn't be the first time a Change took a few releases to finish. 15:14:40 * sgallagh looks pointedly at Python 3 15:15:05 bookwar: +1 15:15:11 sgallagh: all changes were exactly scoped for the release they were pointed at, or were explicitly described as "continuous effort" 15:15:13 well, it would be easy to roll it back 15:15:16 sgallagh: if I would know what exactly they want to replace by what, then I could think about it 15:15:25 if the replacement solution doesn't work as expected 15:15:31 it's not like we have filed a F26 change "swicth everything to py3" and than just said we didn't make it 15:15:34 mhroncok: Sorry, that was meant to be tongue-in-cheek, not an insult 15:15:43 sgallagh: not insulted 15:15:51 I don't see a harm in starting it for F31 15:15:51 sgallagh: trying to explain the difference 15:16:16 bookwar: does this imply that we will revisit it after they update change description? 15:16:28 ignatenkobrain: yes 15:17:00 bookwar: then I'm +1 to what you proposed 15:17:26 so am I 15:17:35 Yeah, I can get behind that. +1 15:18:15 What exactly is the proposal? 15:18:16 I'm -1 for the change as as, as said. what bookwar says doesn't IMHO require a vote, but if needed, can +1 15:18:17 +1 - though i don't think "a list of scriptlets and how they should be replaced" needs to - or perhaps evne *should* be in the change proposal itself - that seems like evolving documentation 15:18:25 bookwar: +1 15:18:40 zbyszek:17:14 proposal: Require upgrade to System-Wide change and list of scriptlets and how they should be replaced" 15:19:03 * mhroncok wonders whether the should be a deadline for the required update of the proposal 15:19:29 mhroncok: I think 2 weeks is good enough 15:19:39 otaylor: i was thinking that there will be a list of "_must_ be removed before F31 release", like the minimal goal, while there will be more of "should be removed but may be later" 15:19:43 otaylor: well, I would not expect an exact list, but numbers and types I would think would be possible now... so we know the scope ? 15:20:06 nirik: +1 15:20:51 proposed #agree Change must be upgraded to System-Wide. Scriptlet types, their replacements and rough numbers should be added. 15:21:09 rough numbers? 15:21:34 s/rough/approximate/ 15:21:40 numbers of what? 15:21:49 yes, that's what I wanted to say 15:21:51 packages affected, I'm assuming 15:22:15 s/rough numbers/approximate numbers of packages affected/ 15:22:41 if you put that in the actual proposal, ack 15:23:43 "Change must be upgraded to System-Wide. Scriptlet types, their replacements and approximate numbers of affected packages should be added." 15:23:52 +1 15:23:54 +1 15:23:56 +1 15:23:59 +1 15:24:01 +1 15:24:15 +1 15:24:15 +1 15:24:27 +1 15:24:40 #agree Change must be upgraded to System-Wide. Scriptlet types, their replacements and approximate numbers of affected packages should be added. (+9, 0, -0) 15:24:46 #topic #2168 F31 Self-Contained Change: DNF Make Best Mode the Default 15:24:48 .fesco 2168 15:24:49 ignatenkobrain: Issue #2168: F31 Self-Contained Change: DNF Make Best Mode the Default - fesco - Pagure.io - https://pagure.io/fesco/issue/2168 15:25:48 So, I understand the desire for the DNF team to try to keep Fedora and RHEL on the same defaults, but I think zbyszek's argument convinced me that it's not right for Fedora. 15:26:06 I have not seen anything to change my view from in ticket. 15:26:51 i don't agree that minimize discrepancies is always better, i think that clear failure in case of something is worng is important 15:26:58 so i am +1 for a change actually 15:26:59 * mhroncok was waiting for the proposal owners to talk to us, but is seems that this is not going to happen until we decline the change 15:27:16 yeah, not much input from them in ticket. ;( 15:27:26 exactly none 15:27:53 but that security argument is still amusing because it's what you can use to argue both for and against this 15:27:56 I was talking to them before they've refiled this change, suggested some changes, but some of them are ingored 15:27:58 bookwar: I agree that clear failure is good *if the user can do something about it* 15:28:16 it seems that they just want to flip the switch but donẗ have the manpower to change anything about the UX if they do 15:28:45 Given the status of Fedora and its third-party repos, all that will happen is that every guide on the internet will just say `alias dnf='dnf --nobest'` and nothing will change except our reputation. 15:29:24 well, I think most people will use --skip-broken... 15:29:30 Well, whichever 15:29:30 contyk: The security argument is a lot better without --best. Sure, you could miss something, but much more likely to catch updates that you wouldn't see with --best 15:29:52 (since thats what it says to do) 15:29:58 * mhroncok is thorn, because I don't like this change but I see how the dnf team is getting more and more frustrated by "us" blocking "them" 15:30:19 I'm a weak +1, I wish it was better, and I understand the folks who are -1 15:31:10 sgallagh: i have a feeling that being honest about our errors _is_ our reputation, even though it can cause some user complains, but that's my personal opinion, we don;t have to argue about it 15:31:20 skip-broken actually doesn't really help sometimes... like right now with my laptop :( 15:31:47 well, when we discussed this the last time I was for enabling best=1 in stable but not in rawhide 15:31:51 regarding UX i think that we all agree that it can be better, so the question is _when_ it should become better, before or after the switch 15:31:53 bookwar: it isn't just our errors though, it is a combination of us and 3rd party repositories 15:31:54 without a proper UX proposal, I'm afraid I'm -1. we repeatadly asked to at least call the best/nobest option more descriptive and there was no response 15:32:00 I'm -1 here - doing this would require a) real work on the CLI user experience and error messages b) better testing of the Fedora repos before we push changes c) changing PackageKit as well, so that updates are actually consistent 15:32:03 ale making sure our repos don't have any problems, via bookwar ;) 15:32:09 but of course there's still the third party problem 15:32:36 making sure our repos don't have any problems seems like very long term goal 15:32:58 our repos have problems and we need to count with what we have 15:33:11 not with what we would liek to have 15:33:14 *like 15:33:14 contyk: You'd have to get to the point where the code could say "package X that you have installed on your system from a third party repo is causing problems upgrading, do you want to remove it" 15:33:19 contyk: again, i don't see it as a problem. if third-party repo is failing - we should inform the user as well, and user needs to channel hist frustration towards the third-party repo, or change the default 15:33:25 mhroncok: making sure our repos don't have problems seems like a goal we should already have. making sure 3rd party repos don't have problems becomes an impossible task 15:33:43 jforbes: that is indeed true 15:34:16 bookwar: They don't channel frustration towards the 3rd party respo, they complain on reddit that fedora sucks. (see recent issues with negativo) 15:34:48 bookwar: that would require dnf to somehow recognize distro and third party repos 15:34:49 jforbes: that's what redditers always do, we shouldn't be driven by that (my imho of course) 15:35:06 gating our composes to not include broken deps should be achievable 15:35:08 it seems I lost connection =( 15:35:17 improving the UI of the error messages should also be achievable 15:35:25 yes, and we are working torward all that. :) 15:35:31 is it my internet connectivity or everyone is still reading change? :) 15:35:31 is it my internet connectivity or everyone is still reading change? :) 15:35:41 ignatenkobrain: it's you 15:35:46 I'll send you a log. 15:35:48 it's always Igor 15:35:50 is it my internet connectivity or everyone is still reading change? :) 15:35:53 oh god! 15:36:01 my old message is being delivered 15:36:19 bookwar: it is what they do, just saying our own reputation can take a hit based on what 3rd party repositories do. 15:36:39 ignatenkobrain_: https://paste.fedoraproject.org/paste/7uEc6NiHj9CbJAykk7yqyA 15:36:53 my other concern was that this switch doesn't propagate to GUI, as far as I understand it 15:37:10 so you'd get different behavior from the graphical tools and different from dnf cli 15:37:11 contyk: it is achievable, so i'll again go back to the question - "_when_ it should become better, before or after the switch". I am ok with making switch first, and UX later as it was done by upstream 15:37:12 anyhow, I think everyone has their opinions... lets just count the votes and move on? or is anyone on the fence here? 15:37:44 let me count votes from ticket and backlog 15:37:52 contyk: cli vs gui difference i think is a feature not a bug here 15:37:53 Let's just revote, since we're all here 15:37:55 It'll be simpler 15:37:57 * contyk can't decide between 0 and -1 15:38:12 bookwar: giving users a bad user experience because we're going to fix things later is a very good way to lose users permanently :-) 15:38:16 Proposal: Accept the Change and make DNF use --best by default 15:38:18 -1 15:38:23 -1 15:38:40 -1 15:38:47 bookwar: updating my system differently based on what tool I happen to use is something I wouldn't consider a feature :) 15:38:47 -1 15:38:50 anyway, -1 this time 15:38:51 otaylor: the users will have gui for tasks where they don't care about things 15:38:51 still -1 15:38:57 -1 15:39:30 is it a permanent -1 or "-1 until UX gets better"? 15:39:43 bookwar: No vote is ever permanent 15:39:45 how do you usually record decisions like REJECTED? +1 means (for rejected or against) :) 15:40:08 sgallagh: ok 15:40:09 ignatenkobrain: #agreed Change is rejected (+0, 0, -6) 15:40:28 so i am +1 for a change, for the record 15:40:38 and I was also weak +1. sorry 15:40:41 "a change" or "the change" 15:40:50 zbyszek: :) 15:40:59 both 15:41:03 change the changes 15:41:21 #agree REJECTED (+2, 0, -7) 15:41:24 change all the changes 15:41:40 #topic Next week's chair 15:41:43 ch... ch... ch... changes... 15:41:58 I can do next week 15:42:02 I'll be out next week, but I can take the week after 15:42:07 so, is the i686 trees thing next week? 15:42:25 nirik: it was just ticketed today 15:42:25 nirik, oh right, Miro opened ticket only today so I forgot about it... 15:42:35 nirik: No one proposed it for discussion today, though if you want to raise it in Open Floor, that' 15:42:35 nirik, let's vote in ticket and see next week. ok? 15:42:40 s your prerogative 15:42:50 sgallagh, that works too. 15:42:57 sure, no great hurry... 15:43:16 ok, so I guess I'll chair next meeting :) 15:43:19 I think the biggest issue surrounding the no more i686 trees is developer education 15:43:40 ignatenkobrain_: you're doing a great job, but we don't want to burn you out. 15:43:41 #action ignatenkobrain will chair next meeting 15:43:49 #topic Open Floor 15:44:04 zbyszek, that's okay. but the weekafter somebody else will have to do it :) 15:44:04 jforbes: that's way we should follow as many formalities around it as we can 15:44:23 ignatenkobrain_: Mark me down for it, since I won't be here next week to volunteer 15:44:28 for the open floor I have one thing 15:44:38 https://pagure.io/fesco/issue/2146#comment-584080 15:44:38 well, I think we can make it pretty seamless... for those few developers using i686 that are out there. 15:44:45 that's the flock week, sgallagh 15:44:53 just small FYI about modules vs libgit breakage ^ 15:45:03 oh geez, is it really? 15:45:09 you might be travelling 15:45:15 wow, that's coming right up 15:45:42 contyk: I 15:45:50 so, on the libgit thing... how about a devel-announce post explaining that you should do reset on it if you are using rawhide? 15:45:51 I'm flying on Tuesday, so that should be fine 15:46:17 btw, talking about Flock 15:46:44 can people who are coming to our panel on Flock tell me their preferred sched.org email addresses? 15:47:02 sure; petr@sabata.xyz 15:47:08 ignatenkobrain: miro at hroncok.cz 15:47:27 kevin@scrye.com for me 15:47:42 i think i have several accounts i need to merge :( 15:47:43 but I've answered my prefered shed email address to all flock email queries and I got an shed email to a different address anyway 15:48:00 ignatenkobrain i'll send it to you a bit later 15:48:01 worked fine for me :) 15:48:04 jmforbes@linuxtx.org I suppose 15:48:12 bookwar, sure 15:49:02 zbyszek, otaylor: are you attending Flock too this year (I don't remember)? 15:49:16 ignatenkobrain_: I am not attending Flock this year 15:49:39 ignatenkobrain_: I am 15:49:53 * zbyszek was trying to figure out his sched.org login 15:50:14 ignatenkobrain_: stephen.gallagher.31 is the account and I think it's my IRC nick at redhat.com for the email 15:50:15 zbyszek@fedoraproject.org 15:50:43 ok, so I'll make sure you are added to the talk. 15:50:50 that's it from me 15:51:35 * sgallagh has nothing else 15:51:39 ignatenkobrain_: can you do a devel-announce on the module reset? or does someone else want to? 15:51:43 or I guess I could... 15:52:04 nirik, module reset is only needed during the upgrade to F31 15:52:11 so I guess this should be in common bugs or so 15:52:50 ah, I thought it was also needed for existing rawhide users. 15:53:41 nirik: Do we have any of those that aren't also FESCo members? :) 15:54:04 nirik, existing rawhide is entirely fine since they were on 0.28.x already 15:54:04 perhaps a few 15:55:47 ok 15:56:05 so... anyone anything else? :) 15:56:10 nope 15:56:53 So I'll close in 15 seconds if nobody speaks up 15:57:17 #endmeeting