15:00:00 #startmeeting Bodhi stakeholders (2017-09-12) 15:00:00 Meeting started Tue Sep 12 15:00:00 2017 UTC. 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 'bodhi_stakeholders_(2017-09-12)' 15:00:00 #meetingname bodhi_stakeholders 15:00:00 The meeting name has been set to 'bodhi_stakeholders' 15:00:00 #topic salutations 15:00:00 #chair bowlofeggs caleigh dgilmore masta mboddu nirik pbrobinson puiterwijk Kellin jcline 15:00:00 Current chairs: Kellin bowlofeggs caleigh dgilmore jcline masta mboddu nirik pbrobinson puiterwijk 15:00:19 * mboddu is kinda here 15:00:44 * jcline is here 15:00:59 * nirik is kinda here too. 15:02:04 .hello dustymabe 15:02:06 dustymabe: dustymabe 'Dusty Mabe' 15:03:14 thanks for coming everyone. let's do this 15:03:22 #topic announcements and information 15:03:22 #info A Bodhi 2.11.0 beta is deployed to staging, but may become 2.12.0, because: 15:03:22 #info threebean hopes to release and deploy a 2.11.0 that does module mashing, displacing the current planned 2.11.0 15:03:22 #info Release notes available at https://bodhi.stg.fedoraproject.org/docs/release_notes.html 15:03:39 so those release notes are for what may become 2.12.0... 15:04:22 any comments/questions on the announcements? 15:04:38 explain your info posts above please 15:05:04 Southern_Gentlem: what in particular is not clear? 15:05:16 so is he deploying 2.11.0 beta 15:05:55 Southern_Gentlem: what had been planned to be a 2.11.0 was deployed already, but threebean wants to "take" that version number and make it a release that adds nothing but module mashing 15:05:56 * threebean waves 15:06:06 Southern_Gentlem: if that happens, what was going to be 2.11 will instead become 2.12 15:06:17 well - i'm glad to take any version number that makes sense. bowlofeggs suggested that I take 2.11.0. 15:06:23 basically, i didn't want to introduce both changes in an FBR deployment 15:06:34 2.11.1? 15:06:38 yeah we don't *have* to use that version, but 2.11 wasn't taken yet 15:06:52 Southern_Gentlem: bodhi uses semantic versioning, so a .z release should not introduce a feature 15:07:03 ehh 2.12 works for me 15:07:05 :) 15:07:06 and 2.11.0 isn't actually taken yet (there's no tag for it) 15:07:14 ahh ok, then w/e 15:07:40 ok its clear as mud 15:07:46 continue 15:07:47 we also aren't completely sure this will happen, as we need an FBR approved to do the deployment 15:08:08 but if threebean's testing goes well and the FBR is approved, that's the plan 15:08:24 so actually, the only topic i had planned for today was that 15:08:25 so: 15:08:28 :p 15:08:30 #topic module mashing 15:09:07 normally i like to avoid deploying features during beta freezes, but this particular feature is an important fedora server objective 15:09:23 so that is why we are doing things that might be considered "strange" :) 15:11:00 any other thoughts or questions about bodhi and modularity? 15:11:06 bowlofeggs: yeah 15:11:12 so the PR for this in bodhi 15:11:36 seems to 'hardcode' a lot of the config that would have traditionally been in the pungi config file 15:11:40 * threebean nods 15:11:45 like 15:11:47 https://github.com/fedora-infra/bodhi/pull/1697/files#diff-1a7f8244263b14fccf760eb233aedd61R1168 15:11:58 I don't really like including information like that in "code" 15:12:12 or is that just in the tests? 15:12:14 yeah - mcurlej is pulling that out. we thought we had another week or so to do it, but the fesco request has put some urgency on it. 15:12:28 threebean: pulling that out means? 15:12:29 dustymabe: that appears to be a test file 15:12:36 replacing it with configurable values. 15:12:47 threebean: how would it be configured? 15:13:09 bowlofeggs: right that is a test file, but how would those values get defined otherwise? 15:13:09 dustymabe: well - the line you linked to? that's just in the tests. 15:13:27 "bodhi-manage-releases create" 15:13:46 they're database values. 15:13:57 oh wow, so the pungi config lives in the database? 15:14:02 no. 15:14:09 the "Release" object lives in the database. 15:14:14 * threebean checks the link again 15:14:16 dustymabe: the bit you linked to was a Release object 15:15:01 ok, i guess what I'm trying to figure out is how this work would merge with the 'call pungi from bodhi' work that I have worked on 15:15:01 which is a database object - this isn't new for modularity but exists today as well (it's how Fedora 26 is defined today, for example) 15:15:14 and if they overlap at all 15:15:26 dustymabe: yeah i also share that concern, because they currently are very different 15:15:53 i was just trying to verify that we weren't storing the pungi config by hard coding 15:16:02 if that's not the case then 'good' 15:16:11 that is 100% not the plan. :) 15:16:25 threebean: where would the pungi configs be stored? 15:16:39 likely in /etc/bodhi/ 15:16:52 managed by ansible, like the mash configs 15:17:05 second option - we could store them in a pagure repo, like the comps files. 15:17:08 threebean: ok let's collaborate on that 15:17:20 +1 15:17:38 threebean: https://pagure.io/releng/issue/6971 15:17:41 please comment 15:17:56 dustymabe: we're flat out this week just trying to get the crazy release branch rebased and to verify upgrade/downgrade works. 15:18:07 threebean: it's important to me not to spread bodhi's configs into more places - i.e., we should keep them in the ansible repo like we do with the mash configs 15:18:22 +1 15:18:33 no prob with that from me. 15:19:23 threebean: so can we collaborate on what the name of the files would be 15:19:32 to make sure we don't step on each others toes 15:20:35 wasn't there a releng ticket about the config here? or was it something else. 15:20:37 * nirik looks 15:20:50 nirik: https://pagure.io/releng/issue/6971 15:21:09 yeah. that one 15:21:37 dustymabe: yeah, for sure. I'll make sure to put comments in that ticket. 15:22:53 threebean: care to give an update on the status of the PR? 15:24:25 no, I haven't gotten into it yet. I've been spending all my time setting up staging to test traditional bodhi. 15:25:05 I was planning to try and rebase "whatever" is in the PR right now ontop of 2.10.0, cut a 2.11.0.beta3 (or something like that) and use that to verify that upgrade/downgrade of bodhi doesn't break the traditional bodhi mash. 15:25:06 threebean: including mash? 15:25:12 dustymabe: yes. 15:25:45 I successfully mashed a repo of "Fedora 2000 updates-testing" in staging. :) 15:25:47 bowlofeggs: ^^ 15:25:55 i didn't think that was possible 15:26:02 dustymabe: it took a lot of work. 15:26:19 threebean: sigh :( 15:26:26 threebean: ah ok. i've been working on https://github.com/fedora-infra/bodhi/issues/1793 and i'm getting close to done - there's a few bits that i need to use your fancy pants infer_content_class() that are slightly tricky, but i should finish it today 15:26:40 bowlofeggs: rad :) 15:26:41 i wish that 'lot of work' could have been targeted towards the bodhi-calling-pungi work 15:26:43 threebean: congrats on fedora 2000 :) 15:27:25 threebean: were you able to verify if the resulting repo can be used to update a module? 15:27:35 no, because the resulting repo was for traditional bodhi. 15:27:41 ahhhh 15:27:47 oh, i thought that had a module in it? 15:27:58 no, i was only trying to replicate how bodhi works today. 15:28:00 threebean: i guess you wanted to verify that traditional works before and after? 15:28:01 so that I can test it. 15:28:02 yeah ok 15:28:04 i thinki understand 15:28:05 cool 15:28:07 makes sense 15:28:07 so that I can then upgrade it, and verify that it *still* works. 15:28:12 indeed 15:28:15 and then downgrade it, and verify that it *still* works. 15:28:22 and then upgrade it, and verify that *modules* work. 15:28:29 cool, i think that will help persuade the FBR gods 15:29:49 any other thoughts on this topic, or shall we move to open floor? 15:30:52 #topic open floor 15:31:51 15:31:53 <3 15:32:06 going once! 15:32:10 going twice! 15:32:19 sold, to threebean for an FBR! 15:32:22 #endmeeting