13:01:47 <dirk> #startmeeting rpm_packaging
13:01:48 <openstack> Meeting started Thu Feb 25 13:01:47 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:49 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
13:01:51 <openstack> The meeting name has been set to 'rpm_packaging'
13:02:07 <IgorYozhikov> hi
13:02:23 <dirk> everyone, please add your agenda items to https://etherpad.openstack.org/p/openstack-rpm-packaging
13:02:27 <mivanov> hi
13:05:33 <dirk> done with topics? can we start?
13:07:01 <dirk> #topic Mitaka Bugsquash event
13:07:45 <dirk> There is an OpenStack Foundation managed Bug Squash event world wide happening in various locations March 7th-9th
13:07:46 <dirk> https://etherpad.openstack.org/p/OpenStack-Bug-Smash-Mitaka
13:08:07 <dirk> in one of the previous meetings we've been pondering about doing a rpm packaging hackathon during that time
13:08:38 <dirk> just wanted to remind you again, feel free to join our irc channel (#openstack-rpm-packaging) during that time and/or meet us in person
13:09:11 <dirk> there is one meetup in Nuernberg Germany at the SUSE headquarters hosted where some of us will participate
13:09:29 <dirk> but in any case lets meet on irc and get more spec files / reviews done
13:09:54 <dirk> #link https://etherpad.openstack.org/p/OpenStack-Bug-Smash-Mitaka
13:10:18 <dirk> #link etherpad.openstack.org/p/openstack-rpm-packaging
13:10:19 <IgorYozhikov> dirk: according to doc any interested people in Moscow could join us too in Mirantis office
13:10:31 <dirk> IgorYozhikov: nice!
13:10:48 <dirk> well, it is hard to beat moscow of course :-)
13:12:11 <dirk> IgorYozhikov: will you set aside some time for rpm-packaging during that time?
13:12:13 <IgorYozhikov> should we try to review | merge as much as possible and with good quality during this event?
13:12:50 <IgorYozhikov> Yes, I could be on irc and participate in public activities
13:12:53 <toabctl> +1 (but I also need some time for manila so I can participate the whole time)
13:13:54 <IgorYozhikov> looks like we need some kind of to-do :)
13:14:15 <dirk> isn't http://www.toabctl.de/openstack/rpm-packaging-status.html the todo? :)
13:14:18 <dirk> or your spreadsheet
13:14:24 <IgorYozhikov> or just will keep going through the list ^^^
13:14:28 <IgorYozhikov> yes :)
13:14:59 <dirk> #topic specify versions for BuildRequires ?
13:15:06 <dirk> toabctl?
13:15:39 <toabctl> I was wondering if we want to specify the versions for BuildRequires . afaik some of our specs do, others don't
13:15:52 <toabctl> so what's our prefered way to handle this?
13:15:53 <IgorYozhikov> to be frank, I prefer to use lower bounds
13:16:30 <dirk> I personally don't really care, I'd be fine without versioned requires on buildrequires
13:16:49 <IgorYozhikov> just to be closer to versions used as for testing as for build and mentioned in corresponding requirements.txt
13:18:00 <IgorYozhikov> dirk: I'm agree here only with one exception, we have already pre-built dependencies with required versions
13:18:16 <dirk> main downside of that is that it serializes the order in which we can merge spec files quite drastically
13:18:40 <dirk> since upstream is doing version bumps everywhere, and then very quickly packages become unbuildable if not updated in the right order
13:19:05 <dirk> maybe that is not a big concern though, but in some cases while the version was bumped you can still build against older versions, so that allows some flexibility
13:20:35 <IgorYozhikov> yes - it is easier, but how to be with same projects which are present in both sections as in BuildRequires as in Requires + version?
13:21:18 <dirk> hmm, okay
13:21:30 <IgorYozhikov> for example - in Mirantis we can't merge spec without successful installation test
13:21:57 <toabctl> we still need such a test for reviews and gating ...
13:22:16 <dirk> yeah, but thats just a few lines of code with the OBS CI job
13:22:26 <IgorYozhikov> toabctl: I'm working on similar stuff
13:22:30 <dirk> (once the bottlenecks with it are solved)
13:22:49 <toabctl> IgorYozhikov: working on CI?
13:22:51 <IgorYozhikov> already made proposal to our infra team, will clarify ETA
13:22:57 <dirk> ok, so we agree to list versions both on buildrequires and requires?
13:23:20 <toabctl> fine for me.
13:24:01 <dirk> #agreed also list versioned dependencies for BuildRequires
13:24:15 <dirk> I think we need to document that on the wiki for some reviewing guidelines
13:24:29 <IgorYozhikov> dirk: yes
13:24:31 <toabctl> +1 for documenting it
13:24:31 <dirk> technically I was thinking about a pep8 tool for our spec files but that is maybe a bit too much work right now
13:24:56 <dirk> any volunteer for startign such a wiki page? it doesn't have to be perfect, but it would be good to document our best practices for new contributors and reviewers
13:25:25 <IgorYozhikov> dirk, toabctl - also need to add about calls for test & docs
13:25:52 <IgorYozhikov> dirk: I will do
13:26:47 <dirk> whats the wiki url? wiki.openstack.org/rpm-packaging/ReviewGuidelines ?
13:26:49 <dirk> perhaps ?
13:27:21 <toabctl> I can create the wiki page
13:27:28 <dirk> #action IgorYozhikov  document existing review guidelines under  wiki.openstack.org/rpm-packaging/ReviewGuidelines
13:27:33 <toabctl> oh. sorry. forgot to scroll down
13:27:39 <toabctl> IgorYozhikov: please go ahead.
13:27:44 <dirk> thanks Igor!
13:27:44 <toabctl> didn't read the answer :)
13:27:55 <dirk> to everyone else, please help/review the changes
13:28:02 <IgorYozhikov> toabctl: ok
13:28:08 <dirk> #topic what files in %doc: AUTHORS ChangeLog CONTRIBUTING.rst HACKING.rst LICENSE README.rst ?
13:28:14 <dirk> again a topic from toabctl :)
13:28:27 <toabctl> also something to document I guess. What files do we want to have there?
13:29:00 <toabctl> imo no LICENSE (because that's under %license) but I'm for AUTHORS, ChangeLog and README
13:29:17 <toabctl> I think CONTRIBUTING.rst and HACKING isn't really needed
13:29:40 <dirk> yeah, I would leave out HACKING* at least
13:29:47 <dirk> I"m undecided about AUTHORS
13:29:58 <dirk> works foe me.
13:30:20 <toabctl> well - AUTHORS is not really documentation. so we can leave that out, too
13:30:57 <dirk> any concerns, thoughts, objections?
13:31:03 <IgorYozhikov> -HACKING, yes
13:34:03 <dirk> #agreed do not add HACKING* and CONTRIBUTING* to %doc
13:34:17 <dirk> #agreed do not add HACKING* and CONTRIBUTING* and AUTHORS to %doc
13:34:31 <dirk> I think we agreed to the 2nd one :)
13:34:39 <toabctl> :)
13:36:08 <dirk> #topic renderspec epoch handling  - comments? (see https://review.openstack.org/#/c/283744/ )
13:37:05 <toabctl> I added support for epochs to renderspec . are there any comments? should something change there?
13:37:09 <dirk> first of all, thanks to toabctl  for writing tons of tests and working out a proposal
13:37:46 <toabctl> I would like to get this merged soon (or chanage it) so we can use the new style template mechanism to support epochs
13:37:53 <dirk> I haven't checked it out in detail, where/how would we add the epoch yaml files?
13:38:13 <dirk> would they be a separate file, e.g. %distro-epochs.yaml alongside the spec.j2 ?
13:38:21 <dirk> how does it hande the case that the file doesn't exist?
13:38:22 <IgorYozhikov> As I already said - 2nd variant looks easier
13:38:23 <toabctl> dirk: that's a good question. I asked number80 about it but got no response
13:38:46 <IgorYozhikov> and yes - yamls - where they will resides?
13:38:51 <toabctl> if the file doesn't exist, epochs are currently just ignored
13:39:56 <toabctl> my current feeling is that we should store the $distro-epochs.yaml in the rpm-packaging repo
13:40:09 <toabctl> IgorYozhikov: why easier?
13:40:44 <IgorYozhikov> one function with params
13:41:11 <toabctl> IgorYozhikov: 2nd variant == {{ py2pkg('oslo.config', ('>=', '3.0.0')) }}  ?
13:41:22 <IgorYozhikov> filter -> function 1,2,3
13:41:23 <IgorYozhikov> yes
13:41:35 <toabctl> ok. I guess then we all agree about that.
13:41:48 <dirk> +1
13:41:56 <IgorYozhikov> ++
13:42:18 <dirk> I also think the yamls should be just submitted into the git repo alongside the spec.j2 files
13:42:31 <dirk> e.g. the renderspec tool should search for them in the given directory where the spec.j2 resides by default
13:42:50 <toabctl> dirk: so you want to have a epoch db per spec.j2  ?
13:42:59 <IgorYozhikov> Just to be clear, it will handle the old format normally, right?
13:43:12 <toabctl> IgorYozhikov: yes. we can slowly migrate to the new format
13:43:19 <dirk> IgorYozhikov: old sformat is still supposed
13:43:33 <dirk> toabctl: ah, you mean it should be in a common directory?
13:43:34 <IgorYozhikov> dirk, toabctl - thanx
13:43:45 <toabctl> dirk: yes. a single db per distro.
13:44:03 <toabctl> dirk: I don't see a reason why we need to duplicate that information
13:44:19 <IgorYozhikov> I've got feeling that yaml will resides near spec.j2
13:44:21 <dirk> so storing in the parent directory?
13:44:45 <IgorYozhikov> but this is not good
13:44:50 <toabctl> dirk: maybe just in rpm-packaging/epochs/fedora-epochs.yaml
13:45:30 <dirk> works for me as well
13:45:31 <IgorYozhikov> common storage, yes. And it should target current OS release
13:45:45 <dirk> I guess we need to discuss this when number80 is back from PTO
13:45:51 <toabctl> m. yes
13:46:11 <dirk> I was anyway thinking that we should add some magic to fetch the proper version numbers from the glocal requirements repo
13:46:29 <dirk> and stop listing them explitely in the spec.j2 template. it would be substituted automatically
13:46:36 <dirk> so the epoch would be similar in that regard
13:46:49 <toabctl> dirk: we can add that later I guess
13:46:53 <dirk> ok, so in generall we agree that this is looking good, we need to finalize the epoch stuff with number80 ?
13:46:57 <dirk> can we agree to that?
13:47:01 <toabctl> +1
13:47:31 <IgorYozhikov> dirk: we already have tool for GR parsing against specs
13:47:54 <IgorYozhikov> mivanov: could you post link?
13:48:08 <dirk> #agreed proposal for py2pkg change in renderspec (see https://review.openstack.org/#/c/283744/ ) looks good, we need to finalize epoch discussion with Red Hat
13:48:17 <dirk> IgorYozhikov: cool.. can we integrate it somehow?
13:48:36 <IgorYozhikov> maybe, mivanov - is one of the authors
13:51:06 <dirk> we should take a look at that
13:51:12 <dirk> mivanov: around?
13:51:51 <mivanov> yes, i'm here
13:52:52 <mivanov> i'm just searching in my repos :)
13:53:04 <IgorYozhikov> mivanov: can you record a small demo and post the link here
13:53:20 <dirk> ok, cool, I'd suggest to continue the discussion in #openstack-rpm-packaging since we have a hard stop here for the next meeting
13:53:24 <dirk> any last topic ?
13:53:39 <toabctl> just the usual "please do reviews" :)
13:53:57 <toabctl> afaics we need next oslo.serialization which is https://review.openstack.org/#/c/284700/
13:54:10 <dirk> yes, good point
13:54:13 <toabctl> this hopefully unblocks oslo.concurrency
13:54:23 <dirk> I realized as well that oslo.serialization blocks everything
13:54:37 <dirk> so please review https://review.openstack.org/#/c/284700/
13:57:08 <dirk> ok, meet everyone in  #openstack-rpm-packaging
13:57:13 <IgorYozhikov> I'm fine with CR, reqs are up to date
13:57:19 <dirk> thanks! next meeting next week same place same time :)
13:57:22 <dirk> #endmeeting