15:12:24 #startmeeting RDO packaging meeting (2015-04-15) 15:12:24 Meeting started Wed Apr 15 15:12:24 2015 UTC. The chair is apevec. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:12:24 Useful Commands: #action #agreed #halp #info #idea #link #topic. 15:12:34 #chair ryansb number80 rbowen 15:12:34 Current chairs: apevec number80 rbowen ryansb 15:12:39 #topic roll call 15:12:42 o/ 15:12:42 \o 15:12:46 /o\ 15:12:55 Here, but only watching with half an eye because I'm at a conference. 15:13:48 \o 15:14:43 #topic review https://trello.com/b/HhXlqdiu/rdo 15:15:01 CBS tags are done, number80 retagged existing builds 15:15:15 so we're clear to build kilo there 15:15:24 \o/ 15:16:21 looking at Apr17 list, I'll start from bottom: Delorean Kilo instance 15:16:50 I've forked https://github.com/apevec/rdoinfo-Kilo which locks source-branch: proposed/kilo for core projects 15:17:01 and Oslo on stable/juno (they already have it) 15:17:36 Delorean trunk already moved on, master branch is L-cycle after RC is created 15:17:44 so in http://trunk.rdoproject.org/centos70/latest-RDO-trunk-CI/ we have 2015.2 builds 15:18:21 I've started rebuilding 2015.1 rc1 in http://trunk.rdoproject.org/kilo/centos70/current/ 15:18:29 #info Delorean trunk moved to L-cycle (2015.2 builds) 15:18:41 #action apevec to finish RC1 rebuilds in http://trunk.rdoproject.org/kilo/centos70/current/ 15:19:06 #action apevec to ask weshay to create separate Kilo RC job 15:19:25 details? 15:19:33 only once that passes we can announce test day 15:19:49 one that does not use delorean? 15:19:54 weshay, TBD but basically just insert /kilo/ in repo url 15:20:09 weshay, it is delorean just separate instance locked on proposed/kilo branch 15:20:12 master moved on 15:20:24 see above 15:20:32 / (half here) 15:20:42 weshay, http://trunk.rdoproject.org/kilo/centos70/current/delorean-kilo.repo 15:21:14 weshay, but not complete yet, will let you know when it's ready 15:21:38 aye 15:21:55 rbowen, so for your half-eye: do not announce testday just yet, I'll ping you :) 15:22:05 ok, thanks for the heads up. 15:22:23 I will be available tomorrow for about half the day, and completely offline on Friday. Back in the office Monday. 15:22:57 ok 15:23:26 re. https://trello.com/c/qgKmFZkY/45-delorean-ci-job - job is green/blue now! 15:23:26 we have ipv6 in kilo packstack \o/ 15:23:39 awesome :) 15:23:47 and we even have kilo horizon now 15:24:02 social, nice! 15:24:27 missing is automatic prompotion (latest-CI symlink) which is work in progress 15:24:53 re. https://trello.com/c/wzdl1IlZ/52-juno-vs-kilo-in-fedora-22 15:25:16 that was back and forth, I tried to summarize latest thinking in https://www.redhat.com/archives/rdo-list/2015-April/msg00033.html 15:25:29 tl;dr leave Juno in F22 except Horizon due to django 1.8 15:25:29 Starting from F23 do not push openstack-* to stable Fedora keeping them in Rawhide and RDO only (details TBD) 15:25:33 what say you? 15:26:21 Note that I have no idea how to "not push openstack-* to stable Fedora" :) 15:26:34 hence TBD 15:27:00 does that include current releases ? (namely icehouse and juno ?) 15:27:49 up for discussion, but probably best to keep them until EOL upstream 15:27:54 esp. f21 icehouse 15:28:01 +1 15:28:11 f22 is not released yet, so maybe we could still kill it? 15:28:56 probably 15:29:06 or maybe not worth the trouble 15:29:13 number80, is there tentative f23 schedule? 15:29:37 nope, energy focused on releasing F22 now 15:30:05 upstream stable/juno releases should be discussed at summit session but if 15months stays, juno EOL would be in Jan 2016 15:30:50 https://wiki.openstack.org/wiki/Talk:StableBranchRelease 15:30:56 I all for dropping RDO from Fedora 15:31:25 jruzicka, did you mean droppping Fedora builds completely? 15:31:47 jruzicka, discussion is about openstack-* i.e. core packages 15:32:04 apevec, anything but clients, really. 15:32:10 yes, we proably want to keep oslo and clients 15:32:26 so that Fedora can use public openstack clouds 15:32:31 It's better to have nothing than b0rken something 15:32:32 maybe switch the core services to community-based effort 15:32:34 plus we save lots of time 15:32:42 I suspect that if we stop, we'll have people wanting to take over 15:33:01 we can move dist-gits to openstack-packages and be free from the Fedora dist-git processes, conventions and what not 15:33:20 we can focus our efforts on RDO repos, which *are* RDO 15:34:02 number80, not sure there are people wanting, assumption is that typical Fedora is a developer and wants latest release 15:34:30 jruzicka, re. fedora dist-git - I find it still valuable to pass Fedora review process 15:34:38 oh that... right. 15:34:45 what other dist-git processes are your concern? 15:35:00 yes, we just need to lay the foundations of allowing volunteers to continue packaging openstack on fedora 15:35:14 especially `fedpkg update` (bodhi) seems redundant in light of `rdopkg update` and friends 15:35:32 jruzicka, yes, that was main concern from ihrachyshka afaict 15:35:40 number80, so I'd like to keep everything in Rawhide i.e. master branch 15:35:56 number80, just not sure how do we prevent it to get into released Fedora? 15:36:15 Fedora releases everything in Rawhide right? 15:36:18 apevec: except retiring it when it's branched, there's no solution (could be automated) 15:36:21 yup, that's rather wierd 15:36:25 ugh 15:36:51 number80, but you can't retire branched release in pkgdb 15:37:07 only master which is where we want to keep it :) 15:37:16 yes, we just need to do it before alpha or beta 15:37:19 in that case, I'd consider moving to openstack-packages anyway 15:37:30 I still don't get why we want to stick to fedora 15:37:45 best practices from fedora - fine, no doubt about thta 15:38:06 legal aspects of having package in fedora 15:38:17 ihrachyshka: we would have to maintain more deps ourselves 15:38:28 we want to use fedora deps as before 15:38:42 as much in fedora/epel and as little in RDO as possible as of deps 15:38:42 number80, not sure. we can push deps into fedora, just not packaging actual services 15:39:17 jruzicka, not getting legal aspect actually. how is it different if we apply the same guidelines? 15:39:21 jruzicka, legal aspect should actually be good, Fedora pkg review shoudl clarify licensing and crypto 15:39:29 ihrachyshka, ^ 15:39:42 yes, I meant it as a reason to stick with fedora 15:39:55 ihrachyshka: +1 15:40:09 jruzicka, so how is it different if we apply the same legal/crypto guidelines on our own? 15:40:09 ihrachyshka, it's also more eyes in Fedora 15:40:11 but on workflow side and not-duplication-effort side, I'd run away 15:40:30 apevec, more eyes argument is moot. the only reviewers are actual openstack guys 15:40:35 ihrachyshka, we're smaller number of potential reviwers 15:40:50 Yeah but if something goes wrong we can blame Fedora ;) 15:40:58 ihrachyshka, there have been non-openstack devels reviewing python-* we need 15:41:10 we want to keep python-* in fedora anyway 15:41:12 and let's face it, if other reviewers would review our packages, they would complain about e.g. no unit tests run :) 15:41:28 jruzicka, python-* - no doubt about it 15:41:41 ie: python-requests (latest release in CentOS/RHEL has unfixed major CVE) 15:41:43 apevec, as I said, python-* story is different 15:42:20 unit tests in particular are problem on fedora due to missing deps. If we built them ourselves, we could attempt to enable them... 15:42:21 jruzicka, blaming won't fix the actual legal issue in case something arises 15:42:31 ihrachyshka, RHT legal still likes to see the link to Fedora pkg review bz 15:42:34 jruzicka, we SHOULD attempt it 15:42:56 ihrachyshka, I DID and it was hell of deps. I think that's the story all over 15:43:02 apevec, well... and then we ship e.g. python-ncclient in rhosp4 that was not ever proposed to fedora 15:43:31 jruzicka, apevec was able to package all the needed stuff for neutron though in his copr, so it's doable 15:43:36 ihrachyshka, yeah, but it's an exception (and not sure who approved it :) 15:43:51 Having our own dist-git gives us full control and allows import to Fedora if we reconsidered. 15:44:06 Not so easy the other way around as we can't even name fedora branches properly 15:44:11 just having 15:44:14 re. unit test - we'll put as a goal to enable %check everywhere 15:44:29 juno 15:44:30 kilo 15:44:31 apevec++ for that 15:44:35 branches 15:44:47 will make everything much easier 15:45:20 jruzicka, yeah, mapping is unclear, we'll need rpm-kilo in openstack-packages as soon as first incompatible L change arrives 15:45:21 (as opposed to f22, master, which change during time 15:45:35 I'm sticking to rpm-master for Kilo rebuilds for now 15:45:36 apevec, agreed 15:46:06 ok, so let me try to summarize again 15:46:10 +1 15:46:19 #info keep oslo and openstack clients in fedora 15:46:38 #info thinkg about retiring openstack-* completely in Fedora 15:47:23 apevec: You mean, Fedora 'proper' repos, right? 15:47:24 #info start using rpm- in openstack-packages as openstack-* dist-git for released versions 15:47:41 Just happened to notice this only message as I glanced at this channel. 15:47:42 kashyap, yes, Fedora dist-git, koji etc 15:48:06 apevec: You noted the rationale on the list, maybe you might want to add a URL here too. 15:48:20 apevec: But just wondering. . 15:48:23 I did post it earlier 15:48:24 related to that, rdoinfo needs some tweaking to contain per-release/dist package config. 15:48:54 jruzicka, why not rdoinfo branches? 15:49:02 f*ck no 15:49:05 apevec: When, some folks come ask "Hey, how come OpenStack packages are not in 'official' Fedora repos" -- at-least some kind of latest version. . . 15:49:06 :D 15:49:10 ihrachyshka, don't start him up :) 15:49:33 deal I have w/ jruzicka is to (ab)use and fork rdoinfo as a temp measure 15:49:40 ihrachyshka, rdoinfo is a global central information source, you don't fork it and you don't branch it.\ 15:49:41 I feel frustration flying in the air 15:50:08 it's the sound of someone thinking of ruining my well-though work :-p 15:50:48 temp measure indeed, noone want to live the hell of multiple rdoinfos, srsly. 15:51:29 ok, let's move on, we'll continue hashing out details on rdo-list 15:51:34 #topic RC1 import 15:52:03 we'll start that once I have Delorean Kilo RC rebuilds passing CI 15:52:25 first in Rawhide then we have CBS Kilo targets ready 15:53:08 number80, we'll need to split that somehow, but we can work that offline 15:53:15 I mean off meeting 15:53:17 apevec: +2 15:53:34 #topic test day: 15:53:40 we touched that already, 15:53:55 will be announced when RC passes CI 15:54:21 should be tomorrow, b/c proposed test day dates are Apr 21-22 15:54:52 #info hopefully announce tomorro RDO Kilo test day Apr 21-22 15:55:02 my action stays to provide instructions 15:55:09 that's it from agenda 15:55:14 #topic open floor 15:55:19 anything? 15:55:29 just a dissapointing information I didn't finish reqcheck yet :) 15:56:25 just don't tell anyone! 15:56:46 I've been trying to move stuff through rdo ci and comment on changes in lieu of proper voting 15:57:05 ping me directly if you have a change in that's not getting enough love. 15:57:06 eggmaster, is it voting now? 15:57:10 no 15:57:16 I am voting. 15:57:27 ok 15:57:29 eggmaster is THE voting. 15:58:22 number80, social - oh yes, how is puppet4 thing going? Will it be ready for test day or should we drop F22 from test matrix? 15:58:55 apevec: I fixed the issue reported by social, there's a new build in fedorapeople space 15:59:03 https://hguemar.fedorapeople.org/puppet4/ 15:59:14 #info new puppet4 build 15:59:21 social looks pretty tired after looking at your query :-p 15:59:25 number80, ok, but maybe better we announce only centos7 and f21 for the testday 16:00:06 social, it only 6pm, why tired :) 16:00:08 I still need ack from our puppet guys before pushing builds 16:00:22 number80, ok, sounds like c7 and f21 it is 16:00:49 ok, thanks everybody for coming and input! 16:00:52 #endmeeting