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