13:00:29 <dirk> #startmeeting rpm_packaging
13:00:30 <openstack> Meeting started Thu Sep  1 13:00:29 2016 UTC and is due to finish in 60 minutes.  The chair is dirk. Information about MeetBot at http://wiki.debian.org/MeetBot.
13:00:32 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
13:00:34 <openstack> The meeting name has been set to 'rpm_packaging'
13:00:37 <dirk> ping dirk toabctl IgorYozhikov number80 jruzicka
13:00:40 <IgorYozhikov> o/
13:00:45 <toabctl> hi
13:00:46 <number80> o/
13:00:47 <dirk> #chair IgorYozhikov toabctl
13:00:47 <openstack> Current chairs: IgorYozhikov dirk toabctl
13:00:52 <dirk> #chair IgorYozhikov toabctl number80
13:00:52 <openstack> Current chairs: IgorYozhikov dirk number80 toabctl
13:00:59 <dirk> #topic roll call
13:01:13 <dirk> everyone, please review/update agenda on
13:01:20 <dirk> #link https://etherpad.openstack.org/p/openstack-rpm-packaging
13:02:10 <jpena> o/
13:03:54 <itxaka> o/
13:05:03 <dirk> toabctl: did you want to add it for next meeting or for todays meeting?
13:05:11 <toabctl> oh. todays meeting
13:06:12 <toabctl> should we start?
13:06:21 <dirk> #topic Newton schedule update
13:06:31 <dirk> #link https://releases.openstack.org/newton/schedule.html
13:06:34 <dirk> as a reminder -
13:06:43 <dirk> this week (today) there is the upstream requirements freeze
13:06:53 <dirk> which means we can start looking more closely at matching the packaging for newton
13:07:04 <dirk> I know that from the sUSE side toabctl  and others are already working on that
13:07:26 <IgorYozhikov> dirk, are you about updating of reqs ?
13:07:26 <dirk> How does it look from Red Hat/Mirantis side?
13:07:33 <IgorYozhikov> according to last U-C?
13:07:51 <dirk> I've see lots of reviews from Javier and others
13:08:17 <dirk> IgorYozhikov: of possible we use UC, but there might be product specific issues with non-openstack components that require us to choose something else
13:08:28 <dirk> s,of possible,if possible,
13:08:46 <IgorYozhikov> i c
13:08:59 <number80> well, in pratice, oslo + clients should to stick to UC as nobody tests against master
13:09:22 <number80> for our downstream CD, we have both: full master and master + UC for clients/oslo
13:09:31 <IgorYozhikov> from mos side - we are trying to back-port new projects in case of necessity
13:10:15 <IgorYozhikov> our CI is using if you saw our packages + centos as dependencies
13:10:26 <IgorYozhikov> as in build as in tests
13:10:36 <IgorYozhikov> our CI doing 3 steps
13:10:50 <IgorYozhikov> build, publish and install
13:11:04 <dirk> Also, we intend to ship the rpm-packaging spec file results in the upcoming openSUSE Leap 42.2 release
13:11:13 <IgorYozhikov> so it test requirements everywhere
13:11:15 <dirk> I hope that they would end up also in other distributions releases
13:12:08 <IgorYozhikov> dirk, in our just started iteration we planned to reuse all what we have done in rpm-packaging
13:12:18 <number80> that's the long-term plan, but there's still a gap we need to bridge in renderspec (jruzicka is working on that)
13:12:37 <IgorYozhikov> during packaging rounf for Newton b2 we reused about 40% of prm-packaging
13:12:57 <IgorYozhikov> s/rounf/round/
13:13:18 <toabctl> I think we use ~90-95% if the specs currently.
13:13:26 <dirk> number80: I'd love to hear about the gaps though
13:13:37 <dirk> ok, 2nd topic I wanted to bring out
13:13:40 <dirk> bring up
13:13:54 <dirk> In two weeks, there is the Ocata cycle PTL self nomination period
13:13:57 <number80> dirk: one I think of is how to handle l10n, which requires some magic
13:14:02 <dirk> Please think about whether you want to be a candidate
13:14:17 <IgorYozhikov> falks, sorry bbs @10 min :(
13:14:18 <number80> ack
13:14:28 <dirk> and bring it up, here, in our channel or on the mailing list when the nomination period starts
13:16:15 <dirk> #topic feedback for renderspec improvals (see https://review.openstack.org/#/c/360919/ ) (toabctl)
13:16:22 <dirk> #link https://review.openstack.org/#/c/360919/
13:17:03 <dirk> toabctl?
13:17:06 <toabctl> I created recently a project called metaextract which gets the install_requires, tests_require and extras_require from a setup.py
13:17:39 <toabctl> with that we could start automating the Requires and BuildRequires sections. I created a POC which needs some more love but initial feedback would be very welcome!
13:19:38 <toabctl> I think there's not more to say about it currently.
13:19:46 <dirk> ok, thanks
13:19:53 <toabctl> but given the amount of specs we already have we need to automate more.
13:20:13 <dirk> yeah, I actually recently got a request on why we don't have openstack spec files yet
13:20:22 <dirk> people are looking for it but are confused on why we only have the clients
13:20:34 <dirk> next topic?
13:21:23 * IgorYozhikov back
13:21:36 <toabctl> yes. next
13:22:33 <dirk> #topic python3 renderspec
13:22:40 <dirk> #link https://etherpad.openstack.org/p/openstack-rpm-packaging-python3-renderspec
13:22:52 <dirk> IgorYozhikov?
13:23:28 * dirk didn't have time to read through the etherpad yet
13:23:28 <number80> I think Igor left for ten min
13:23:37 <IgorYozhikov> number80, I'm here
13:23:40 <IgorYozhikov> :)
13:23:42 <number80> great
13:24:07 <dirk> anything you want to say to it?
13:24:15 <IgorYozhikov> we where waiting for you dirk - to discuss this topic about using py3 for renderspec
13:24:23 <dirk> I see
13:24:35 <dirk> ok, I'll get to it and start a discussion on irc within this week
13:24:36 <dirk> ok?
13:24:55 <dirk> I'm only back since yesterday and there were a few things to take care of
13:25:09 <IgorYozhikov> yes, please read my thought.
13:25:25 <dirk> #topic Extend pymod2pkg to include mapping between PyPi module name and OpenStack project name
13:25:27 <IgorYozhikov> just want to understand - how we are going to work with py3
13:25:34 <dirk> #action dirk get back to IgorYozhikov on the python3 proposal
13:25:54 <dirk> jpena: are you around?
13:25:59 <jpena> yes, I'm here
13:26:03 <number80> I think we're lacking a proper rpm spec parser
13:26:18 <jpena> so currently pymod2pkg is providing mappings for PyPi project names fo suse/fedora packages
13:26:21 <number80> most of python3 boilerplate can be generated with few macros
13:26:40 <jpena> and in some cases, it would be nice to have a mapping between PyPi project/OpenStack project (it's not 1:1 all the time)
13:27:13 <jpena> I've been playing with a patch to add that mapping, but I wanted to check before
13:27:33 <jpena> is that something that matches the pymod2pkg purpose?
13:27:45 <number80> I guess, it could work (I see also benefit for downstream rdoinfo too)
13:28:13 <dirk> jpena: sound sgood to me
13:28:23 <dirk> jpena: should be okay to keep the exception list
13:28:33 <dirk> you need that for the URL:/Source: lines?
13:29:12 <dirk> is there a review already?
13:29:39 <jpena> dirk: I could use it for our DLRN implementation. That way, we could clone the github repo using that mapping, then use the Version: field to find the proper tag
13:29:47 <jpena> dirk: no, I'll upload the review after the meeting
13:30:06 <dirk> ok
13:30:07 <number80> jpena: add jruzicka as a reviewer, it may impact his tooling
13:30:11 <dirk> #action jpena  post review
13:30:12 <jpena> number80: ack
13:30:23 <dirk> #topic Including test directories in package
13:30:35 <jpena> that's also mine
13:31:22 <jpena> I've noticed we include the test directories for every repo in our packages. This is different to what we do in RDO (separate test packages), just wanted to know if it's on purpose
13:31:24 <dirk> so this is about splitting tests into -test subpackage or in the main package (or not at all)?
13:31:36 <jpena> dirk: exact
13:31:44 <dirk> I think I prefer an extra -test pacakge but I don't have a strong opinion
13:32:14 <number80> tests have a lot of deps, so +1 to split them out
13:32:25 <jpena> that would have an impact on some packages. For example, I've seen openstackclient requires tests from osc-lib
13:32:30 <number80> otherwise, I wouldn't care of keeping them
13:32:46 <jpena> I meant muranoclient
13:33:06 <IgorYozhikov> jpena, you are proposing to add extra foo-test.rpm which is going to do almost the same things like in %check section?
13:33:08 <number80> jpena: runtime stuff requiring test utils?
13:33:26 <number80> IgorYozhikov: nope, shipping test files in a separate subpackage
13:33:26 <jpena> number80: no, during build
13:34:01 <number80> jpena: we choose as a policy to run tests as much as possible at build time
13:34:07 <IgorYozhikov> might be more useful to make am example?
13:34:31 <jpena> IgorYozhikov, as an example, we have https://github.com/openstack/osc-lib/tree/master/osc_lib
13:34:45 <jpena> there is a tests/ directory inside the repo, which includes the test we run during %check
13:35:09 <jpena> they're only useful to us during build, but we package them because they get installed during %install
13:35:51 <jpena> however, during build, some packages require tests from other packages (muranoclient), so it'd be good to have a separate -tests subpackage for osc-lib, and have that as a BuildRequires
13:36:45 <IgorYozhikov> python-osc-lib - with py2 code
13:37:03 <IgorYozhikov> python-osc-lib-test - with py2 tests folder for osc-lib?
13:37:09 <jpena> exact
13:38:11 <itxaka> wait, so muranoclient requires the tests from osc-lib? its not enough with osc-lib package? That sounds wrong :/
13:38:11 <IgorYozhikov> and py*client will need BuildRequires: python-osc-lib-test ?
13:38:29 * IgorYozhikov confused
13:38:39 <jpena> IgorYozhikov, if they need to use tests from osc-lib, yes
13:39:18 <jpena> itxaka: https://github.com/openstack/python-muranoclient/blob/master/muranoclient/tests/unit/osc/v1/fakes.py#L14
13:39:31 <jpena> that's the example I've found (maybe there are more?)
13:40:09 <IgorYozhikov> from osc_lib.tests import utils
13:40:40 <jpena> from the OpenStack project point of view, they just require the PyPi package, and it includes everything. It might be easier for us to follow them, I just wanted to make sure it was a conscious choice
13:40:57 <IgorYozhikov> https://github.com/openstack/python-neutronclient/blob/cccc7f7fb0cecb585a8a250c11c22e2135838b47/neutronclient/tests/unit/osc/v2/trunk/test_network_trunk.py#L21
13:41:00 <IgorYozhikov> same here
13:41:16 <IgorYozhikov> jpena, more || les I've got your pint
13:41:54 <IgorYozhikov> but will extracted tests work without main lib code?
13:42:16 <itxaka> wow
13:42:16 <IgorYozhikov> just curious
13:42:26 <jpena> IgorYozhikov, no, for that the -test subpackage needs to Require: the main one
13:43:10 <IgorYozhikov> so why do we need to extract tests then ?
13:43:52 * dirk is back
13:43:53 <IgorYozhikov> just to create lightweight main python lib rpm package?
13:44:23 * IgorYozhikov trying to understand
13:44:28 <itxaka> but in this case the test dir is an integral test of the osc_lib package so we should not split it ever, even if that is super wrong
13:44:55 <jpena> that's why I asked :). We can think of it two ways: a) remove unnecessary code for installation (so split), b) tests are part of the code (so keep)
13:45:19 <jpena> I'm not 100% convinced on any of them
13:45:48 <toabctl> jpena, do we have currently a problem with the way it is?
13:45:50 <itxaka> What do we gain by splitting the packages? less BuildRequires?
13:46:29 <jpena> toabctl: not really, just if we dislike seeing the tests/ directory in the package
13:46:31 <toabctl> itxaka, yes. less possible dependency cycles
13:47:08 <dirk> one advantage you have of -test packages is that you can install them and then run the tests
13:47:13 <toabctl> jpena, I'm currently fine with having them in the packages. but I would also be fine if somebody is doing the work and split the packages.
13:47:15 <dirk> instead of having them run during build times
13:47:28 <number80> yes
13:47:28 <dirk> but it is a lot of painful work to keep that running, and getting patches for that upstream is difficult
13:47:42 <dirk> speaking from past experience
13:48:55 <jpena> ok, let's keep them for now, then split if we feel the need
13:49:08 <dirk> so can we summarize that we keep all the tests in python-$name package ?
13:49:10 <toabctl> just 10 min left. let's go to the next topic.
13:49:16 <toabctl> dirk, +1
13:49:23 <jpena> +1
13:49:25 <IgorYozhikov> +1 (¯―¯٥)
13:49:27 <itxaka> +1
13:49:29 <dirk> #agreed keep tests inside main package for now, revisit topic potentially later
13:49:41 <dirk> #topic Core reviewer additions (dirk)
13:50:11 <dirk> I was wondering whether we'd be interested in adding further core reviewers alongway, especially with the ocata cycle upcoming
13:50:27 <dirk> I already reached out to jpena  and aplanas, jpena said he'd be interested
13:50:32 <number80> dirk: I was thinking about increasing the pool post-GA too
13:50:40 <dirk> any comments/suggestions/opinions?
13:50:49 <toabctl> +1 for both.
13:50:52 <number80> I think both are good candidates
13:50:53 <itxaka> +1
13:50:59 <IgorYozhikov> dirk agree
13:51:20 <dirk> aplanas actually asked to not become core for now
13:51:21 <dirk> fwiw
13:51:21 <toabctl> they already do reviews and having more persons being able to add +2's would be good
13:51:44 <dirk> number80: so are you good with adding people now or do you want them only for ocata+ü
13:51:47 <dirk> ocata++
13:52:16 <number80> dirk: I'm fine with both
13:52:47 <number80> In aplanas case, I'd definitively revisit his case post-GA if he changes his mind by then
13:52:52 <dirk> so I suggest to create a mailing list posting on openstack-dev and I would invite the existing cores to +1/-1 that
13:53:01 <number80> ack
13:53:04 * dirk would start that
13:53:07 <IgorYozhikov> ++
13:53:17 <toabctl> +1
13:53:21 <dirk> #topic open floor
13:53:33 <dirk> #action dirk send mail about new core members to openstack-dev
13:53:46 <IgorYozhikov> dirk, what is your opinion about Barcelona
13:54:09 <IgorYozhikov> fishbowl || work-session
13:54:22 * toabctl will most likely not be in Barcelona
13:54:23 <IgorYozhikov> may be combined with deb
13:54:41 <number80> let's say work-session and fishbowl combined with deb folks
13:55:13 <IgorYozhikov> to discuss availability to do the same build "machine" using infra resources
13:55:41 <IgorYozhikov> as already done for deb with help of Paul Belanger
13:55:43 <dirk> ah, good point
13:56:07 <dirk> so there was a mail asking for input on barcelona sessions a few weeks ago, during my vacation
13:56:08 <IgorYozhikov> zigo, if u r here ^^^^
13:56:18 <dirk> I responded to that with the results of what we discussed in june
13:56:31 <dirk> I requested 1 fishbowl, possibly co-located with deb-packaging and two work sessions
13:56:35 <dirk> no contributor day session
13:56:51 <dirk> to summarize, barcelona is really crowded
13:57:19 <dirk> it is shorter and in order to remove overlap with other tracks the design tracks are just two days iirc
13:57:26 <IgorYozhikov> dirk, now or in future summit?
13:57:28 <dirk> and contributor day is only half a day
13:57:42 <IgorYozhikov> oh, got it
13:57:59 <dirk> IgorYozhikov: just talking about barcelona, I don't recall the future planning
13:58:08 <dirk> there was some discussion about it somewhere, but I forgot the details
13:58:35 <dirk> so to meet the deadline I submitted request for 1 fishbowl and two work sessions
13:58:44 <dirk> I haven't heard anything back yet
13:58:53 <IgorYozhikov> i c
13:58:59 <dirk> so we'll see. I think we're a small enough group so that we can gather somewhere else as well
13:59:03 <IgorYozhikov> thanx anyway
13:59:29 <dirk> IgorYozhikov: it should match what you suggested, except that its two work sessions
13:59:50 <dirk> I'd like to focus one on the upstream rpm packaging building effort and one at least on general topics
14:00:04 <dirk> anyway, we have to end this
14:00:21 <dirk> due to time constraints.. lets continue with the packaging reviews that I skipped in #openstack-rpm-packaging
14:00:26 <dirk> thanks, see you next week!
14:00:28 <dirk> #endmeeting