15:00:00 #startmeeting FESCO (2018-09-10) 15:00:00 Meeting started Mon Sep 10 15:00:00 2018 UTC. 15:00:00 This meeting is logged and archived in a public location. 15:00:00 The chair is bowlofeggs. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:00:00 Useful Commands: #action #agreed #halp #info #idea #link #topic. 15:00:00 The meeting name has been set to 'fesco_(2018-09-10)' 15:00:00 #meetingname fesco 15:00:00 The meeting name has been set to 'fesco' 15:00:00 #chair nirik, maxamillion, jsmith, jwb, zbyszek, tyll, sgallagh, contyk, bowlofeggs 15:00:00 #topic init process 15:00:00 Current chairs: bowlofeggs contyk jsmith jwb maxamillion nirik sgallagh tyll zbyszek 15:00:17 o/ 15:00:28 .hello2 15:00:29 zbyszek: zbyszek 'Zbigniew Jędrzejewski-Szmek' 15:00:30 .hello psabata 15:00:32 contyk: psabata 'Petr Šabata' 15:00:36 morning 15:00:39 .hello2 15:00:40 sgallagh: sgallagh 'Stephen Gallagher' 15:01:04 .hello2 15:01:05 bcotton: bcotton 'Ben Cotton' 15:01:05 .hello2 15:01:07 maxamillion: maxamillion 'Adam Miller' 15:01:28 .hello till 15:01:29 tyll: till 'Till Maas' 15:01:29 .hello2 15:01:32 jforbes: jforbes 'Justin M. Forbes' 15:01:42 cool, we have quorum 15:01:48 let's get this party started 15:01:55 ain't no party like a fesco party 15:01:55 hay 15:01:57 ho 15:02:01 lol 15:02:05 #topic #1988 Josh Boyer has resigned 15:02:05 .fesco 1988 15:02:06 bowlofeggs: Issue #1988: Josh Boyer has resigned - fesco - Pagure - https://pagure.io/fesco/issue/1988 15:02:21 AFAICS contyk needs to vote 15:02:27 Because FESCo parties just don't... stop. *cries* 15:02:35 sgallagh++ 15:02:36 maxamillion: Karma for sgallagh changed to 13 (for the current release cycle): https://badges.fedoraproject.org/tags/cookie/any 15:02:38 I haven't yet? 15:02:39 too true 15:02:44 * contyk checks 15:02:45 i count +7 on the ticket 15:03:04 i think we are missing maxamillion's vote actually 15:03:06 contyk: sorry, old page 15:03:20 ah, yes, he, too 15:03:23 or only he 15:03:51 maxamillion: can you vote on my proposal (first comment)? 15:04:29 bowlofeggs: voted in ticket for posterity 15:04:50 (vote of +1 jforbes for meeting logs) 15:04:50 excellent 15:05:48 #agreed FESCo chooses Justin Forbes (@jforbes) to fill the seat until the next election. (+8, 0, -0) 15:05:58 #chair jforbes 15:05:58 Current chairs: bowlofeggs contyk jforbes jsmith jwb maxamillion nirik sgallagh tyll zbyszek 15:06:04 congratulations :) 15:06:09 Thanks 15:06:15 who will update the permissions? 15:06:15 welcome back jforbes 15:06:22 nirik: ? 15:06:27 I can sure. 15:06:28 i don't think i have access 15:06:37 i can try to edit the fesco wiki page to add him though 15:06:38 jforbes: are you OK with the current meeting time? 15:06:41 jforbes: congratulations and/or we're sorry ;) 15:06:42 assuming i have perms for that 15:06:46 I am 15:06:57 #action nirik will give jforbes access to fesco'y things 15:07:01 so question: jwb is/was also the engineering rep to the council ? 15:07:06 #action bowlofeggs will update the fesco wiki page 15:07:38 nirik: "engineering" == "red hat platform engineering" 15:07:40 ?* 15:07:46 nirik: oh i didn't realize that. so we need a volunteer to do that? 15:07:49 nirik, true. i filled that role while not eing on fesco before 15:08:12 maxamillion: No, a liason to the Fedora Council 15:08:24 ohhh 15:08:40 jwb: does that mean you will continue to do that going forward? 15:08:50 according to https://docs.fedoraproject.org/en-US/council/ FESCO coordinates the seat 15:08:59 jwb: are you able/willing to keep filling that role? 15:09:49 it doesn't seem to say it has to be a fesco member though, so if jwb wants to keep doing it we are probably ok 15:10:14 afaict, the engineering representative isn't required to be a FESCo member, but it seems to me that they should be (not that i don't love having jwb around) 15:10:39 nirik, bowlofeggs: if FESCo thinks there is a better suited candidate, it's up to them to decide. that role is a bit less time consuming and i would like to try for a bit to continue there, but i won't stand in the way if there is a better person 15:11:35 i don't see any reason to change things for now since jwb is willing to continue 15:11:38 cool. I'm fine with you continuing that... and if you don't have time or whatever we can look for a new person for that... 15:11:41 shall we move on to next topic? 15:11:42 me too 15:11:42 * nirik nods. 15:11:48 thanks jwb! 15:11:56 \o/ 15:12:30 jwb++ 15:12:30 maxamillion: Karma for jwboyer changed to 2 (for the current release cycle): https://badges.fedoraproject.org/tags/cookie/any 15:12:54 thank you all. 15:12:57 * jwb goes back to work meeting 15:13:34 ok, next topic 15:13:41 #topic #1967 Fedora 29 incomplete changes 15:13:41 .fesco 1967 15:13:43 bowlofeggs: Issue #1967: Fedora 29 incomplete changes - fesco - Pagure - https://pagure.io/fesco/issue/1967 15:14:29 Let's go one-by-one again 15:14:34 indeed 15:14:44 let's skip dbus since it got its own ticket as you noted 15:14:58 let's look at festival? 15:15:04 For festival, I'the two package managers to update festival to the latest version 15:15:10 https://fedoraproject.org/wiki/Changes/Update_festival_to_2.5 15:15:17 The package seems to be working, but there's still some packaging cleanups to be done. 15:15:40 I think we should just wait until this is done and push in the new version after beta if it is ready before GA. 15:16:01 that sounds ok to me, esp since things are broken now anyway 15:16:04 +1 15:16:06 +1 15:16:08 that sounds better than the current state of festival 15:16:17 so +1 15:16:33 +1 here 15:17:00 +1 15:17:30 maxamillion, jsmith: ? 15:18:15 +1 15:18:51 oh right, jsmith isn't here today 15:18:51 haha 15:19:18 #agreed we will wait for festival to be done and push in the new version after beta if it is ready before GA (+8, 0, -0) 15:19:46 next topic: https://fedoraproject.org/wiki/Changes/CloudProviderImageUpdates 15:20:10 From the ticket: 15:20:13 > This change is an internal process change that has no code changes inside of Fedora 29. This change should not block the release of Fedora 29. 15:20:36 Didn't we decide last week that this wasn't tied to the release schedule? 15:21:13 definitely not last week 15:21:22 last decision was AGREED: cloud image updates: defer and check next week, it's unclear 15:21:22 to me what would need to be done before beta as this change deals 15:21:22 with post GA content (+7, 0, -0) (contyk, 16:51:37) 15:21:24 yeah, just ack it and make sure they know they have to be ready after GA 15:21:33 nirik: +1 15:21:36 It doesn't look to be other than monthly after 15:21:54 nirik: +1 15:22:09 nirik: +1 15:22:37 +1 15:23:27 +1 15:23:35 +1 15:23:47 maxamillion: ? 15:25:12 ok, i'll count maxamillion as an abstension? 15:25:42 should we vote on that proposal? ;) 15:25:44 sorry, my kid just broke a coffee cup in the other room ... he's home sick today 15:25:51 +1 15:25:57 #agreed FESCo acks the cloud image updates change and notes that they need to be ready after GA (+8, 0, -0) 15:26:11 maxamillion: Giving him coffee probably isn't helping that 15:26:25 last one: https://fedoraproject.org/wiki/Changes/Silverblue 15:26:49 still no activity on this 15:27:16 our last decision was: 15:27:17 sgallagh: lol 15:27:19 let folks work on 15:27:19 it today, if not done in time for freeze, they can ask for an 15:27:19 exception or move to f30. 15:27:19 well, a bunch has been done, but I don't know if it's complete. 15:27:27 sgallagh: it was an empty cup I mistakenly left in his reach 15:28:22 it has been difficult to get communication about this change 15:28:33 any proposals? 15:28:33 kalev: Can you answer any questions about Silverblue? 15:28:33 so move to f30? 15:28:49 If we wanted to, could we realistically postpone this, considering that the new name is already visible in various places? 15:29:26 Yeah, I'm concerned that we may be past the point of no (realistic) return 15:29:30 we keep postponing this despite getting no updates... 15:29:48 the I know the ostree ref is changed. 15:30:06 not sure about the other items. Looks like the anaconda changes are reviewed, but not merged yet 15:31:18 https://silverblue.fedoraproject.org/ looks quite good 15:31:25 so I guess the 3 options are: 1) try and back it out and go for f30, 2) let it land after beta or 3) block beta on it being done 15:31:40 i'd vote for #1 or #3 15:31:45 #2 seems risky to me 15:31:56 is that a release blocking change? 15:32:05 maybe if it's not a release blocker #2 is ok too 15:32:17 yeah, 1 or 3 is good for me as well but I'd be interested in adamw's opinion about it if he's available to chime in 15:32:20 well, with 2 we loose out on any beta testing... 15:32:22 adamw: ping - you around? 15:32:41 Right, with anaconda changes, beta would be pretty important 15:32:53 oh right 15:32:53 I'd certainly vote against #2 with what I know now 15:32:57 yeah #2 seems no good 15:33:19 also, since there has been little to no communication, #3 doesn't seem great eithe frankly 15:33:36 otaylor: So we're discussing the current state of Silverblue and whether it's better to block Beta for it to finish or to try to back it out 15:33:38 because blocking on a change that you can't get updates about seems unwise, right? 15:34:15 "finish" here means what? 15:34:19 otaylor: We're suffering an acute lack of visibility into the project, so we don't know where we are 15:34:31 but #1 would also require the change owners to do work and communicate (and would also block the beta?) 15:34:40 anaconda changes to add variant, pungi-fedora channges to change image names and possibly other stuff... 15:35:02 We know some parts of this have already landed 15:35:21 But we're not sure what remains to be done and whether it's more work to proceed with it or back it out at this point. 15:35:38 And frankly the Workstation WG has not been highly communicative 15:35:39 I don't think anybody is scrambling to finish a finite set of changes for Beta - so I don't think that blocking on that would make sense 15:36:51 An option would be to assert that Silverblue (formerly Atomic Workstation) is non-blocking for F29 by FESCo ruling 15:36:54 There's a distinct lack of engineering ownership for Silverblue I'm afraid - it's falling between the cracks of the workstation wg and volunteers interested in it in particular 15:37:12 otaylor: do you think we should postpone the change to fedora 30? 15:37:23 bowlofeggs: I don't think postponing really makes sense 15:37:32 It's replacing a non-blocking medium anyway 15:37:40 sgallagh: thats basically 2 above right? just letting it land after beta? 15:37:43 (Atomic Workstation has always been a preview) 15:37:44 sgallagh: right, but it also needs anaconda changes, right? 15:37:51 sgallagh: and we wouldn't want to allow that post-beta? 15:37:59 bowlofeggs: Hmm 15:38:23 perhaps thats not so bad... 15:38:24 I guess that would depend on how isolated those anaconda changes are 15:38:35 jforbes: +1 15:38:54 the anaconda changes seem pretty small: https://patch-diff.githubusercontent.com/raw/rhinstaller/anaconda/pull/1510.patch 15:38:58 if we were sure it didn't risk blocking releases, i'd be happy to allow it post beta, but that does seem to be a risk area 15:39:14 https://github.com/rhinstaller/anaconda/pull/1510/files 15:39:29 is that the relevant PR for anaconda? Is there something more? 15:39:37 yeah that does look small 15:39:41 there might be a lorax change... 15:40:11 bowlofeggs: I think the month between Beta and GA is time enough to roll it back if it breaks anything 15:40:34 So, not only small, but isolated addition of an InstallClass, it shouldn't have any impact on other InstallClasses so would be safe 15:41:08 I can't find any lorax change, but I think a small one is needed. Also websites will need to change/adjust... 15:41:08 I don't see much risk in that particular anaconda change landing post beta 15:41:11 ok, so are we thinking that we can just keep waiting to see what happens? 15:41:44 honestly, i'd be more into waiting and seeing if we were getting communication 15:41:51 bowlofeggs: My view is "let them keep at it" and treat it as non-blocking. If they make a change that causes a blocking failure, that change must be reverted 15:42:11 sgallagh: that seems very risky 15:42:19 sgallagh: +1 15:42:25 anaconda changes have a high regression potential 15:42:35 zbyszek: not that one 15:42:38 bringing it up at the next workstation WG meeting might also be a good idea... find someone to try and make sure all the parts land. 15:42:39 I'd suggest waiting - mclasen should be back from LAS today I think - I'll discuss the situation with him. 15:42:41 keep in mind that people not involved with making the change will have to notice the problem (work) and report it (work) and/or back it out (work) 15:42:43 I think he means future changes 15:43:01 oh, right 15:43:15 otaylor: thanks. 15:43:24 and difficulty to communicate with the change owners will complicate things too 15:43:40 my biggest concern really is the lack of communication 15:43:46 mine too 15:43:55 * tyll agrees 15:44:00 I was proposing to move this to f30 two weeks ago and would still choose that 15:44:10 it makes it seem like this change isn't important to the owners 15:44:17 what form of communication would be helpful here? eeping the change page updated? anything else? 15:44:23 which makes it seem like it isn't important to grant an exception to? 15:44:44 otaylor: yeah, and answering questions in the bz https://bugzilla.redhat.com/show_bug.cgi?id=1598405 15:44:46 otaylor: Well, the owners were pinged on the Change BZ several times 15:44:48 otaylor: regular status reports with a clear list of items that need to be addressed 15:45:10 otaylor: responsing to need-info's in bugzilla also 15:45:12 i'll point out that the owners haven't even asked us for an exception 15:45:34 * otaylor wonders how much bugzilla traffic mclasen gets every day 15:45:52 ugh, I can't even imagine 15:46:15 (Not saying he's at all unique in that ... just saying that it's not the most reliable form of communication) 15:46:47 otaylor: he was also present in last meeting 15:47:45 This kind of change also does go accross many teams too, which makes it harder... anaconda, lorax, releng, websites, etc... some of them more responsive than others. 15:47:54 this is a tough one 15:48:07 nirik: also true 15:48:51 i don't see a clear "good" choice for us here 15:48:52 proposal: allow this change to land after beta, but also try and get updated status and vote in ticket if new information warrents it 15:49:03 nirik: this makes it more important to collect all the items somewhere ... nothing blocks or is mentioned in the tracking bug and the wiki does not contain links for all issues in the scope 15:49:41 We could also require that nothing touching Anaconda or compose-tools can be merged without FESCo's review? 15:49:48 Yeah, "allow this change to land" is undefined 15:49:56 I also see the problem with reverting that there is probably also nobody who would oversee that it would be properly reverted, therefore trying to not block on it seems to be the only option 15:50:02 if we told them "wait until f30", would that risk anything for f29? 15:50:05 Or not necessarily all of FESCo, but a representative 15:50:21 bowlofeggs: well, some things (the ostree ref at least) are already changed. 15:50:23 bowlofeggs: Press coverage 15:50:41 We've definitely had some pick-up of the name in the press, this would mean negative coverage. 15:50:48 But we've dealt with that before 15:51:16 would anything "break" due to that ostree ref being silverblue? 15:51:31 what if we told them to do a phase1/phase2 type thing? 15:51:40 like f29 just gets that ostree ref and whatever else is done now 15:51:44 the rest wait for f30? 15:51:47 I am not sure. Might prevent updates from atomic workstation media/ 15:51:48 ? 15:51:49 could that work? 15:51:55 ah 15:52:25 Hmm, the anaconda PR was reviewed and approved on June 20th. That's almost 3 months with no action. 15:53:50 otaylor: do you think you could talk with mclasen withing let's say two days and provide an update in the fesco ticket? 15:54:05 * nirik notes the beta go/no-go is thursday 15:54:29 zbyszek: Yes, I'll talk to him today or tomorrow. 15:54:30 yeah, rgr 15:54:35 otaylor++ 15:54:35 maxamillion: Karma for otaylor changed to 6 (for the current release cycle): https://badges.fedoraproject.org/tags/cookie/any 15:55:47 we've been on this a long time 15:55:50 so how about we file a 'f29 silverblue name change' fesco ticket and collect status/any needed votes there? 15:55:56 proposal: we wait for a status update from otaylor or mclasen, and vote in ticket on one of the #1-#2-#3 proposals as updated. 15:56:07 how about a combo of those two? ☺ 15:56:14 (in separate ticket as nirik says) 15:56:16 +1 15:56:24 +1 15:56:29 +1 15:56:51 +1 15:56:54 +1 15:57:01 +1 15:57:27 contyk: ? 15:58:33 I abstain 15:59:20 ack 15:59:45 #agreed we will file a separate fesco ticket about the silverblue change, ask for status there, and vote there (+8, 1, -0) 15:59:54 #action zbyszek to create the ticket 15:59:54 #action bowlofeggs will file the fesco ticket about silverblue 15:59:57 hahah 16:00:14 uh, zbyszek you can do it ☺ 16:00:20 OK, I'll do it. 16:00:30 #undo 16:00:30 Removing item from minutes: ACTION by bowlofeggs at 15:59:54 : bowlofeggs will file the fesco ticket about silverblue 16:00:32 ok that's all of them 16:00:40 next topic 16:00:45 pfff 16:00:52 sorry, just got here. 16:00:57 #topic #1974 Problematic blocker for F29: dnf 'offline' module tracking 16:00:57 .fesco 1974 16:01:00 bowlofeggs: Issue #1974: Problematic blocker for F29: dnf 'offline' module tracking - fesco - Pagure - https://pagure.io/fesco/issue/1974 16:01:15 adamw: we decided to move it to a ticket - we'll ping you there 16:01:20 rgr 16:01:23 I have no new information on this since the last meeting. 16:01:41 adamw: but this is also your ticket ☺ 16:02:42 i'm also running a blocker meeting... 16:02:58 if the answer to this is 'we're fine doing nothing for beta', then that's okay. 16:03:54 sgallagh: sorry, I'm not up to date with silverblue renaming, can't really provide any info right now 16:04:06 adamw: That was my recommendation last meeting. The hang-up seems to be around GA blocking or not. 16:04:30 I think we need to block there, but there's no clear indication from the DNF team whether they can deliver on that timeframe :( 16:04:35 sgallagh: do we have any sense when the fix might land? 16:04:41 ah, bummer 16:05:06 contyk: Have you heard anything new here that I may have missed? 16:05:39 no, I don't think there's any concrete plan at this point 16:05:50 I don't see as we have much alternative here... I guess we could disable the modular repos until it's fixed, but... 16:05:55 it is clear that the DISTTAG check is impossible to do in this timeframe 16:06:12 but I still hope that storing modulemd for installed RPMs + enabled modules should be doable 16:06:25 wouldn't it be bad to disable the modular repos in the beta if it intend to enable them in GA? 16:06:30 even if they just dump them in a directory somewhere 16:06:34 s/if it/if we/ 16:06:43 bowlofeggs: that does seem ungood 16:07:03 I don't think that was proposed 16:07:19 I don't think we should be disabling the repos 16:07:25 I agree 16:07:37 right, I was just saying there wasn't much else we could do ffor beta. 16:07:43 Before GA, we're somewhat protected by the fact that U-T is available 16:07:44 I guess block beta 16:08:03 This mitigates the most serious risk of this bug 16:08:13 blocking beta also seems unwise 16:08:19 yeah i'm a bit inclined to block beta too, because it sounds like there isn't yet a plan for GA 16:08:21 * nirik agrees 16:08:28 But once we get to GA, it needs to be fixed or we're going to have problems with anyone who installs a module update from a temporarily-enabled U-T 16:08:42 nirik: Agrees with whom? 16:08:49 it might also affect system upgrades in some unpredictable way 16:08:51 I was agreeing with jforbes. 16:09:18 contyk: Hmm, I hadn't considered that, but you might be right 16:09:33 I think we move this to a final blocker and also add a common bugs for beta and hope for the best. 16:09:41 it depends on what exactly happens and in what order 16:09:49 nirik: +1 16:09:51 nirik: +1 16:09:52 i'm concerned that there isn't a plan to solve this problem before GA and that the known solutions aren't viable for the time frame (am i right in these claims?) 16:09:52 nirik: That's basically what I proposed last time, so +1 16:10:05 bowlofeggs: No 16:10:14 sgallagh and I will try to form an action plan for the dnf team, too 16:10:16 oh, there are viable solutions? 16:10:21 right? 16:10:23 bowlofeggs: the 'keep info about repos you installed from' plan should be doable 16:10:26 The known, viable solution is unclear if it's viable in the current timeframe 16:10:30 It might mean slipping a bit. 16:11:12 oh ok, i think i'm ok with it 16:11:13 well, there are two things dnf needs to do to properly handle these things 16:11:20 i think i had misunderstood some comments in the ticket 16:11:36 one is doable (storing modulemd files for enabled modules and installed modular RPMs), the other is not (DISTTAG verification) 16:11:38 proposal: FESCo considers this a GA blocker but not a beta blocker 16:12:05 bowlofeggs: this is a subset of what nirik proposed 16:12:12 +1 16:12:13 oh right 16:12:29 nirik's proposal then: we move this to a final blocker and also add a common bugs for beta and hope for the best. 16:12:34 esp the bit about hope ☺ 16:12:36 contyk: the DISTTAG verification is more of a fallback if the stored metadata doesn't prove sufficient though 16:12:37 +1 again 16:12:37 i'm +1 16:12:41 +0 16:12:42 It's for really esoteric cases 16:12:50 +1 16:12:55 +1 16:13:00 +1 16:13:03 s/esoteric/pathological/ 16:13:15 +1 16:13:15 +1 16:13:51 #agreed we move this to a final blocker and also add a common bugs for beta and hope for the best (+7, 1, -0) 16:14:06 #topic #1976 Review of release-blocking deliverables for Fedora 29 16:14:07 .fesco 1976 16:14:07 bowlofeggs: Issue #1976: Review of release-blocking deliverables for Fedora 29 - fesco - Pagure - https://pagure.io/fesco/issue/1976 16:14:37 i think this one just needs rubber stamps, but didn't get the +3 at the time i put it on the agenda 16:14:37 * nirik had no problems with this list. +1 16:14:39 * zbyszek knows nothing about this, so he's happy to just follow the majority 16:14:48 +1 16:15:00 +1 16:15:10 +1 16:15:37 +1 16:15:39 I was kinda surprised so few things are release blocking 16:15:40 zbyszek: it's just the list of artifacts that we declare should block the release 16:15:56 yes, but if one is missing, I'm not the one to spot it ;) 16:15:57 especially regarding arches 16:16:44 is there a reason why we don't block on all of them? 16:16:48 contyk: We like shipping once in a while 16:16:49 we are at +6 i think (including jsmith) 16:17:10 heh 16:17:16 contyk: not everything has dedicated full time engineers working to get it release ready 16:17:32 maxamillion: ? 16:17:33 well, +1 anyway 16:17:38 Right, anything that doesn't block release is still welcome to ship if it manages to stay in shape 16:17:52 +1 16:17:57 And any bug that would be a blocker on a blocking media pretty much gets an automatic FE for non-blocking media 16:18:07 zbyszek: i count +8. do you want ot be a +0, or a +1? ☺ 16:18:17 I can be +1, nice and friendly ;) 16:18:20 haha 16:18:28 #agreed APPROVED (+9, 0, -0) 16:18:39 #topic Next week's chair 16:19:06 I haven't done it in a while. I suppose I should volunteer. 16:19:16 #action sgallagh will chair next week's meeting 16:19:21 #topic open floor 16:19:36 I have something 16:19:43 I would like to discuss https://pagure.io/fesco/issue/1970 16:19:58 zbyszek: you were first 16:20:13 I started working on converting FESCo wiki pages to antora to make 16:20:13 them part of docs.fedoraproject.org. 16:20:13 (History would be preserved in git, but text/formatting would be 16:20:13