14:04:10 <dirk> #startmeeting RPM Packaging Weekly Meeting
14:04:11 <openstack> Meeting started Thu Feb 18 14:04:10 2016 UTC and is due to finish in 60 minutes.  The chair is dirk. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:04:12 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:04:14 <dirk> hey number80
14:04:15 <openstack> The meeting name has been set to 'rpm_packaging_weekly_meeting'
14:04:26 <dirk> do we have agenda items for today?
14:04:45 <IgorYozhikov> dirk: I think yes
14:04:51 <IgorYozhikov> according to etherpad
14:05:20 <number80> important ones I see
14:06:41 <dirk> anything missing?
14:07:19 <number80> IgorYozhikov just added the epoch topic so I'm good with the agenda
14:07:37 <number80> ah maybe it was you
14:08:05 <dirk> #topic toabctl: versions of proposed specs. looks like we are submitting older versions. What's our goal? Gettting packages for Mitaka?
14:08:43 <dirk> toabctl?
14:09:03 <dirk> I think the confusion is because we originally said we'd aim for finishing openstackclient with liberty release
14:09:05 <IgorYozhikov> dirk: I added previous versions because they could be tested against already built packages
14:09:06 <dirk> which didn't happen
14:09:09 <toabctl> ah. yes. I recognized that a lot of the proposed specs are using outdated versions.
14:09:17 <IgorYozhikov> 4 now I'm ok with Mitaka versions
14:09:39 <toabctl> and I created an overview for mitaka
14:09:41 <toabctl> #link http://toabctl.de/openstack/rpm-packaging-status.html
14:09:55 <dirk> any concerns objections from anyone to go with mitaka specs ?
14:09:57 <IgorYozhikov> & I've to update all my commits with corresponding to Mitaka SW versions
14:10:20 <toabctl> this shows our current versions and the versions fromhttps://github.com/openstack/releases/tree/master/deliverables/mitaka
14:10:49 <toabctl> IgorYozhikov: I justed wanted to discuss what we want for this cycle. and having something for mitaka would be cool imo :)
14:11:05 <dirk> ok, sounds like agreement, number80 ?
14:11:09 <IgorYozhikov> toabctl: agree
14:11:12 <number80> amen to Mitaka but it will be painful
14:11:23 <toabctl> number80: why?
14:11:38 <toabctl> number80: to early?
14:11:46 <IgorYozhikov> number80: pain due not stable code, reqs and spec
14:11:49 <IgorYozhikov> right?
14:11:49 <number80> considering delorean stats, we have packaging changes every week
14:11:53 <number80> IgorYozhikov: yes
14:12:21 <number80> but I agree that Mitaka should be our goal (so my formal +1)
14:12:35 <IgorYozhikov> o/ +1
14:12:49 <dirk> #agreed packaging spec files should aim mitaka release deliverable versions
14:13:09 <dirk> #topic created status page: http://toabctl.de/openstack/rpm-packaging-status.html
14:13:20 <toabctl> ah. well. I mentioned that already :)
14:13:28 <dirk> I think we mostly covered that already.. any questions about it?
14:13:39 <dirk> first of all of course thanks to toabctl  for generating it :)
14:13:48 <toabctl> if wanted, I can propose the code to rpm-packaging-tools.
14:13:57 <toabctl> it will be updated every 2 hours.
14:14:05 <number80> yes, that's very useful
14:14:30 <number80> that and IgorYozhikov spreadsheet will help to coordinate
14:15:01 <IgorYozhikov> I need to update my spreadsheet with current status :)
14:15:24 <dirk> toabctl: sounds like a good idea (proposing to packaging tools)
14:15:36 <toabctl> if I find time, I'll add a extra column with "currently in review"
14:15:41 <toabctl> ok. I'll do that
14:15:45 <IgorYozhikov> remind the link https://docs.google.com/spreadsheets/d/1d5j0UxkkAm2lfGtfbvcC3zszkLTqxv-PJ7US6AHxL-s/edit#gid=0
14:15:45 <dirk> I was having the crazy idea to publish it as docs from the rpm-packaging repo but thats for some other time..
14:16:03 <toabctl> #action toabctl proposes rpm-packaging-status.py to rpm-packaging-tools repo
14:16:13 <number80> https://docs.google.com/spreadsheets/d/1d5j0UxkkAm2lfGtfbvcC3zszkLTqxv-PJ7US6AHxL-s/edit#gid=0
14:16:25 <number80> (just add the link in meetbot logs)
14:16:51 <toabctl> here are the meetbot commands: https://wiki.debian.org/MeetBot
14:17:25 <dirk> #link https://docs.google.com/spreadsheets/d/1d5j0UxkkAm2lfGtfbvcC3zszkLTqxv-PJ7US6AHxL-s/edit#gid=0
14:17:33 <dirk> #topic move agenda/minutes links to wiki?
14:17:42 <dirk> imho yes for minutes
14:18:20 <toabctl> so currently we are using the etherpad but other projects use the wiki. and with the wiki we have history and nobody can just delete content without haveing a "backup"
14:18:38 <IgorYozhikov> just to use the same approach as the rest of OS projects - agree
14:18:45 <toabctl> so I like the etherpad because it's simple to add things but having history is imo important
14:19:21 <number80> yyes
14:19:39 <IgorYozhikov> toabctl: + visibility for community members who are use to use OS wiki
14:19:58 <toabctl> so what about using https://wiki.openstack.org/wiki/Rpm-packaging/Meetings ?
14:20:08 <toabctl> IgorYozhikov: yes
14:20:18 <dirk> toabctl: can do.. I"ll take a look how other projects do this
14:20:39 <toabctl> dirk: so you don't want to use it for the agenda? just for minutes?
14:21:53 <dirk> well I definitely agree that wiki makes sense to clean up our slightly messy etherpad
14:22:10 <dirk> so I'd use it to put the links on the meeting logs and action items
14:22:34 <dirk> regarding agenda collection - which often happens ad hoc, I'd find the etherpad simpler
14:22:40 <dirk> but I don't have a strong opinion either way
14:22:46 <toabctl> ok. also fine for me.
14:22:54 <dirk> I agree that we've been slacking a bit on this and moving to wiki has advantages
14:23:06 <toabctl> let's start with using it for general info (meeting time, ...) and colection minutes and AIs
14:23:24 <toabctl> s/collection/collecting/
14:24:20 <dirk> sounds good to me
14:24:22 <IgorYozhikov> AIs -> tracking progress | issues
14:24:26 <IgorYozhikov> good
14:24:27 <dirk> any concerns, objections?
14:25:56 <dirk> #agreed AI and meeting logs move to wiki page https://wiki.openstack.org/wiki/Rpm-packaging/Meetings
14:26:25 <dirk> #topic move meeting to official meeting place: https://review.openstack.org/#/c/279950/
14:26:45 <dirk> first of all, adding it to the meeting ical is a good idea, thanks
14:27:03 <dirk> the slight downside is that the meeting rooms are booked at our usual meeting time
14:27:11 <dirk> so we'd have to move to a different week day or different time
14:27:16 <toabctl> and you can't add our room as meeting room
14:27:18 <dirk> different time would be one hour earlier on thursdays
14:27:38 <dirk> different day would also be possible, e.g. fridays same time works for me , or an hour later
14:27:53 <dirk> so I guess there are two things to this
14:28:02 <dirk> a) moving to one of the official meeting rooms for the meeting
14:28:13 <dirk> and b) if we do so, adjust to the different scheduling
14:28:31 <dirk> what do you think?
14:28:37 <toabctl> so the current proposal would be Thursday, 1 pm UTC
14:28:45 <toabctl> in #openstack-meeting-alt
14:28:51 <number80> not a big change
14:28:58 <number80> +1
14:28:59 <IgorYozhikov> most of projects using os meeteng | meeting-alt
14:29:03 <toabctl> +1
14:29:11 <number80> visibility is important
14:29:15 <IgorYozhikov> yep +1
14:29:29 <toabctl> so I proposed the change already: https://review.openstack.org/#/c/279950/3 (with workflow -1 to first discuss it here)
14:29:43 <dirk> number80: IgorYozhikov :, ok then please +1 the review
14:29:53 <toabctl> and I'll remove the workflow-1
14:29:55 <dirk> #agreed meeting will move an hour earlier and to openstack-meeting-alt
14:29:59 <IgorYozhikov> a lot of dev folks attends meetings at os meeting | meeting-alt
14:30:56 <IgorYozhikov> dirk: done
14:30:59 <dirk> moving an hour earlier might even makethe meeting attendable for kun_huang  I guess
14:31:03 <dirk> thanks
14:31:20 <dirk> #topic handling of Epoch versions
14:31:32 <dirk> and now the fun topic :)
14:31:36 <number80> tough one
14:31:42 <toabctl> :)
14:31:54 <number80> I think we need to have some kind of database to store such things
14:32:02 <number80> handling that in spec will be hell
14:32:08 <IgorYozhikov> yes, I want to be clear here too
14:32:11 <dirk> I am wondering if we ever manage to agree to one epoch version accross all distros
14:32:33 <number80> dirk: considering fedora experience, impossible
14:32:41 <dirk> if we can, then it would be rather simple - we add a filter that removes the epochs for suse and all others stay on a common epoch
14:32:53 <IgorYozhikov> dirk: it might be ok in case of installation from scratch
14:33:02 <IgorYozhikov> without update from previous version
14:33:27 <toabctl> number80: with database, you mean a db per distro?
14:33:28 <IgorYozhikov> if we are speaking only about OS related packages
14:33:44 <dirk> yeah, well suse's distro upgrade allows version downgrades :)
14:33:48 <apevec> this is about https://review.openstack.org/281196 ?
14:33:59 <toabctl> hi apevec
14:34:00 <apevec> dirk, so suse always has Epoch: 0 ?
14:34:14 <dirk> apevec: sort of, yes, sorry for not summarizing
14:34:19 <dirk> we discussed that over the last few days already
14:34:22 <apevec> what do you do in case of upstream changing versioning
14:34:25 <dirk> let me summarize a bit
14:34:30 <apevec> yes please
14:34:43 <dirk> suse currently has the (imho slightly stupid) policy of not allowing epochs in distro packages
14:35:06 <dirk> which means epoch: fields will be stripped during checkin process from the spec file. so with other words it is always epoch 0
14:35:25 <dirk> a switch of the code stream (distro upgrade) allows version downgrades, so it is not a major issue for us
14:35:37 <dirk> within a maintained products no epochs and no version downgrades are allowed
14:36:03 <dirk> so in case when upstream breaks versioning, we either delay the upgrade to the next release (where downgrade is allowed) or we invent a fake version number (very rarely)
14:36:49 <dirk> in the openstack case, the version change to semver was not an issue since it came aligned with a product switch
14:36:56 <dirk> so we just accept the downgrade and don't worrry about it
14:37:14 <dirk> and going forward in theory this will not ever happen anymore (famous last words..)
14:37:36 <dirk> it seems both rhel and mirantis have introduced epochs to handle upgrades due to the semver change
14:37:50 <IgorYozhikov> dirk: yes
14:38:17 <dirk> number80: so we'd need a distro specific yaml that renderspec has to read and add to the spec file ?
14:38:28 <dirk> and we annotate version numbers with a filter that introduces the epochs?
14:38:34 <IgorYozhikov> you are right here - epoch used to handle upgrade-ability
14:38:46 <dirk> because there are two aspecits. the epoch: field in the .spec file and the epoch specifiers in dependencies
14:38:59 <dirk> e.g. requires: foo >= epoch:version-release
14:39:11 <toabctl> dirk: having a per-distro yaml with key-values (package name -> epoch) could be enough I guess. and then using that in renderspec
14:39:18 <dirk> we'd have to do something like
14:39:21 <number80> dirk: yes
14:39:24 <IgorYozhikov> ic - so we need to handle this in renderspec
14:39:55 <dirk> well, unless we agree to not use epochs
14:39:58 <dirk> :-)
14:39:59 <IgorYozhikov> by cutting off epoch from reqs versions
14:40:05 <toabctl> well - we need the key/value store per disto and that needs to be in rpm-packaging imo. this will change with new releases
14:40:18 <dirk> its not only cutting off, but also adding the epochs to the deps
14:40:19 <number80> dirk: I wouldn't be against it but reality wants us to have them around :(
14:41:07 <IgorYozhikov> dirk: 4 example - Requires: {{ 'oslo.config' | py2pkg }} >= 2:3.4.0
14:41:36 <IgorYozhikov> for SUSE - Requires: {{ 'oslo.config' | py2pkg }} >= 0:3.4.0
14:41:37 <dirk> right
14:41:39 <IgorYozhikov> nope?
14:41:44 <dirk> yes
14:42:01 <toabctl> would be more like Requires: {{ 'oslo.config' | py2pkg }} >= {{ 3.4.0|epoch }}
14:42:05 <IgorYozhikov> so, suggesting to add filter for that
14:42:08 <dirk> but when I understood number80  correctly it is not "2" everywhere but the "2" depends on the distro
14:42:24 <dirk> toabctl: doesn't work
14:42:25 <toabctl> and epoch looks what distro you want to render and scans the file with the packagename->epoch mapping
14:42:29 <toabctl> dirk: why?
14:42:29 <dirk> toabctl: epoch filter needs to know the package name
14:42:37 <toabctl> dirk: ah. right
14:42:55 <IgorYozhikov> {{ 'oslo.config' | py2pkg }} >= {{ 2 | epoch }}:3.4.0
14:43:09 <dirk> so you'd have to do something like {{ 3.4.0|epoch('oslo.config') }}
14:43:18 <toabctl> then maybe another filter with 2 params, pkgname and version.
14:43:27 <IgorYozhikov> with current implementation might work
14:43:29 <dirk> which makes it fsckingly ugly
14:43:44 <apevec> yeah that's too ugly
14:43:46 <dirk> IgorYozhikov: well, are you saying we can agree on a common epch?
14:43:59 <number80> or having a smarter filter
14:44:04 <toabctl> number80: yes
14:44:22 <IgorYozhikov> smart filter requires DB
14:44:31 <number80> IgorYozhikov: exactly
14:44:39 <IgorYozhikov> agree on smart filter
14:44:43 <dirk> yaml is the openstack db ;-)
14:44:52 <number80> yaml is fine with me :)
14:44:57 <IgorYozhikov> +1
14:45:13 <dirk> number80: but is it really going to be package specific?
14:45:19 <dirk> number80: or can we do something like
14:45:22 <IgorYozhikov> we need to elaborate data format
14:45:44 <dirk> {{ "3.4.0" | epoch("oslo_version_break_2015.1") }}
14:45:47 <number80> dirk: it could be global
14:46:03 <dirk> and then oslo_version_break_2015.1 is mapped to epoch 2 for rhel, and 3 for mirantis (as an example)
14:46:10 <number80> jruzicka has experience in such databases, so I'd have him helping us
14:46:25 <dirk> so the lookup key is not the package name, but some identifier that we agree on..
14:46:59 <dirk> we could also make it then
14:47:24 <number80> *nods*
14:47:29 <dirk> {{ "oslo2015:3.4.0" | epochfilter }}
14:47:45 <dirk> and then oslo2015: would be replaced by 2: for one distro and "" for suse
14:47:56 <toabctl> hm. that looks ugly
14:49:01 <dirk> is
14:49:02 <IgorYozhikov> may be use current OS release - like oslo:mitaka:3.4.0
14:49:26 <IgorYozhikov> may be use current OS release - like oslo.config:mitaka:3.4.0
14:49:29 <dirk> {{ "oslo:3.4.0" | evr }} better ?
14:50:10 <IgorYozhikov> oslo - to common name, how filter will know what exactly should be processed
14:50:35 <toabctl> what about {{ oslo.messagging|myfilter('3.4.0') }}
14:50:35 <dirk> well, the idea is that you'd use a common epoch version for all "oslo" packages
14:50:55 <toabctl> and then the filter handles the epoch and pypkg naming conversion foo
14:50:56 <IgorYozhikov> even when it is not necessary?
14:51:03 <dirk> IgorYozhikov: yes
14:51:53 <IgorYozhikov> not sure that add epoch to whole oslo namespace is a good idea...I need to think more on this
14:52:01 <toabctl> dirk: what's the advantage? not having a "big" db file?
14:52:04 <dirk> toabctl: it looks a bit redundant to me, since we'll have oslo.messaging mentioned before already
14:52:28 <toabctl> dirk: my idea is to give the filter just another argument (the version)
14:53:13 <dirk> toabctl: I understand, but the complete line will look lik ethis in your example
14:53:20 <IgorYozhikov> can we connect two filters? 1 with name - second with epoch
14:53:51 <dirk> Requires: {{ "oslo.messaging" | py2pkg }} >= {{ "oslo.messagging" |myfilter('3.4.0') }}
14:53:56 <number80> I think we need a PoC first so we could discuss on a better basis
14:54:01 <toabctl> dirk: more like : BuildRequires: {{ 'oslotest' | py2pkg('1.10.0', '>=') }}
14:54:30 <toabctl> number80: +1
14:54:31 <IgorYozhikov> toabctl: this one could work
14:54:37 <IgorYozhikov> number80: +1
14:54:44 <IgorYozhikov> PoC
14:55:02 <dirk> who takes the action item?
14:55:15 <toabctl> I'm interessted but not sure if I can do that before next week
14:55:36 <toabctl> with next week I mean before our next meeting :)
14:55:47 <dirk> I think we have a week, we have plenty of specfiles to review/merge before epochs become a major obstacle
14:55:58 <toabctl> yeah
14:56:10 <IgorYozhikov> toabctl: who is knows python may be
14:56:22 <number80> *nods*
14:56:34 <dirk> toabctl: ok, slightly less ugly than what I understood, thanks for the explanation
14:57:22 <dirk> ideally I'd have something like BuildRequires: {{ buildrequires[i] }} and that just expands automatically to the right thing (maybe from a separate yaml file)
14:57:27 <dirk> anyway, we agree to postpone
14:57:46 <dirk> #agreed decision postponed until a better PoC is available that covers all aspects
14:57:59 <dirk> #action toabctl  come up with prototype
14:58:18 <dirk> ok, that wasn't so painful, thanks a lot for the engagement!
14:58:32 <dirk> I'm fairly happy with the progress on the reviews lately, keep rocking!
14:58:49 <toabctl> +1
14:58:50 <IgorYozhikov> dirk: let's do some CR 4 now?
14:58:51 <dirk> any last words? otherwise one hour earlier next week in openstack-meeting-alt!
14:59:14 <dirk> IgorYozhikov: I have to jump on something else at the top of the hour I"m sorry. but I'll check out the current state later today
14:59:20 <number80> btw, I won't be around next week due to personal matters
14:59:26 <dirk> IgorYozhikov: I sent another PR this morning that should unblock others
14:59:40 <IgorYozhikov> https://review.openstack.org/#/c/281792/?
14:59:49 <dirk> IgorYozhikov: feel free to ping me on irc on anzthing that needs my review/merge
14:59:59 <IgorYozhikov> dirk: sure
15:00:27 <IgorYozhikov> https://review.openstack.org/#/c/270795/ - this one you mentioned earlier
15:00:35 <dirk> IgorYozhikov: ah, good point. did we agree to list versions on buildrequires? we didn"t do that so far Iirc
15:01:23 <IgorYozhikov> dirk: yes, lower caps usage
15:03:26 <dirk> IgorYozhikov: fixed the review
15:03:35 <IgorYozhikov> dirk, toabctl - will recheck-suse helps with CI became green?
15:04:11 <toabctl> IgorYozhikov: it should at least retrigger a build. but we currently have only one worker so that's maybe a bit slow...
15:04:18 <dirk> IgorYozhikov: yes.
15:04:34 <dirk> IgorYozhikov: its just that the build times are a bit slow right now.. will look into that (needs assistance from a colleague)
15:04:41 <IgorYozhikov> ok, going to retrigger oslo.context
15:05:01 <dirk> currently the SUSE CI thing is not really voting yet (probably something we should change at some point)
15:05:12 <dirk> anyway
15:05:14 <dirk> #endmeeting