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