14:30:25 <mboddu> #startmeeting RELENG (2017-05-01)
14:30:26 <zodbot> Meeting started Mon May  1 14:30:25 2017 UTC.  The chair is mboddu. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:30:26 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
14:30:26 <zodbot> The meeting name has been set to 'releng_(2017-05-01)'
14:30:26 <mboddu> #meetingname releng
14:30:26 <zodbot> The meeting name has been set to 'releng'
14:30:26 <mboddu> #chair dgilmore nirik tyll sharkcz masta pbrobinson pingou puiterwijk maxamillion mboddu Kellin
14:30:26 <zodbot> Current chairs: Kellin dgilmore masta maxamillion mboddu nirik pbrobinson pingou puiterwijk sharkcz tyll
14:30:26 <mboddu> #topic init process
14:30:35 <nirik> morning
14:30:48 <Kellin> .hello kellin
14:30:52 <zodbot> Kellin: kellin 'None' <kellin@retromud.org>
14:32:32 <masta> hey gang
14:35:45 <mboddu> I think lot of people are attending the summit, so lets see how much we can cover
14:36:02 <mboddu> #topic #6767 Creating a Pagure repo/project for "PkgDB related tickets"
14:36:09 <mboddu> #link https://pagure.io/releng/issue/6767
14:36:52 <mboddu> I know that there are talks on decommissioning pkgdb, but not sure we have decided on it and whats the future plan for it.
14:37:18 <dgilmore> hey all
14:37:21 <nirik> I think it's all still in the discussion phase... so I would just defer this.
14:37:43 <dgilmore> I reached out to mprahl's boss as well
14:37:58 <dgilmore> as I found the request way too abrasive and demanding
14:40:19 <mboddu> dgilmore: you added meeting keyword on the ticket is there something you want to share from your discussion or can we defer the ticket until it gets finalized?
14:41:07 <dgilmore> mboddu: well I felt it was something we needed to discuss
14:42:05 <dgilmore> If we are to choose a location I would suggest releng/dist-git-requests or something like it
14:42:09 <masta> I've not seen a "decision"
14:42:13 <nirik> The ticket presents that as decided, but I really don't think it's been decided... it was just discussed some in a thread.
14:42:40 <masta> perhaps the phrasing is wrong
14:43:27 <nirik> One thing that might be good for this effort is a wiki page or something clearly outlining old and new, then deciding if we want to do that and if we agree with all the new process decisions.
14:43:40 <nirik> we are going to need a document for people looking for things for sure.
14:43:42 <dgilmore> nirik: yeah, its part of the harshness I saw in it
14:43:57 <dgilmore> we should gather some questions we want to ask
14:43:59 <bowlofeggs> .hello bowlofeggs
14:44:00 <zodbot> bowlofeggs: bowlofeggs 'Randy Barlow' <randy@electronsweatshop.com>
14:44:08 <mboddu> nirik: yeah I like the idea.
14:44:13 <dgilmore> and make sure we are engaged and involved in the discussions
14:44:19 <dgilmore> because todate we have not been
14:44:47 <dgilmore> nirik: would be good
14:44:55 * nirik nods. I definitely see the appeal in getting rid of pkgdb if we can get all it's functions handled
14:45:03 <nirik> one less app is great. ;)
14:45:04 <mboddu> We can ask them to create a wiki page and based on that we can ask our questions
14:45:09 <dgilmore> pkgdb is a big piece of glue today
14:45:24 <dgilmore> we have to be involved in any decision to replace it
14:45:32 <masta> perhaps a feature page?
14:45:36 <dgilmore> not have some team/person say we are throwing it out
14:45:43 <dgilmore> and you have to change
14:46:01 <Kellin> also - is there even value to getting rid of it, or is it 'need-more-shiny' syndrome
14:46:43 <dgilmore> Kellin: well some of what it does, does not make as much sense if we change the way we branch in dist-git
14:46:50 <nirik> well, if other stuff all does that or most of it, then having one less app to maintain is good.
14:47:16 <nirik> and yeah, it's very suited to packages, other stuff has been bolted on
14:47:18 <masta> I'll take the action to respond to  mprahl with our agreed sentiment, are we agreed that a preliminary wiki page is the next step?
14:47:21 <dgilmore> if we can drop maintainence burden's that is good
14:47:23 <mboddu> Also, if I am not wrong I think modularity is another driving criteria
14:47:55 <dgilmore> mboddu: thats driving the look at changing how we do branching
14:48:34 <dgilmore> it may be that a lot of what is in pkgdb can move to pdc
14:48:46 <masta> dgilmore, I was just thinking that too
14:48:50 <dgilmore> but this all feels rushed and premature
14:49:01 <Kellin> mboddu: modularity driving change is fine, but replacing a tool means re-finding all the little issues that were smoothed out over however many years of service.  so it's a matter of adding modularity or adding everything we have, re-testing, and then adding modularity.  it's a huge scope difference
14:50:03 <mboddu> Kellin: yeah, thats true.
14:50:14 <dgilmore> Kellin: well modularity breaks a ton of hard coded assumptions
14:50:29 <dgilmore> I see good cases both ways, but we need more data and engagement
14:50:39 <Kellin> agreed
14:51:17 <dgilmore> propoased #agreed masta to engage on the ticket to get us more information and engagement
14:51:27 <dgilmore> +1 to my proposal
14:51:31 <mboddu> +1
14:51:32 <masta> will do
14:51:39 <masta> +1
14:51:49 <Kellin> +
14:53:28 <mboddu> #agreed masta to engage on the ticket to get us more information and engagement
14:53:44 <mboddu> Okay, lets move on
14:54:29 <mboddu> #topic #6746 Produce a slimmed-down compose whenever certain packages appear in an update
14:54:37 <mboddu> #link https://pagure.io/releng/issue/6746
14:55:34 <mboddu> We met QA team and here's the meeting minutes from that meeting https://pagure.io/releng/issue/6746#comment-437307
14:55:37 <masta> so doing CI on anaconda and grub2, etc... seem reasonable
14:56:35 <mboddu> masta: yeah, but they want more, but we might start with small list and see where it goes
14:57:22 <dgilmore> masta: likely eventually anytime any of the anaconda runtime changes
14:57:57 <mboddu> Also, I created the pungi configs for the compose, and there's a PR in pungi-fedora https://pagure.io/pungi-fedora/pull-request/215
14:58:50 <masta> it would be more pressure on the compose system, but arguably worth it for QE.
14:59:19 <dgilmore> mboddu: I think it needs a lot of work still
15:00:27 <mboddu> dgilmore: okay, if you can comment on it, I can look at it and update it.
15:00:56 <mboddu> dgilmore, nirik : also, where do you think we should run this?
15:01:16 <masta> the listener ?
15:01:23 <nirik> compose-x86-01 probibly?
15:01:39 <dgilmore> I would say branched-composer
15:01:44 <mboddu> masta: nope, actual compose
15:01:54 <dgilmore> we already have quite a bit going on on xompose-x86-01
15:02:01 <nirik> branched composer could be fine.
15:02:04 <dgilmore> compose-x86-01
15:02:10 <mboddu> nirik: I think we have several things running on compose-x86-01
15:02:15 <nirik> or we could make a new instance if needed
15:02:51 <mboddu> nirik: I think branched makes sense if it can handle it
15:03:10 <nirik> sure
15:03:23 <masta> it seem contextual, so long as the list of packages is small
15:04:01 <masta> if this list will grow, more infra might be a thing
15:04:04 <linuxmodder> .fas linuxmodder-
15:04:05 <zodbot> linuxmodder: 'linuxmodder-' Not Found!
15:04:14 <linuxmodder> .fas linuxmodder
15:04:15 <zodbot> linuxmodder: linuxmodder 'Corey W Sheldon' <sheldon.corey@openmailbox.org>
15:04:17 <dgilmore> masta: well the compose would not change
15:04:28 <dgilmore> but we would do them more often
15:05:53 <mboddu> #info mboddu will update the pungi configs based on dgilmore comments
15:06:28 <mboddu> #info we will use branched-composer.phx2.fedoraproject.org to do the composes
15:06:55 <masta> would the CI compose goes into some special name space?
15:07:29 <masta> these are not the same as nightly, even more volatile, yes?
15:08:03 <masta> to be clear, I'm all in favor of this idea... just scoping out.
15:09:07 <mboddu> masta: they will be located in /mnt/koji/compose/ and yes they will have different set of rules compared to nightlies
15:10:17 <masta> mboddu, that is good
15:10:31 <mboddu> Another thing that we need to work on here is fedmsg listener
15:13:27 <nirik> well, if possible I'd like to use loopabull for that. Should be able to configure it for listening and firing off the compose.
15:14:02 <mboddu> nirik: any idea when it will be ready to use?
15:14:21 <nirik> I thought it already was, but I might be misremembering...
15:15:47 <dgilmore> we should do things in a standardised manner
15:20:10 <mboddu> dgilmore: by standardized you mean fedmsg driven compose since all our composes right now are cron jobs.
15:20:44 <dgilmore> mboddu: no
15:21:10 <dgilmore> I mean that we need to do it in a standardised manner.
15:21:30 <dgilmore> anything we have running from cron today needs to be done in a different way
15:22:00 <dgilmore> as cron is not really a good way to do things allowing for reporting and transparency
15:22:17 <dgilmore> or getting statistics etc
15:22:51 <mboddu> dgilmore: okay, you want to have a standardized manner of doing composes and we will use that to do this compose as well
15:23:00 <dgilmore> mboddu: yes
15:23:00 <nirik> my understanding is that loopabull was going to be that
15:23:16 <dgilmore> and replace how we do all the existing ones
15:23:35 <dgilmore> nirik: until two weeks ago I had never heard of loopabull
15:23:40 <dgilmore> nirik: so it may well be
15:23:50 <dgilmore> but it has to be communicated and decided on
15:23:54 <mboddu> dgilmore: okay
15:24:15 <nirik> sure. and... it's unlikely to be done today now in this meeting. ;)
15:24:26 <dgilmore> right
15:24:43 <dgilmore> I was being vague in my standardised way messaging
15:24:47 <dgilmore> because that has to be figured
15:26:06 <mboddu> #action Investigate to find a standardized way to do composes and see if loopabull fits our needs
15:26:15 <dgilmore> anyway lets record that its agreed we will do the ocmpose in a standardised manner
15:26:31 <dgilmore> mboddu: I would not mention loopabull
15:26:44 <mboddu> dgilmore: okay, let me undo it
15:26:46 <mboddu> #undo
15:26:46 <zodbot> Removing item from minutes: ACTION by mboddu at 15:26:06 : Investigate to find a standardized way to do composes and see if loopabull fits our needs
15:27:11 <mboddu> #action Investigate to find a standardized way to do composes
15:27:54 <mboddu> #agreed We will do the minimal compose in a standardized manner
15:28:06 <mboddu> Okay, we have few min left
15:28:08 <dgilmore> and we will be doing the compose using a standardised framework
15:28:31 * dgilmore has two things for open floor
15:28:34 <mboddu> #Open Floor
15:28:46 <mboddu> #topic Open Floor
15:28:51 <dgilmore> 1st thing is to say we have imported s390x on friday
15:29:00 <dgilmore> and enabled it for building in rawhide
15:29:11 <dgilmore> so far things seem to be smooth
15:29:13 <Kellin> hooray
15:29:22 <masta> hrm...
15:29:30 <masta> we should monitor this
15:29:31 <dgilmore> 2nd is that we need to get a s390x builder in the compose channel
15:29:39 <mboddu> dgilmore: awesome, I know you hit couple of signing issues, are all those resolved?
15:29:39 <dgilmore> and get things setup so that we can compose it
15:30:01 <dgilmore> mboddu: yes, we hit some bugs in sigul and sigul_signunsigned.py
15:30:11 <dgilmore> asll 229k+ rpms in rawhide are signed
15:30:14 <nirik> I'm still waiting on a firewall change to setup a cache there. That should improve build speeds.
15:30:19 <mboddu> dgilmore: cool
15:30:31 <dgilmore> nirik: build speed seems fine so far
15:30:58 <masta> this is kinda cool, so long as build times are good
15:31:25 <mboddu> #info dgilmore imported s390x into primary koji on Friday and enabled it for building in rawhide.
15:31:36 <dgilmore> koji taginfo f27-build
15:31:36 <dgilmore> Tag: f27-build [425]
15:31:38 <dgilmore> Arches: aarch64 armv7hl i686 ppc64 ppc64le s390x x86_64
15:31:40 <nirik> dgilmore: sure, but also it's sucking up BW.
15:31:47 <dgilmore> nirik: sure
15:31:56 <dgilmore> reducing bandwidth is good
15:32:50 <masta> so this kinda closes the chapter on "alternative architectures", right?
15:32:51 <mboddu> #action We need to get a s390x builder into the compose channel
15:34:28 <masta> all architectures are all happening in the primary koji instance, right?
15:34:35 <nirik> well, we have to keep ppc and aarch64 around until f25 goes away and s390 around until f26 goes away
15:35:02 <dgilmore> masta: for rawhide yes
15:35:08 <dgilmore> masta: well the official ones
15:35:29 <dgilmore> there is work outside of primary koji for mips and openrisc I think
15:35:42 <masta> yes...
15:36:01 <dgilmore> it is a step in the door of the alt arch redefinition
15:36:32 <dgilmore> anyway I have nothing else
15:36:35 <masta> anybody can host a koji instance for their architecture, I'd expect risc-v next
15:36:58 <mboddu> thanks dgilmore
15:36:59 <nirik> Oh I have a quick item or two...
15:37:07 <mboddu> nirik: sure, go ahead
15:37:16 <nirik> mass update/reboot cycles this week. So, please note the outage times and such.
15:37:30 <dgilmore> nirik: we need to not update koji
15:37:40 <dgilmore> nirik: or we need to go all in
15:37:42 <nirik> and max is on push duty, but he's at summit so mboddu will do pushes
15:37:46 <dgilmore> do the schema update etc
15:37:58 <nirik> and yeah, I wanted to know if we wanted to do koji update then too or not.
15:38:05 <mboddu> #info nirik is doing mass update/reboot cycles this week. So, please note the outage times and such.
15:38:09 <nirik> is it working ok in stg?
15:38:16 <dgilmore> I was hoping to get 1.12.0 deployed this week
15:38:22 <dgilmore> nirik: seems to be
15:38:30 <dgilmore> not fully tested the new features yet
15:38:41 <dgilmore> I think the new theme we should not deploy
15:38:44 <masta> dgilmore, stage?
15:38:54 <dgilmore> masta: what?
15:39:04 <nirik> ok, the build side outage is tomorrow. So, just let me know if we are a go to do it then or schedule another one.
15:39:12 <masta> can koji .12 go to stage?
15:39:23 <dgilmore> masta: its been in stage for two weeks
15:39:36 <nirik> oh, and also a number of infra folks will be in rdu next week... so if you are looking for us there we are.
15:39:38 <masta> dgilmore, ah, that's great.
15:40:36 <masta> the .12 koji has significant new features. Mostly dist-repos... we can start to look at replacing mash
15:40:53 <mboddu> masta: yep, thats the plan :)
15:41:08 <nirik> 1.12.0 is already in stg
15:41:16 <mboddu> anybody has anything else?
15:42:01 <masta> [nothing]
15:42:41 <mboddu> Okay, lets close it
15:42:46 <mboddu> Thanks everyone for joining
15:42:55 <mboddu> #endmeeting