13:00:38 <toabctl> #startmeeting rpm_packaging 13:00:39 <openstack> Meeting started Thu Jul 14 13:00:38 2016 UTC and is due to finish in 60 minutes. The chair is toabctl. Information about MeetBot at http://wiki.debian.org/MeetBot. 13:00:40 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 13:00:42 <openstack> The meeting name has been set to 'rpm_packaging' 13:00:47 <toabctl> ping dirk toabctl IgorYozhikov number80 13:00:58 <toabctl> #chair number80 13:00:58 <openstack> Current chairs: number80 toabctl 13:01:01 <toabctl> #chair dirk 13:01:03 <openstack> Current chairs: dirk number80 toabctl 13:01:10 <dirk> o/ 13:01:15 <aplanas> hi 13:01:15 <toabctl> hey 13:01:33 <toabctl> please add your agenda points as usual to https://etherpad.openstack.org/p/openstack-rpm-packaging 13:01:58 <mivanov> hi folks 13:02:15 <jruzicka> o/ 13:03:09 <toabctl> #topic Specs with patches, support by CI. 13:03:16 <toabctl> who proposed that? 13:03:59 <dirk> maybe me 13:04:02 <dirk> not remember 13:04:04 <number80> o/ 13:04:15 <dirk> this was a fallout of the python-keystoneclient discussion 13:04:24 <number80> i think it's from mivanov 13:04:27 <dirk> there was a bug in the release we wanted to update to that was fixed in git but not in the release 13:04:37 <dirk> so we wanted to discuss how to add a patch to the .spec.j2 template 13:04:47 <dirk> this was resolved by updating to a newer version of keystoneclient 13:04:49 <number80> (sorry,it's national holiday here, so I'm sitting between army folks :) ) 13:04:51 <dirk> but the problem might come back 13:05:15 * dirk also sits in another meeting and might become unresponsive 13:05:33 <toabctl> should we just postpone the topic? 13:05:49 <number80> yup, nothing to say about it 13:05:53 <toabctl> I agree that we need a solution for that but it seems it's not urgent currently 13:06:00 <dirk> wfm 13:06:00 <number80> *nods* 13:06:02 <toabctl> #agreed postpone patch support topic 13:06:20 <toabctl> #topic Next steps for common upstream binary package building (review status) 13:06:32 <toabctl> again, no idea who proposed it 13:06:47 <number80> wasn't that dirk? (according colors) 13:06:58 <toabctl> number80, so all colors are from dirk? :) 13:07:18 <dirk> number80: postpone 13:07:33 <dirk> I did not have tiem to look at the state of building packages in the gate 13:07:39 <number80> salmon red is dirk, rose is mivanov, I'm weird green 13:07:40 <toabctl> ok 13:07:44 <number80> ack 13:07:52 <toabctl> #topic Logo Mascot status + submission (see https://etherpad.openstack.org/p/openstack-rpm-packaging-logo-ideas ) 13:08:11 <toabctl> dirk, again, you 13:08:33 <dirk> yes 13:08:36 <dirk> so this was announced 13:08:45 <dirk> http://www.openstack.org/project-mascots 13:08:55 <dirk> there is a video in there that explains everything 13:09:05 <dirk> we still need to submit our mascot idea 13:09:33 <toabctl> #link http://www.openstack.org/project-mascots 13:10:02 <toabctl> I haven't looked into it yet. 13:10:10 <dirk> deadline is july 27th 13:10:20 <dirk> it is also about t-shirts, which I really like 13:10:50 <dirk> how do we want to move forward? 13:10:54 <toabctl> so postpone this topic, too? maybe we find time this week to collect ideas? 13:11:02 <dirk> separate session with brainstorming? with video/audio? 13:11:05 <dirk> or email thread? 13:13:21 <toabctl> dirk, can you start an email thread about it? 13:13:31 <dirk> ok 13:13:45 <dirk> #action dirk start mailthread on mascot 13:14:07 <toabctl> #topic Adjust Gerrit so that 2 × V+1 are required, so that we make sure every CI system built and published packages. 13:14:12 <toabctl> dirk again? 13:14:36 <dirk> don't think so 13:14:40 <dirk> this is mivanov from the color 13:14:46 <dirk> but I can summarize it if mivanov isn't around 13:15:17 <mivanov> but i didn't add this or any other topic for today 13:15:36 <toabctl> mivanov, maybe from last week? 13:15:36 <jruzicka> so it's an anonymous stranger 13:15:40 <toabctl> :) 13:15:53 * toabctl is away for 3 minutes .. 13:15:56 <mivanov> didn't think so :) 13:16:14 <mivanov> because i skip previous meeting 13:16:15 <number80> no, it;s mivanov again 13:16:35 <dirk> anyway so the issue is/was that toabctl iirc approved a patch before fuel ci found the review 13:16:47 <number80> ah yeah 13:16:55 <dirk> so on merge the built packages were not "published" to the tree and were missing from future gate checks 13:17:23 <dirk> so I think its just a reminder for core people to not workflow+1 patches that do not have all external gates result reported successfully 13:17:30 <dirk> plus the usual 2x +2 13:17:45 <number80> #info core should pay attention to 3rd party CI results before +W 13:17:59 <toabctl> ack 13:17:59 <dirk> I don't know of a good way to enforce checks being reported 13:18:06 <number80> I think we should add 3rd CI contacts on the wiki 13:18:19 <toabctl> I think there are. 13:18:22 <dirk> I guess we need to add it to the approval queue instead of the check queue only going forward 13:19:08 <number80> well, 3rd party CI are still immature, but we should start working on promoting them to voting gates 13:19:13 <dirk> related tot hat there was my thought of upgrading our existing gates as voting 13:19:14 <toabctl> number80, it's linked here: https://wiki.openstack.org/wiki/Rpm-packaging 13:19:58 <number80> Yeah, I meant human contacts like mivanov 13:20:09 <dirk> number80: well, iirc adding them to the approval queue is a 2nd step 13:20:17 <number80> *nods* 13:20:28 <dirk> we could label the current ones as voting (it only causes the jenkins +1 to turn into a -1 I think) 13:20:44 <dirk> imho we should be doing that at some point 13:20:59 <dirk> it feels to me like that the suse ci is almost there for that, just too slow right now 13:21:15 <dirk> but we could postpone that when we have usptream building 13:21:18 <toabctl> I'm fine with our current process for now. 13:21:26 <number80> Yes, I don't think we're too far from getting them "mature" 13:22:13 <toabctl> next topic? 13:22:16 <dirk> +1 13:22:24 <toabctl> #topic Refreshed stable/mitaka templates 13:22:35 <toabctl> number80, I guess it's your topic? 13:22:39 <number80> I noticed that they didn't build in CI 13:23:09 <number80> so two changes: 1. old pypi url 2. not in sync w/ renderspec changes 13:23:18 <number80> and few refresh specs on top 13:23:23 <dirk> number80: yeah, thanks for taking care of that 13:23:31 <dirk> I'm still digesting the list of open reviews 13:23:33 <toabctl> the SUSE CI is broken for the stable/mitaka branch. I'll try to fix that soon 13:23:46 <dirk> I blacklisted suse ci to not report false status on stable/mitaka 13:23:59 <dirk> so for now feel free to ignore that, although we're going to fix that soon 13:24:07 <toabctl> #action toabctl fix SUSE CI for stable branches 13:24:19 <dirk> (e.g. it is not going to show up as checker for stable/mitaka reviews) 13:24:36 <number80> I don't mind waiting a bit, we need to improve our workflow as well, so it could be a good test case for that :) 13:25:17 <dirk> ok 13:25:31 <toabctl> next? 13:25:39 <dirk> +1 13:25:46 <number80> ok 13:25:51 <toabctl> #topic packages reviews 13:26:02 <toabctl> #link https://review.openstack.org/#/q/project:openstack/rpm-packaging+status:open 13:26:44 <toabctl> anything anybody wants to highlight? 13:27:38 <aplanas> maybe that pbr doesn't require devel and setuptools afaics? 13:28:02 <toabctl> aplanas, I think centos/rhel require setuptools in addition to pbr 13:28:13 <number80> just a question, I have this feedback from suse CI "nothing provides python-urllib3" 13:28:21 <number80> does it have a different name? 13:28:24 <dirk> no 13:28:32 <dirk> we jsut don"t have it in the build environment 13:28:36 <number80> ah ok 13:28:38 <dirk> because we use python-requests 13:28:50 <dirk> I am not sure how to mvoe forward with this to be honest 13:29:05 <number80> well, the previous patchset had only requests 13:29:11 <toabctl> dirk, we can just add it 13:29:41 <dirk> yeah 13:29:42 <dirk> done 13:29:56 <toabctl> dirk, heh. I was 2 seconds to slow :) 13:29:56 <number80> I don't mind, in pratice, requests maintainers forces us to ship the same version of urllib3 than bundled in requests or bundle it 13:30:00 <dirk> to be honest I would remove urllib3 from the spec file though 13:30:13 <dirk> since its an implementation detail of requests from my perspective 13:30:22 <toabctl> no. it's explicitly used in the code 13:30:26 <number80> in pratice, yes 13:30:27 <dirk> but I guess we have to discuss that in the review 13:30:31 <toabctl> there is a "import urllib3" 13:30:57 <number80> *nods* 13:31:02 <number80> let's postpone that discussion 13:31:07 <toabctl> +1 13:31:08 <number80> and leave it as-is 13:31:56 <toabctl> anything else? 13:32:05 <dirk> not from me 13:32:20 <toabctl> #topic pymod2pkg reviews 13:32:28 <toabctl> #link https://review.openstack.org/#/q/project:openstack/pymod2pkg+status:open 13:32:33 <toabctl> oh. there is nothing 13:32:46 <toabctl> #topic renderspec reviews 13:32:51 <toabctl> #link https://review.openstack.org/#/q/project:openstack/renderspec+status:open 13:33:31 * number80 has to go, it's raining 13:33:42 <toabctl> number80, for https://review.openstack.org/#/c/332265/, a test case would be good 13:33:51 <toabctl> ok. I'll add it as a comment 13:34:42 <toabctl> #topic open discussion 13:34:49 <toabctl> anything else to discuss? 13:35:22 <mivanov> yes, one question 13:35:40 <toabctl> go ahead 13:36:04 <mivanov> do i understand correctly, that we change "group:" to development/languages/python in all specs? 13:37:09 <toabctl> mivanov, I think that's what dirk proposed. isn't that working for you? 13:37:43 <mivanov> no, it's ok 13:38:06 <toabctl> ok. great 13:38:10 <mivanov> I just want to update it once, but not a dozen patches :) 13:38:16 <mivanov> thank you 13:39:05 <dirk> mivanov: the main requirement is for stupid reasons we need to have Group: in the main package still 13:39:11 <dirk> it is currently not consistent 13:40:05 <toabctl> so any last topic? 13:41:05 <toabctl> thanks everybody 13:41:07 <toabctl> #endmeeting