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