17:03:07 <mboddu> #startmeeting RELENG (2017-10-19)
17:03:07 <zodbot> Meeting started Thu Oct 19 17:03:07 2017 UTC.  The chair is mboddu. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:03:07 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:03:07 <zodbot> The meeting name has been set to 'releng_(2017-10-19)'
17:03:07 <mboddu> #meetingname releng
17:03:07 <zodbot> The meeting name has been set to 'releng'
17:03:08 <mboddu> #chair dgilmore nirik tyll sharkcz masta pbrobinson pingou puiterwijk maxamillion mboddu Kellin
17:03:08 <zodbot> Current chairs: Kellin dgilmore masta maxamillion mboddu nirik pbrobinson pingou puiterwijk sharkcz tyll
17:03:08 <mboddu> #topic init process
17:03:23 <nirik> morning
17:03:28 <puiterwijk> hi
17:05:29 <mboddu> We will wait for couple more min for more people to join
17:07:44 * masta is around
17:08:01 <dustymabe> masta: \o/
17:08:53 <mboddu> Okay, lets get started
17:09:01 <mboddu> since dustymabe is here, we will start with his request
17:09:05 <mboddu> :)
17:09:25 <dustymabe> :0
17:09:31 <dustymabe> :)
17:09:31 <mboddu> #topic #7100 new koji tags for atomic host
17:09:38 <mboddu> #link https://pagure.io/releng/issue/7100
17:09:58 * dustymabe will give people time to read the ticket
17:10:45 <nirik> so I guess ostree doesn't care about versions?
17:10:57 <dustymabe> about versions of rpms?
17:11:11 <nirik> yeah
17:11:36 <nirik> might be confusing to end users, but I don't know how many would notice if it doesn't care.
17:11:42 <dustymabe> not really. if I have rpm version 1 in one commit and then version 2 in the next and version 1 in the next
17:11:44 <dustymabe> it doesn't matter
17:12:06 <dustymabe> it *will* show the user that something was downgraded
17:12:14 <dustymabe> but ultimately the tooling works fine
17:12:17 <nirik> does this need happen often?
17:12:30 <dustymabe> nirik: i certainly hope not
17:13:00 <dustymabe> this shouldn't be something we need often, assuming our tests and gating are good and get better over time
17:13:08 <nirik> seems odd to plan for it if it's not something that happens...
17:13:14 <dustymabe> ideally we will catch things before they make it to "stable"
17:13:33 <nirik> yeah
17:14:03 <nirik> so at the least this would affect koji-gc and signing... not sure what else, might have to ponder on it.
17:14:07 <dustymabe> nirik: the important part is that we can identify problems and revert them and then the 'stream' of updates can march on and properly get tested on a tree that is not failing
17:14:25 <dustymabe> so rather than wait a few days while rpm-xyz fixes the issue, we can continue to get good tests run on atomic host
17:15:26 <dustymabe> the important thing here is that I don't think this request actually requires development work to be done
17:15:37 <dustymabe> i.e. it should work with the existing features of koji
17:15:39 <nirik> well,we have to adjust koji gc and signing.
17:15:41 <dustymabe> assuming we get permissions
17:16:19 <dustymabe> nirik: I'd like to know what work that entails?
17:16:28 <dustymabe> and is signing an issue?
17:16:29 <mbonnet> nirik: any packages tagged into -overrides should already be signed, because they're older packages
17:16:37 <nirik> it's all just adjusting config... not new development
17:16:39 <mbonnet> and I don't think this will affect koji-gc
17:16:55 <nirik> well, we want to keep the ones we use if they are in override no?
17:17:00 <mbonnet> depending on the current config, it should just keep working
17:17:12 <mbonnet> koji-gc shouldn't gc packages that are "latest" in a tag
17:17:31 <mbonnet> and anything tagged into -overrides would be latest
17:17:32 <nirik> ok. I have not looked at our config in a while... ;)
17:17:40 <dustymabe> :)
17:17:45 <dustymabe> thanks mbonnet for the clarification
17:18:14 <mbonnet> dustymabe: no prob. :)
17:18:23 <nirik> anyhow, seems ok to me. I
17:18:34 <nirik> d like others input tho... dgilmore, etc.
17:18:48 <dustymabe> nirik: sure. i'd like that as well
17:19:09 <nirik> seems like it should work.
17:19:20 <dustymabe> dgilmore: mboddu ?? any thoughts?
17:19:45 * nirik notes dgilmore is traveling this week. not sure he's on.
17:19:56 <dustymabe> nirik: fun
17:20:09 <nirik> always fun. ;)
17:20:16 <mboddu> dustymabe: seems okay to me, not much of a work if its just config changes
17:20:42 <dustymabe> mboddu: can we update the ticket with at least the discussion from this meeting. we can ask dennis to review in the ticket
17:20:52 <mboddu> dustymabe: as nirik mentioned, better get another opinion from Dennis
17:20:53 <dustymabe> maybe give him a week to review?
17:20:56 <mboddu> dustymabe: sure, will do
17:21:00 <maxamillion> .hello maxamillion
17:21:00 <nirik> sure.
17:21:00 <zodbot> maxamillion: maxamillion 'Adam Miller' <maxamillion@gmail.com>
17:21:02 <maxamillion> sorry I'm super late
17:21:06 <maxamillion> completely lost track of time
17:21:21 <dustymabe> maxamillion: we were talking about you the whole time
17:21:28 <maxamillion> dustymabe: good then
17:21:31 <maxamillion> :P
17:21:32 <nirik> ssssh... he's here now. ;)
17:21:37 <mboddu> #info The plan seems okay so far, but we will get another review from dgilmore.
17:22:03 <dustymabe> #info all of maxamillions fedora badges will be transferred to bowlofeggs
17:22:14 <dustymabe> :)
17:22:16 <dustymabe> #undo
17:22:26 * dustymabe is not even chair
17:22:45 <mboddu> maxamillion: ^^^ for being late ;)
17:23:23 <mboddu> Okay, moving on
17:23:37 <maxamillion> :)
17:23:51 <mboddu> #topic #7097 Automate the process of reviewing and merging PRs on releng/fedora-scm-requests
17:23:57 <tyll> .hello till
17:23:58 <zodbot> tyll: till 'Till Maas' <opensource@till.name>
17:23:58 <mboddu> #link https://pagure.io/releng/issue/7097
17:24:36 <masta> regarding #7100 , looks sane to me
17:24:46 <nirik> I'd be fine with automating PRs for those if we can do so with proper checks, etc.
17:25:51 <mboddu> nirik: But dont you think we need to re-review the review?
17:26:10 <mboddu> nirik: I mean just a glance at it, to check if properly done
17:26:15 <nirik> for changing anytia status or who gets assigned bugs on a branch of an existing package: no.
17:26:17 * mboddu is not sure how much can be automated
17:26:33 <nirik> we definitely still want a check for new packages.
17:26:36 <nirik> IMHO
17:26:44 <mboddu> nirik: yes, I am talking esp about new packages
17:26:50 <tyll> we had a lot of checks in pkgdb-admin before moving away from pkgdb
17:27:14 <nirik> this ticket is only about PRs
17:27:36 <mboddu> tyll: No, I think its for everything
17:27:39 <nirik> that change anitya status and who is assigned bugs override for branches (like epel)
17:27:51 <tyll> ah, sorry
17:28:11 <tyll> yes, this should be self-service/automated IMHO - no reason for a human to review it
17:28:51 <tyll> AFAICS it is just not automated anymore because of the switch away from pkgdb
17:29:35 <mboddu> tyll, nirik : I think we can automate 3 and 4, but IMHO definitely not 1 and probably not even 2
17:30:20 <nirik> mboddu: I don't read the ticket as asking us to. It already says 1 and 2 are handled by fedrepo_req
17:30:45 <tyll> yes, I misread it initially - it is only about 3 and 4
17:30:46 <nirik> anyhow, agreed. we don't want to automate 1
17:30:59 <nirik> I think we definitely _do_ want to automate 3 and 4
17:31:11 <nirik> 2 might be possible but would need a fair pile of checks.
17:31:40 <mboddu> nirik: Oh, I thought limb is still handling 1 and 2
17:31:51 <mboddu> nirik: but I agree with you
17:32:18 <tyll> iirc for 2 there pkgdb-admin processed it automatically when the checks were good (it just only happened when an admin ran the tool, but then the admind did not have to do much)
17:32:31 <tyll> s/there//
17:35:15 <mboddu> So, I think we should ask pingou and his team to remove the automation on 1 and 2, and let them know we are okay with automating 3 and 4
17:37:23 <tyll> there is no automation for 1 and 2 at the moment
17:37:48 * nirik is +1 to the proposed automating of items 3 and 4
17:38:23 * tyll is also +1 for 3 and 4
17:39:55 <mboddu> Okay, everyone +1 with 3 and 4
17:40:32 <mboddu> So, what about 1 and 2? If its automated should we ask them to remove it and if its not automated, then ask them to not do it?
17:41:17 * mboddu thinks 1 and 2 are not fully automated
17:42:08 <mboddu> AFAIK, fedrepo-req-admin just gives the admin with the info on tickets that needs to be handled and does some basic checks
17:42:34 <tyll> 1 and 2 are not automated andafaik there are only plans to automate all the checks
17:43:17 <tyll> it is more or less this: https://taiga.fedorainfracloud.org/project/acarter-fedora-docker-atomic-tooling/us/851
17:43:51 <tyll> unretiring, new-packages and new branches share most checks
17:46:12 <mboddu> tyll: Okay, so should we say them not to automate it then? I think they can do some basic checks, but the decision should be man made
17:47:53 <tyll> AFAIK nobody is really pushing forward to automate it... at most the tool will tell the human that everything is ok.
17:48:48 <nirik> well, I think case 2 could be someday automated... but we don't need to decide that now.
17:49:27 <mboddu> tyll: Okay
17:49:29 <mboddu> nirik: sure
17:49:41 * nirik needs more coffee.
17:49:42 * mboddu will update the ticket
17:49:55 <mboddu> nirik: I will join you for cup of tea :)
17:50:06 <mboddu> Okay, moving on
17:50:24 <mboddu> #topic Alternative Architectures updates
17:51:33 <mboddu> sharkcz: any updates?
17:53:20 <mboddu> #undo
17:53:20 <zodbot> Removing item from minutes: <MeetBot.items.Topic object at 0x26883c90>
17:54:17 <mboddu> #info Tune the anitya integration flag and Set bugzilla overrides (so EPEL bugs go to a different person than the Fedora ones) can be automated. But new package and branch request cannot be automated.
17:54:46 <mboddu> Seems like sharkcz is not around
17:55:02 <mboddu> So, moving to open floor
17:55:05 <mboddu> #topic Open Floor
17:55:22 <mboddu> Anybody has anything?
17:55:29 <maxamillion> not I
17:55:56 <Kellin> mboddu: I have a headache, does that count? =D
17:56:25 <mboddu> Kellin: yes, but not in the minutes :)
17:56:41 <Kellin> here's an open question:
17:57:24 <Kellin> does anyone know what this is (beyond the obvious) and why it wasn't updated for EPEL-7 - https://pagure.io/releng/blob/master/f/scripts/check_epel_deps.py
17:58:00 * mboddu dont know
17:58:38 <tyll> afaik noboddy is really checking EPEL for broken deps regularly it if they probably use other scripts
17:59:27 <Kellin> so was this supposed to be a regularly running thing?
17:59:47 <nirik> there were several attempts for such a thing over the years...
18:00:09 <nirik> this was probibly one that got far enough to get checked in, but not run? don't recall
18:01:32 <mboddu> Okay, we will take this to releng channel
18:01:49 <mboddu> We are over time
18:01:55 <mboddu> Thanks everyone for joining
18:01:57 <Kellin> thanks for the insights
18:01:59 <tyll> I have something, too
18:02:05 <mboddu> tyll: sure, go ahead
18:02:09 <mboddu> tyll: sorry
18:02:52 <tyll> Since the switch away from pkgdb2 the script for retiring orphaned packages is not ready to retire these packages. Therefore it is not running.
18:03:10 <tyll> However, the problem is, that we lost the ability to orphan certain branches in the current setup
18:03:28 <tyll> there is at least one ticket open about this but it does not seem to be moving
18:03:38 <nirik> I thought we were going to revisit that...
18:03:42 <tyll> So I wanted to make sure that everyone is aware of tthe situation
18:03:45 <nirik> because being able to do that is important.
18:03:52 <nirik> but yeah, not much movement
18:04:30 <mboddu> tyll: yeah, not much movement there
18:04:40 <Kellin> tyll: can you share the ticket # in releng channel and I'll get it into Taiga
18:04:42 <tyll> yes, my proposal was to use the scm-requests repo owner override setup to mark branches as orphaned and/or not orphaned... However it is also very cumbersome to work with that repo IMHO
18:04:53 <tyll> ok, I will fetch the details
18:05:12 <Kellin> we can continue on in releng channel; I think the other group needs this one
18:05:52 <tyll> ok
18:06:22 <mboddu> #info Since the switch away from pkgdb2 the script for retiring orphaned packages is not ready to retire these packages. We are working on fixing it.
18:06:57 <nirik> I think we may need pagure changes for it..
18:07:03 <nirik> as it doesn't know about owners per branch
18:07:35 <maxamillion> heh
18:07:37 <maxamillion> awesome
18:08:33 <tyll> owners per branch would probably be the cleanest solution
18:09:03 <mboddu> tyll: yeah, but dist-git over pagure doesn't support it
18:09:59 <mboddu> tyll: that was one of my initial questions to them, but... here we are
18:11:21 <mboddu> Anyway, we should close this one here, and continue on releng channel
18:13:32 <mboddu> Thanks everyone for joining
18:14:02 <mboddu> #endmeeting