15:00:02 #startmeeting FESCO (2018-10-15) 15:00:02 Meeting started Mon Oct 15 15:00:02 2018 UTC. 15:00:02 This meeting is logged and archived in a public location. 15:00:02 The chair is contyk. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:00:02 Useful Commands: #action #agreed #halp #info #idea #link #topic. 15:00:02 The meeting name has been set to 'fesco_(2018-10-15)' 15:00:05 #meetingname fesco 15:00:05 The meeting name has been set to 'fesco' 15:00:09 #chair nirik, maxamillion, jsmith, jforbes, zbyszek, tyll, sgallagh, contyk, bowlofeggs 15:00:09 Current chairs: bowlofeggs contyk jforbes jsmith maxamillion nirik sgallagh tyll zbyszek 15:00:13 #topic init process 15:00:17 .hello psabata 15:00:18 contyk: psabata 'Petr Šabata' 15:00:22 .hello2 15:00:23 jforbes: jforbes 'Justin M. Forbes' 15:00:23 .hello2 15:00:25 .hello2 15:00:25 sgallagh: sgallagh 'Stephen Gallagher' 15:00:28 zbyszek: zbyszek 'Zbigniew Jędrzejewski-Szmek' 15:00:29 morning all 15:00:30 .hello2 15:00:34 bcotton: bcotton 'Ben Cotton' 15:00:50 .hello2 15:00:51 bowlofeggs: bowlofeggs 'Randy Barlow' 15:01:11 seems we have a quorum 15:01:28 if we owned a quarry, it could be a quarry quorum 15:01:41 and if we had a problem, it would be a quarry quorum conundrum 15:02:11 /kick bowlofeggs 15:02:20 :) 15:02:31 so the php change proposal was approved and announced 15:02:37 that leaves us with one lovely ticket 15:02:44 haha 15:02:46 #topic #1974 Problematic blocker for F29: dnf 'offline' module tracking 15:02:49 .fesco 1974 15:02:52 contyk: Issue #1974: Problematic blocker for F29: dnf 'offline' module tracking - fesco - Pagure.io - https://pagure.io/fesco/issue/1974 15:02:52 https://pagure.io/fesco/issue/1974 15:03:05 So really, January? 15:03:07 * sgallagh pours the whiskey 15:03:16 so 15:03:29 Right 15:03:31 sct and I put together a proposal for a new mvp 15:03:41 and met with the dnf today again 15:03:44 contyk: sct? 15:04:03 Stephen Tweedie 15:04:16 Long-time Red Hat software architect 15:04:25 * contyk nods 15:04:55 the response was that the new proposal seems interesting but the team will need some time to go through it and even if they accept it as it is 15:05:06 they expect the actual code design, implementation and testing will take a month or two 15:05:27 whoah 15:05:28 So January again ;( 15:05:31 so we basically have two options 15:05:31 * nirik sighs 15:05:32 so what do we do about f29? 15:05:56 wait for them to fix it or drop the blocker flag and document it 15:06:09 we could just tell mattdm that f29 will be ready in time for devconf! 15:06:27 sgallagh: care to summarize the impact? 15:06:39 hmm 15:07:36 The impact will be mostly what we've discussed: there's a risk that users might get upgraded away from their modules (if they're using a module with an lower NVR than the non-modular repos) if the repodata went away. 15:08:00 This may happen in some cases with content added from updates-testing or from COPR/third-party repos. 15:08:17 So, essentially modularity is broken, but the system isn't so much 15:08:27 sgallagh: for copr, would "repodata [going] away" mean they turned off the copr in dnf? 15:08:37 I think we can mitigate the COPR/third-party stuff by documenting that any repos offering modules must be marked as skip_if_unavailable=Flase 15:08:39 bowlofeggs: yep 15:08:39 *false 15:08:52 bowlofeggs: Or COPR's lack of an SLA got then 15:08:53 *them 15:09:17 If the repo isn't reachable, DNF wouldn't be able to process its modulemd 15:09:37 basically: always keep the same set of modular repos enabled if you don't want bad things to happen. 15:09:42 we were previously concerned about copy/paste users getting instructions for fixing a bug they have with an --enablerepo 15:09:42 right 15:09:53 bowlofeggs: Yes, and that's still a concern 15:10:01 it seems like such a user would probably not read any docs we wrote about this problem 15:10:05 ditto with --repofromurl or whatever the right command is 15:10:23 or people disabling the modular repo entirely 15:10:37 if the content is available in both Everything and *modular 15:10:44 contyk: I think the set of people who would do that are the set of people who wouldn't have previously installed a module 15:10:51 So I'm not too concerned about that specific case 15:10:54 well 15:11:01 We only have two modules with a default stream in F29 15:11:01 consider the libgit2 case 15:11:04 stratis and dwm 15:11:38 contyk: libgit2 is no longer in a default stream 15:11:42 That was done in error 15:11:53 contyk, sgallagh: did you become convinced that it would really take that long to fix the issue? it sounded last week like the proposed fix was low complexity 15:12:17 :) 15:12:19 bowlofeggs: I am convinced it would take the current DNF team that much time to do it yes. 15:12:25 haha 15:12:42 ok, so we don't really have a lot of options other than delay f29 or accept this as a known bug 15:12:54 yes, I'm afraid so 15:12:56 * nirik nods 15:13:01 and delaying f29 would probably make mattdm cry a single tear 15:13:25 delaying until jan would be... Fedora 18 all over again. ;) 15:13:38 FOSDEM release party 15:13:49 Well, this isn't a small delay, I don't think a single tear would be the response from mattdm 15:14:10 I don't think the impact of this big enough to justify a 2+ month delay 15:14:31 I honestly don't think there is much of an option here, I agree with zbyszek that it isn't enough to justify such a delay 15:14:52 yeah, sadly. 15:14:52 yeah. 2+ month delay is "your computer will literally catch fire and burn your house down" 15:14:53 zbyszek: I'm leaning that way as well, but it pains me greatly 15:15:07 same here 15:15:24 this is a lousy position for us to be in, but there's not a whole lot we can do about it now 15:15:29 proposal: drop blocker status on bug, document in release notes, common bugs and anywhere else we can 15:15:44 +1 nirik 15:15:54 +1 niriki 15:15:58 +1 nirik 15:16:02 +1 nirik 15:16:34 ...+1 15:16:45 My major concern here is going to be how this comes across in the tech press 15:17:32 Hopefully it is such a small issue in practice that it doesn't 15:17:59 well, it's a anoying corner case, but it is a corner, so I don't know how much it will really hit people... especially since we don't yet have a bunch of default streams. 15:17:59 jforbes: Have you EVER known the press to ignore any opportunity to criticize a new feature? 15:18:30 point 15:18:37 sgallagh: Press *loves* new features, esp. if they come with screenshots ready 15:18:48 nirik: +1 15:19:16 nirik: I'm resigned to a +1 here 15:20:08 assuming nirik is +1 here 15:20:12 * contyk sighs 15:20:13 Please note that dnf has one more accepted blocker and another two proposed blockers, and resolving them will consume some resources from the dnf team too 15:20:24 contyk: we voted to always assume the proposer is +1 15:20:31 (unless explicitly noted) 15:20:34 true 15:21:04 yes, I'm +1 15:21:05 #agree drop blocker status on bug, document in release notes, common bugs and anywhere else we can (+7, 0, -0) 15:21:20 alright 15:21:30 so that's all we had 15:21:33 #topic Next week's chair 15:21:56 I have a conflict half an hour in next week 15:22:17 i will be absent next week 15:23:11 I can do it again if there are no other volunteers 15:23:17 I can 15:23:23 yay 15:23:32 #action jforbes will chair next meeting 15:23:37 thank you 15:23:43 #topic Open Floor 15:24:47 crickets 15:24:54 Would anyone be opposed to move the Release Readiness meeting after each the GO/no-go meeting that passes GO? 15:25:13 zbyszek: i would 15:25:27 bcotton: please explain 15:25:48 there are just over 4 days between declaring a release go and doing the release 15:25:53 which includes 2 weekend days 15:26:09 that's very short notice to get people into a meeting, cover readiness, and address any concerns that come up 15:27:03 My thinking was to schedule the Readiness meeting after each go/no-ge meeting, and automatically cancel it if no-go is voted. 15:27:19 Same people attend both meetings anyway... 15:27:19 ah okay, that's not how i read it 15:27:38 well a lot more people are in the release readiness meeting (theoretically) 15:27:50 OK, so maybe it's too much trouble. 15:27:53 i'd be less opposed to that, but that's a lot of time for people to block off and then not need 15:28:10 i do think the release readiness meeting need some improvement 15:28:46 i'll reply to the devel thread, too, because my concerns may be overblow 15:29:05 OK, let's move on and continue the discussion on the mailing list. 15:29:09 for the beta, didn't we only have a release readiness meeting after the no-go decision, and not another after the go? 15:29:15 i.e., isn't only one necessary? 15:29:19 yes, there's only 1 per milestone 15:29:21 or do we do it different for final? 15:30:17 I'm not sure how useful they are. Seldom are there any issues... might be better to coordinate async somehow... "update your status here" 15:30:21 we just have one for final as well. zbyszek is proposing we change that 15:30:42 nirik: yeah, i was thinking the same thing 15:30:47 (as long as someone was making sure everyone updated and has the things thye need) 15:31:35 i like the idea of an asynchronous check-in 15:31:41 though i bet some people won't check in 15:31:48 but then again, some people also don't come to the meeting 15:32:24 * bcotton nods 15:32:36 but the point is for people to have a way to tell us they aren't ready, so i guess not hearing from them means it's probably ok to assume they don't have an issue with releasing 15:32:50 because you'd think they'd say something if they had a reason to block release 15:33:16 kind of like bodhi +1 karma - it's not useful, but -1 karma is useful 15:34:49 yeah, but that can run into... we thought you were ready, but no one was doing the work there. 15:34:57 yeah... 15:35:23 well we could try a wiki table check in 15:35:44 and maybe some nudging would be necessary to get answers from people who don't reply 15:35:58 if they are nudged and dont' reply, i say that's def their fault 15:36:35 Well, that sounds like we want to keep the meeting — it's a well known part of the process and people can be all nudged using irc 15:37:03 certainly for F29 let's keep the status quo. for F30 i'm definitely open to new ideas 15:37:26 yeah, too late to change 29, but we could do something different/better for 30 15:38:29 i'm fine with either way 15:39:20 * nirik doesn't think it needs to be solved here/now. 15:40:13 agreed. we can move on 15:41:18 I don't have anything else for open floor... 15:42:04 alright 15:42:27 closing in one minute then 15:43:14 #endmeeting