16:04:26 <mboddu> #startmeeting RELENG (2019-07-04)
16:04:26 <zodbot> Meeting started Wed Jul  3 16:04:26 2019 UTC.
16:04:26 <zodbot> This meeting is logged and archived in a public location.
16:04:26 <zodbot> The chair is mboddu. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:04:26 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:04:26 <zodbot> The meeting name has been set to 'releng_(2019-07-04)'
16:04:26 <mboddu> #meetingname releng
16:04:26 <zodbot> The meeting name has been set to 'releng'
16:04:26 <mboddu> #chair nirik sharkcz pbrobinson puiterwijk mboddu dustymabe ksinny jednorozec
16:04:26 <zodbot> Current chairs: dustymabe jednorozec ksinny mboddu nirik pbrobinson puiterwijk sharkcz
16:04:26 <mboddu> #topic init process
16:04:39 <nirik> morning
16:04:44 <mboddu> nirik: Hello again
16:04:46 <mboddu> :)
16:05:20 <nirik> :)
16:05:24 * mboddu haven't looked at the tickets, lets see
16:06:40 <mboddu> Lets start with epel8 update
16:07:18 <mboddu> #info fedpkg and fedscm-admin changes are tested in stage and are working. People can request epel8 branches just like they do for fedora release branches.
16:07:26 <mboddu> #undo
16:07:26 <zodbot> Removing item from minutes: INFO by mboddu at 16:07:18 : fedpkg and fedscm-admin changes are tested in stage and are working. People can request epel8 branches just like they do for fedora release branches.
16:07:32 <mboddu> #topic EPEL8
16:07:34 <mboddu> #info fedpkg and fedscm-admin changes are tested in stage and are working. People can request epel8 branches just like they do for fedora release branches.
16:08:05 <mboddu> #action mboddu need to create pungi configs and scripts to run epel8 nightly composes
16:08:32 <mboddu> nirik: ^ Where do we keep this config? pungi-fedora repo and epel8 branch?
16:08:40 <nirik> well, we aren't ready for branches in prod yet right?
16:09:00 <nirik> yep. I would say so... or master branch in a epel8 config...
16:09:39 <mboddu> nirik: On dist-git prod, yes, we are not ready, I tested them on stg only
16:10:07 <mboddu> And I prefer the epel8 branch to just keep the things separate as we do with branched composes from rawhide composes
16:11:24 <nirik> ok, that works
16:12:15 <mboddu> nirik: Couple of questions on epel8
16:12:30 <mboddu> Did we ever provide upgrade path from epeln-1 to epeln?
16:12:58 <nirik> well, not sure what you mean there...
16:13:20 <nirik> so say we have epel8 and epel8-playground or whatever we call it (rawhide is bad we should pick another name soon)
16:13:28 <nirik> and 8.1 comes out.
16:14:05 <nirik> we then take our existing packages, tag them all epel8.0 and move them to a epel8.0 repo, never to be updated again.
16:14:27 <nirik> then our first compose with 8.1 populates everything in epel8 again...
16:14:33 <nirik> and updates that, etc.
16:15:06 <mboddu> nirik: Yes, I got that, what I asked is from epel7 to epel8?
16:15:25 <nirik> ah... no.
16:15:44 <nirik> we have never cared about upgrade path between major versions.
16:15:59 <mboddu> Okay, good to know :)
16:20:54 <mboddu> nirik: In your above plan, we dont need epel8-playground then, right? Since we clone epe8.0 from epel8 when 8.1 comes out and 8.1 points to epel8, right?
16:21:48 <nirik> well, not for that, but as a place to experement/rapidly push changes, etc it's useful
16:22:31 <nirik> so you push your changes to there first, test, iterate, then if you think/want it to just go to stable mode, you build for epel8 branch that exact thing and it goes out via bodhi, etc.
16:22:49 <nirik> but it's all to be figured out
16:23:41 <mboddu> So, what does epel8-playground buildroot comes from? When
16:23:48 <mboddu> 1. 8.0 is the only release
16:23:58 <mboddu> 2. 8.1 is released
16:24:14 <mboddu> epel8-playground and epel8 buildroots, both?
16:24:24 <nirik> I would think it would have it's own buildroot that is like rawhide... so after you build it updates.
16:25:05 <mboddu> nirik: Then why cant the maintainers use -override tag to achieve the same thing?
16:25:18 <mboddu> If it works, thats great, if not, remove the override and build the stable one
16:27:59 <nirik> well, the playground rpms would be published/shipped out to users to use... you don't want things building against them until you are ready...
16:28:54 <nirik> so say... 8.0 has Xfce 4.12 in it... (the current stable release)
16:29:18 <mboddu> nirik: Okay, so it will separate repos coming out for epel8 and epel8-playground, even though they might be using the same buildroot
16:29:19 <mboddu> ?
16:29:20 <nirik> 4.14 rc's are coming out. You would want to build them in playground, and get feedback testing/
16:29:49 <nirik> but thats a stack of like 20 packages you would need overrides for, and if you left one and accidentally had to push a bugfix of 4.12 out it could get built with the wrong thing
16:30:13 <nirik> yeah, well, I am not sure they can share a buildroot, but perhaps it could work.
16:30:23 <nirik> but yes, otherwise seperate...
16:30:56 <nirik> except due to the fedpkg config it will normally be the same git hash/tree unless someone specificallywants to make a playground build.
16:31:38 <mboddu> nirik: Yes, got it, thanks for explaining it to me, I was a bit confused whats the need for epel8-playground
16:32:37 <mboddu> same buildroot = coming from rhel8 is the same, but epel8 might have bodhi overrides and epel8-playground will have playground builds
16:32:41 <nirik> same as rawhide, a place to do integration work/play with new versions/ship things that are not stable at all/ship things you don't want to support very long
16:33:17 <nirik> yeah, but we don't want to build stable stuff from the playground builds... so I think it would be better for them to be seperate...
16:33:24 <mboddu> Thanks nirik for the info
16:33:26 <nirik> I mean they inherit the same rhel8 base...
16:33:36 <nirik> but then epel8 just has stable updates + overrides
16:33:48 <nirik> and epel8-playground has all builds
16:35:21 <mboddu> Right, thats what I meant
16:36:07 <mboddu> Okay, moving on
16:36:16 <mboddu> #topic #7400 Rethink how we handle networking config with createImage (oz / ImageFactory)
16:36:21 <mboddu> #link https://pagure.io/releng/issue/7400
16:36:37 <mboddu> nirik: Any idea if it has been fixed?
16:36:48 * nirik looks
16:37:22 <nirik> no, I don't think thats done.
16:37:28 <nirik> we need the actual koji patch. ;)
16:38:07 <nirik> "We could send a PR for Koji to use this to disable 'predictable' interface naming during the image creation; either to just always include a kernelparam value of biosdevname=0 net.ifnames=0 for createImage tasks, or to make this configurable via the command line somehow and then have pungi / pungi-fedora pass it in for the images we want to use it for (handwave handwave)."
16:39:15 <nirik> so, I guess we should file a koji bug asking... and/or find someone to write the patch
16:40:37 <mboddu> nirik: Okay, I will file a bug against koji, thanks
16:40:47 <nirik> cool.
16:42:46 <mboddu> #topic Alternate Architecture Updates
16:43:15 <mboddu> nirik: I heard there was some moment in s390x issue while you guys are in F2F meetings, any update on that?
16:44:42 <nirik> so, we have a s390x buildvmhost now, and I have configured it. I have been trying to setup a guest builder on it, but networking is not working right. ;(
16:44:55 <nirik> once networking is sorted, I hope to move all the existing builders to it.
16:47:05 <mboddu> #info Now we have a s390x buildvmhost now, and nirik have configured it but it has networking issues, once its sorted out, nirik will try to setup a guest builder on the buildvmhost and once tested, all the existing builders will moved
16:47:17 <mboddu> #topic Open Floor
16:47:22 <mboddu> Anything?
16:47:24 <nirik> its quite noticabily faster...
16:47:38 * mboddu looking forward for it
16:48:47 <nirik> me too
16:49:48 <mboddu> Well, if nothing, lets close the shop and give back the 10 min
16:49:52 <mboddu> Thanks nirik for joining
16:50:44 <mboddu> #endmeeting