13:01:57 #startmeeting rpm_packaging 13:01:57 Meeting started Thu Sep 29 13:01:57 2016 UTC and is due to finish in 60 minutes. The chair is dirk. Information about MeetBot at http://wiki.debian.org/MeetBot. 13:01:58 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 13:02:01 The meeting name has been set to 'rpm_packaging' 13:02:02 #topic roll call 13:02:13 o/ 13:02:14 hi 13:02:15 o/ 13:03:09 ping dirk toabctl IgorYozhikov number80 jruzicka jpena aplanas 13:04:21 IgorYozhikov: ? 13:04:36 o/ 13:05:02 ok, let's start 13:05:11 dirk: ? 13:05:48 yes, sorry 13:06:16 #topic Chair for the next two weeks (hguemar absent on october, 6) 13:06:24 I'm also absent very likely 13:06:34 anyone's up for october, 6 at least? 13:06:35 I can probably do the week after 13:06:48 I can do Oct 6 13:06:51 #info dirk chairing october,13 meeting 13:06:57 I can also 13:06:58 #info jpena chairing october,6 meeting 13:07:01 ah right 13:07:10 ah, ok 13:07:12 #topic promote SUSE and MOS CI to voting gates (final decision) 13:07:32 no opposition on the list, anyone who disagree with promotion? 13:07:44 no, +1 for me 13:07:48 +1 13:07:51 +1 13:08:01 +1 13:08:03 update from MOS side: we will handle stable/newton after branching process done in our downstream 13:08:08 so for master +1 13:08:18 let's make them voting 13:08:21 I checked with infra-root earlier, and we're now able to add gates to rpm-packaging-ci group 13:08:21 dirk, SUSE CI already handles stable/newton, right? 13:08:25 toabctl: yes 13:08:30 there were a few hickups in the last few days 13:08:36 Or, we can do it sooner if need arises. 13:08:36 also caused by a broken harddrive and other issues 13:08:40 but things should be good again 13:08:59 our branching in progress 13:09:17 believe that it takes a week 13:09:28 IgorYozhikov: ping me when you're done and I'll add MOS CI 13:09:28 so very soon we could handle newton too 13:09:38 number80, sure 13:09:40 dirk, toabctl: suse CI is ready? 13:09:45 number80: yes 13:09:47 number80, yes 13:09:50 You can add MOS CI as voting right now for every branch. 13:09:53 ok, I'll get it added today 13:10:04 It just won't vote in stable/newton. 13:10:10 astsmtl: if you say so, I'll add it then :) 13:10:13 number80: thanks. youcould do in theory yourself once permissions are changed in gerrit 13:10:19 but for now you need an infra root 13:10:26 dirk: perms were fixed 13:10:31 oh, great 13:10:52 astsmtl: you need to change config then to remove the non-voting flag fyi 13:11:12 #action number80 change gate checks to allow voting for SUSE ci + mos ci 13:11:20 #action dirk change suse ci to propagate voting 13:11:24 I thought we'll make one CR for both CI systems 13:11:44 If not, we can modify config for MOS CI separately. 13:11:48 astsmtl: I think it is a dual change. once "allowing voting" and one "do vote" 13:12:01 the "do-vote" thing is a option in your local zuul 13:12:10 ok, added 13:12:22 :) 13:12:29 #topic package reviews 13:12:41 #link https://review.openstack.org/#/q/project:openstack/rpm-packaging+status:open 13:12:51 anything somebody wants to bring up 13:12:56 in general things seem to be progressing 13:13:18 there are two reviews that are stalled 13:13:26 https://review.openstack.org/#/c/357361/ 13:13:31 this one depends on python-mistral 13:13:39 does anyone want to create a mistral package in rpm-packaging? 13:13:52 it doesn#t have to be perfect, just good enough to satisfy the dependency :) 13:13:56 JFYI, I'm working on ceilometer. 13:14:07 I wouldn't start with mistral for service personally 13:14:19 I think IgorYozhikov wanted to prepare a mistral package 13:14:22 well, it blocks the whole tripleo related packages from going in 13:14:23 And btw, maybe we want some tool to sync on who does what? 13:14:24 I believe - we can 13:14:25 so it is important 13:14:31 Maybe etherpad? 13:14:49 gerrit? 13:14:56 feel free to post a unfinished review 13:15:05 at least I'm somewhat good at checking for duplicates.. 13:15:07 In Mirantis we use Google Spreadsheet for that. 13:15:08 +1 for gerrit. 13:15:14 Ok. 13:15:15 Yep 13:16:03 so can we at least have a mistral package that fulfills the tripleoclient deps? 13:16:11 just not package services and all the other stuff? 13:16:24 we can add that later, but I hate to see other things blocked on it right now 13:16:40 well, tripleoclient should be renamed as triplemessclient 13:16:46 lol 13:16:51 not the easiest one to work on 13:16:56 alternatively we can remove the test dep 13:17:03 it is only for testing iirc, maybe we can get rid of it 13:17:09 it requires quite a lot of things like heat-templates etc ... 13:17:27 so mistral packaging alone won't unblock that review 13:17:33 jpena: wanna try to reduce %check so that we can live without mistral? 13:17:36 so mistral & heat? 13:17:44 dirk: I'll give it a try 13:18:20 #action jpena try removing mistral from *triplo* review s for now 13:18:23 jpena: thanks! 13:18:33 Am I right that we are going to cut mistral from test depends to unlock 3-O*? 13:19:00 yes 13:19:09 at least give that a try 13:19:18 ok 13:19:29 alternatively if somebody has a mistral package, post a review :) 13:19:39 *nods* 13:19:43 but we are running out of clients right now, we need to start with services 13:20:02 dirk, I will try to do that 13:20:16 thanks 13:20:25 anything else on rpm-packaging? 13:20:58 dirk, colleagues did you have a chance to contact out newcomers? 13:21:31 I'm about Chinese folks? 13:21:50 I think number80 wanted to send an email 13:21:52 I haven't 13:21:54 s/out/our/ 13:21:59 but they seem to be active right now 13:22:06 maybe we could invite them here.. 13:22:32 I posted in one of reviews invitation to irc 13:22:38 Yeah, I haven't yet 13:23:12 if nobody does, I will do today or tomorrow 13:23:35 I pinged tony in #rpm-packaging 13:24:00 I'd like to channel their efforts, as some of the clients they submitted needs proper checking (e.g requirements etc...) 13:24:27 so more focused reviews, to have a faster throughput 13:24:38 yep, I saw them 13:24:54 will spend some time today & tomorrow on that 13:24:57 number80: yeah, it would also be good to explain tha tyou can fix more than one character per git commit :) 13:25:06 e.g. all the url changes could have been done in one review 13:26:05 * number80 notes to add that point 13:26:17 Yes, these do not affect builds so it can be done in one go 13:26:30 anyway, no harm done, I'm fine either way 13:26:43 I took the liberty to fastapprove those trivial changes to reduce workload for others 13:26:49 wfm 13:27:18 dirk, https://review.openstack.org/#/c/378444/ - didn't pass SUSE CI 13:27:39 in that PR url changed 13:27:40 IgorYozhikov: thats a flakey test 13:27:46 oslo.messaging fails like 50% of the cases right now 13:27:46 i c 13:27:53 I don't know exactly why, but it is fairly annoying 13:28:08 it is not visible in the mos ci because it only rebuilds one package, while we always rebuild everything against everything 13:28:40 I was already searching in oslo.messaging git whether there is a fix somewhere but couldn't pinpoint one 13:28:43 yes, mos ci rebuilds only changed 13:29:11 I would love to get that one nailed though 13:29:36 next? 13:29:52 #topic pymod2pkg reviews 13:30:04 #link https://review.openstack.org/#/q/project:openstack/pymod2pkg+status:open 13:30:22 https://review.openstack.org/#/c/379419/1/pymod2pkg/__init__.py 13:30:48 look like only 1 PR awaiting 13:31:11 no controversies here 13:31:25 #topic renderspec reviews 13:31:33 #link https://review.openstack.org/#/q/project:openstack/renderspec+status:open 13:31:54 anything there? 13:32:09 same here, if some can +W the g-r one 13:32:13 I'd drom https://review.openstack.org/#/c/336151/ 13:32:16 *drop 13:32:36 omg, dirk, number80 is it normal that I have verified option enabled? 13:32:38 me too 13:32:40 ah, thats a good one 13:32:52 to be honest I can't make up my mind on this one 13:32:56 I see good in either approach 13:32:57 IgorYozhikov: let's see in the other chan 13:33:27 yeah but it's in a bad -1 state 13:33:30 ok, how about discussing it in the mailing list? 13:33:42 astsmtl: do you feel like driving that discussion? 13:33:44 you mean postponing even further 13:33:50 I want to update this CR. 13:34:06 astsmtl, OK, please do. 13:34:07 it's changing the current default behavior. 13:34:09 ok 13:34:15 Let return do discussion after that. 13:34:20 great 13:34:20 jruzicka: no, just want to avoid eternal postponing, because nobody can take a final decision on the design 13:34:50 we got our next step there, so I'm happy 13:34:55 ok 13:35:06 can someone summarize the next step in an agreed statement for the bot ? 13:35:20 toabctl, how's the {{ requires going }} ? 13:35:28 * jruzicka summarizing 13:35:38 jruzicka, no progress. I was on vacation (and will be on vacation again) 13:36:06 #action astsmtl to upload next version of https://review.openstack.org/#/c/336151/ before continuing discussion 13:36:14 jruzicka: thx 13:36:18 #topic open discussion 13:36:54 can I haz new releases for renderspec and pymod2pkg? They'll be useful to complete DLRN support for the 3rd party CI 13:37:15 jpena: sure 13:37:21 oh, right, how do one make a relese btw? 13:37:25 thx :) 13:37:27 is just pushing verison tag enough? 13:37:32 jruzicka: sending a review to releases repo 13:37:38 ah yes 13:37:44 * number80 will take care of that 13:38:02 #action number80 to release new versions of pymod2pkg and renderspec with latest fixes 13:38:15 wait I'm not chair :D 13:38:17 I'd like to finalize summit fishbowl agenda, there was no new changes for a while, are we good? 13:38:20 yes 13:38:44 jruzicka: sorry 13:38:51 my bad, I came late 13:38:53 #chair jruzicka number80 IgorYozhikov toabctl jpena astsmtl 13:38:54 Current chairs: IgorYozhikov astsmtl dirk jpena jruzicka number80 toabctl 13:39:05 #action astsmtl to upload next version of https://review.openstack.org/#/c/336151/ before continuing discussion 13:39:08 #action number80 to release new versions of pymod2pkg and renderspec with latest fixes 13:39:17 Oh, sorry guys, seems like I was wrong, and I will no do another version of this request 13:39:33 s/no/not 13:39:41 even better! 13:39:43 astsmtl: you mean the renderspec change or something else? 13:39:50 astsmtl, please abandon it in that case 13:39:51 So we can discuss it here or in ML. 13:39:54 yes 13:40:22 I won't abandon it, because I believe that this beahviour is much better than what we have now. 13:40:33 so I didn't understand your sentence, then 13:41:57 :D 13:42:21 I mean - I can't improve it more. :P 13:42:50 oh I see 13:43:11 then, let's discuss about design, and make choices 13:43:32 Until we do so, nobody will agree on what to do with this review 13:43:47 so I think what astsmtl wants to do is 13:43:54 "if a file was given as argument, and it doesn't exist, fail" 13:44:07 yes, reasonable 13:44:09 "if a file was not given explicitely but is the default, then *fail* as well" 13:44:14 right? 13:44:36 and the latter part is what jruzicka objects to, right? 13:44:43 No, if file was not specified we don't want to fail. 13:44:58 ah, ok 13:45:21 so if it was not specified explictly on command line but the implict one does not exist, silently ignore that 13:45:29 * number80 will revisit review again 13:46:14 yeah but then I found out the default isn't used 13:46:15 Oh.. again no. 13:46:31 and it's also outside of current dir which is maddness 13:46:45 There cannot be default values for these files. 13:46:48 I'll revisit it too. 13:46:57 astsmtl, oh there can as well as requirements.txt is 13:47:12 So if you want them to affect render process - you specify them explicitly. 13:47:41 astsmtl: I'll add it to next week meeting agenda, so it doesn't drag further 13:48:13 astsmtl, templates that are part of renderspec also affect render process yet you don't need to pass them 13:48:28 Because they are part of renderspec. 13:48:50 If we make global-requirements.txt and epochs part of renderspec, they can be used by default. 13:48:52 yes and we can have a convention for arbitrary files that affect the rendering process 13:49:14 That was my idey, that I reconsidered. 13:49:18 if sane and well documented, I'm always for tools that work without parameters for the default use case 13:49:22 s/idey/idea/ 13:49:48 Well, propose good default value then. 13:49:50 I'm not aware about such convention now, so we can remove this unused magic 13:49:56 and reintroduce it when needed 13:50:07 hi TonyXu 13:50:16 astsmtl, yes, alternative to your change would be a good default :) 13:50:34 Not alternative but addition I think. 13:50:50 removing the removal :D 13:51:02 sure. I'll revisit the review until next meeting 13:51:33 My change has an important point that specified non-existing files should lead to failure. 13:51:39 explicit is good unless you don't need to be explicit about obvious things that are same 90 % of time :) 13:51:56 astsmtl: hmm, so one thing we could do is require a single "--context" parameter that refrences all files that should be used for rendering a spec 13:52:07 if its not given, we abort 13:52:19 if it is given, we have pointers to everything that will be considered that way 13:52:54 but do we use epoch.yaml in the render process? 13:52:59 then jruzicka is still happy because he could alias "renderspec" to "renderspec --context fedora-with-all-my-epochs-and-deps" and be good 13:53:06 It's the same as current request. 13:53:24 astsmtl: ok, I guess I didn't read that out of the existing git commit message 13:53:26 well I'm OK with current concept (the second revision) 13:53:37 I might have had a bad understanding 13:53:38 just need to test it again 13:53:53 let's stop this 13:54:00 ok 13:54:08 #action jruzicka revisit https://review.openstack.org/#/c/336151/2 13:54:09 all information required has been transfered 13:54:13 yes 13:54:19 great, thanks astsmtl and jruzicka 13:54:23 :) 13:54:23 anything else before we end? 13:55:16 nope 13:55:24 ok, cya, and toabctl, don't make too much vacation ;) 13:55:26 #endmeeting