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