15:03:16 <apevec> #startmeeting RDO packaging meeting (2015-06-03)
15:03:17 <zodbot> Meeting started Wed Jun  3 15:03:16 2015 UTC.  The chair is apevec. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:03:17 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:03:29 <apevec> #chair gchamoul number80 rbowen jpena
15:03:29 <zodbot> Current chairs: apevec gchamoul jpena number80 rbowen
15:03:36 <apevec> #topic roll call
15:03:42 <apevec> \o
15:03:48 <eggmaster> \o
15:03:53 <jpena> o/
15:03:54 <number80> o/
15:04:03 <jruzicka> o/
15:04:04 <gchamoul> o/
15:04:46 <jschlueter> o/
15:04:54 <number80> rbowen won't join us as he is having a company call right now
15:04:56 <ryansb> \o
15:05:09 <mburned> o/
15:05:27 <apevec> ok
15:05:44 <apevec> agenda is at https://etherpad.openstack.org/p/RDO-Packaging
15:05:55 <apevec> currently only one topic:
15:06:04 <apevec> #topic Post Kilo retrospective https://trello.com/c/oGSEYj8J/53-post-kilo-retrospective
15:06:30 <apevec> thanks everybody who added their inputs in https://trello.com/c/oGSEYj8J/53-post-kilo-retrospective
15:06:55 <apevec> looks like common theme is better planning :)
15:07:09 <apevec> #info we need better planing
15:07:24 <chandankumar> o/
15:07:55 <number80> #chair chandankumar
15:07:55 <zodbot> Current chairs: apevec chandankumar gchamoul jpena number80 rbowen
15:08:06 <apevec> Delorean should help us detected new deps but package review process should start at the same time when new package is added to rdoinfo
15:08:23 <number80> +1
15:08:33 <apevec> #action apevec to expand master packaging add-new-package procedure
15:08:43 <apevec> currently it is:
15:09:05 <apevec> https://www.rdoproject.org/packaging/rdo-packaging.html#_how_to_add_a_new_package_to_rdo_master_packaging
15:09:37 <apevec> related isssue is how to maintain maintainers
15:09:48 <jruzicka> metamaintainers!
15:09:49 <apevec> separate pkgdb2 instance was suggested
15:09:49 <number80> yes, we need more input from them
15:09:52 * jruzicka ducks
15:10:42 <gchamoul> +1
15:10:42 <apevec> number80, jruzicka - what do you think about my suggestion to add status flag to rdoinfo?
15:11:09 <apevec> it's another (mis)use of rdoinfo, polluting jruzicka's clean design :)
15:11:11 <number80> apevec: it'll help
15:11:30 <apevec> rdoinfo currently drives Delorean directly
15:11:31 <number80> we could even leverage this on board-like web page
15:11:46 <apevec> with status flags we could create subsets
15:12:07 <apevec> BTW we also have ownership info in CBS Koji and Fedora Koji
15:12:19 <apevec> Fedora Koji is synced with Fedora pkgdb?
15:12:30 <jruzicka> I think I need to map the current workflow
15:12:31 <number80> apevec: yes,
15:12:34 <jruzicka> create diagram
15:12:44 <jruzicka> see what's happening, what's the structure of everything
15:12:49 <jruzicka> collect missing features
15:12:57 <number80> jruzicka: +1
15:13:08 <jruzicka> and redesign rdoinfo in as backward compatible way as possible
15:13:11 <gchamoul> diagram++
15:13:15 <jruzicka> but better clean with temporary breakage
15:13:23 <jruzicka> then cr4p forevah
15:13:25 <apevec> number80, and in CBS Koji it's whatever we put when doing cbs add-pkg ... i.e. not update after that
15:14:01 <jruzicka> apevec, how would it look?
15:14:20 <apevec> jruzicka, ok, so currently we start with rpm-master in github/openstack-packages
15:14:35 <jruzicka> anyway, I'm all for having all the moving parts described declaratively
15:14:41 <apevec> (NB there's upstream Packaging as project proposal which might change that)
15:14:49 <jruzicka> but danger is to have too much redundancy
15:14:59 <apevec> jruzicka, that's the trouble all parts are moving :)
15:15:04 <jruzicka> hehe, right
15:15:12 <number80> apevec: yeah, atm, I don't pay attention to this but it will be important for our big tent packaging goals
15:15:14 <jruzicka> so I say, pollute the rdoinfo for now
15:15:15 <jschlueter> situation normal
15:15:57 <jruzicka> and I'll redesing it in the near future once I myself know wtf is going on
15:15:57 <apevec> jruzicka, for backward compat we just need to keep current field, adding should be fine
15:16:53 <apevec> so back to rpm-master: we track upstream changes there, but at some point we have discontinuity(sp?)
15:17:10 <apevec> when we need to move to dist-git to make "real" builds
15:17:38 <apevec> so suggestion was to avoid this singular point,
15:17:45 <jruzicka> IOW let's see what the real needs do to rdoinfo, and I'll try to clean it up afterwards
15:17:46 <apevec> and just ship Delorean builds in RDO repos
15:18:05 <apevec> I've trouble with that b/c of build reproducibility
15:18:22 <apevec> jruzicka, ack
15:18:32 <number80> apevec: I think most of the mentioned issues are getting sorted, at least on the CentOS side
15:19:05 <number80> making Delorean builds suitable for production (signing, reproducibility) would be a lot of efforts to end up stumbling on the very same issues ...
15:19:20 <apevec> yeah, we would reimplement Koji...
15:19:32 <number80> which is actually being rewritten :)
15:20:09 <apevec> heh
15:20:35 <mburned> why not make delorean *use* koji/cbs?
15:21:14 <apevec> #info CentOS SIGs side is sorting out publishing pipeline
15:21:39 <apevec> mburned, yeah, that one idea, question is about accounts
15:21:55 <apevec> currently all account have human accountable for it
15:22:11 <apevec> I'm not sure bot account in the buildsystem would be allowed
15:22:17 <apevec> need rel-eng input on that
15:22:26 <number80> for Fedora, it's likely to be no
15:22:31 <mburned> apevec: if we can build to a non-production tag...
15:22:43 <apevec> number80, yeah, bots cannot sign CLA :)
15:22:46 <mburned> or even scratch builds that we extract into our own repos...
15:22:56 <number80> :)
15:23:06 <apevec> mburned, right, so that would be still 2nd class repos
15:23:09 <mburned> then we have something a human could import and build into the correct tags
15:23:13 <apevec> for production you'd still need real thing
15:23:29 <apevec> mburned, yep, that's critical
15:23:30 <mburned> apevec: yes, there is a manual step, but we'd have srpms we can immediately import
15:23:35 <apevec> how to automate import
15:23:54 <apevec> mburned, but I don't think scratch koji builds would help
15:24:07 <apevec> they'd be still from master packaging templates
15:24:21 <apevec> for real builds you need immutable NVR i.e. commit in dist-git
15:24:28 <apevec> at least that's current Koji setup
15:24:30 <number80> moreover, delorean builds don't have changelogs
15:24:34 <apevec> maybe that could be improved?
15:24:51 <apevec> number80, yeah, but I think we should follow suse there i.e. separate file for changelog
15:24:58 <number80> +1
15:25:10 <mburned> apevec: are fedora sigs the same?
15:25:20 <number80> I'm pretty sure that nobody would really complain if we start doing it though
15:25:22 <mburned> use the same koji, same rules, same tags, etc?
15:25:35 <apevec> also in upstream "no-more-stable-point-releases" discussion automatic changelog generation was suggested
15:25:47 <apevec> with specially formatted commit messages
15:26:16 <number80> mburned: not at all, they're informal groups
15:26:19 <apevec> mburned, fedora sigs (or actually workgroups?) require package to be in Fedora
15:26:23 <apevec> i.e. there isn't CBS
15:26:30 <mburned> ok...
15:26:37 <number80> I'm trying to champion CentOS SIG-like in fedora for a while :)
15:26:39 <apevec> closest for Fedora would be copr
15:26:41 <mburned> that doesn't help then...
15:26:51 <apevec> yeah,
15:27:25 <apevec> so current suggestion would be to improve centos SIG pipeline, solve import to dist-git
15:27:39 <apevec> and eventually have production RDO repos only at mirror.centos.org
15:27:52 <apevec> for Fedora would offer Delorean repos only
15:28:01 <number80> apevec: +2
15:28:09 <mburned> apevec: so drop packages from fedora proper?
15:28:20 <number80> mburned: we still need the reviewing process
15:28:22 <apevec> mburned, eventually yes, missing piece is centos dist-git
15:28:38 <apevec> so we need to use fedora dist-git for now
15:28:39 <mburned> number80: sure, but we can enforce guidelines as part of rdo
15:28:49 <number80> mburned: yeah
15:28:53 <mburned> we don't *need* fedora builds for that
15:29:00 <mburned> apevec: sure
15:29:01 <apevec> mburned, yes, but would be reinventing the process
15:29:16 <apevec> mburned, instead why not push Fedora to improve review process
15:29:28 <apevec> mburned, note that we don't want _all_ deps in RDO
15:29:36 <apevec> we do want to push general ones to Fedora
15:29:40 <mburned> apevec: you're already proposing moving our packages out of fedora
15:29:42 <apevec> like most of python-*
15:29:50 <mburned> apevec: sure, deps should go in fedora
15:30:06 <apevec> mburned, only openstack-*
15:30:18 <apevec> mburned,  we do want clients (and oslo as their deps) in Fedora
15:30:36 <apevec> so that Fedora can be used as a client to openstack based clouds
15:30:42 <apevec> jruzicka, ^
15:30:56 <jruzicka> agreed
15:31:05 <mburned> apevec: we still get into trouble there...
15:31:07 <mburned> with clients
15:31:22 <apevec> yeah, upstream created stable/* branches for clients
15:31:24 <jruzicka> mburned, upstream started using stable/RLS for clients as well
15:31:25 <number80> delorean repo could be used for people who want using fedora to build small PoC and development station so it should be good enough
15:31:33 <apevec> but those are not really useful
15:31:35 <apevec> jruzicka, ^
15:31:41 <mburned> right, so we have a Fedora --> Openstack mapping
15:31:49 <mburned> even though we don't want it
15:31:50 <jruzicka> mburned, now is first cycle, so let's see how stable client branches change the sad client scene
15:32:02 <apevec> jruzicka, it made it worse :(
15:32:03 <cucumber_> Is there any change on the rdo installer? After executing "yum install -y openstack-packstack" I got this error: https://paste.fedoraproject.org/228500/
15:32:11 <apevec> e.g. heatclient team wasn't aware
15:32:20 <cucumber_> it asks me for python-docutils
15:32:21 <apevec> so current heatclient stable/kilo is missing Kilo features...
15:32:23 <mburned> if we have clients separate in rdo, then we can have a kilo-clients repo and a liberty-clients repo
15:32:23 <jruzicka> quite some responsibility moved from us to upstream, which is convenient... but also loss of control
15:32:33 <cucumber_> yesterday worked fine
15:32:58 <mburned> both for the same fedora version
15:33:01 <apevec> cucumber_, that seems to very old version , which repos you're using
15:33:04 <jruzicka> apevec, I see. So we need to pressure upstream to take client versioning seriously
15:33:13 <apevec> cucumber_, but please wait until meeting is over...
15:33:31 <cucumber_> http://rdo.fedorapeople.org/rdo-release.rpm
15:33:34 <mburned> jruzicka: versioning of clients forces mapping of fedora and openstack version unless the clients live outside...
15:33:35 <cucumber_> oh.. ok, sorru
15:33:37 <cucumber_> sorry
15:33:38 <jruzicka> it's great all these magnificient features hit the core services, but that's not all that great when you can't talk to it
15:34:06 <jruzicka> mburned, some clients are better than none. They still ought to be backward compat
15:34:22 <apevec> jruzicka, yeah, that's what heatclient team promised:
15:34:33 <apevec> master will work with Kilo deps and be backward compatible
15:34:51 <mburned> still forces people to update fedora if they want latest...
15:34:55 <jruzicka> None of promises about clients were met
15:34:55 <apevec> so they should be safe to ship in Kilo repo
15:35:02 <trown> all clients should be backward compatible
15:35:09 <jruzicka> so let's see this cycle...
15:35:10 <apevec> but we don't have that guarantee for all clients
15:35:13 <mburned> or we need to only ship latest clients regardless of version
15:35:20 <apevec> trown, should, yes, but no guarantees :(
15:35:43 <jruzicka> yes, it's this "one nice lady told me it should be like that"
15:35:51 <apevec> mburned, if they work in Kilo repo, but how do we ensure
15:35:54 <jruzicka> but mechanisms still missing
15:36:00 <mburned> apevec: exactly my point...
15:36:05 <jruzicka> anyway, that's upstream problem now
15:36:10 <mburned> and more reason to have them outside fedora
15:36:12 <jruzicka> so let's solve it upstream
15:36:21 <trown> the openstack client should also help wrt outliers in backward compatibility
15:36:33 <jruzicka> we can bring added value by providing client that actually work with latest features
15:36:34 <trown> since that would be handled there
15:36:41 <jruzicka> as we did till now
15:36:48 <jruzicka> but we should pressure upstream to take care of that
15:37:06 <apevec> jruzicka, you already had to backport one feature to OSC Kilo
15:37:34 <jruzicka> yeah, yeah, there are stable/kilo branches
15:37:40 <jruzicka> but it looks exactly the same to me
15:37:53 <jruzicka> not too many fscks given about poor clients
15:38:16 <jruzicka> well people who actually use them will hit issues, report issues, someone's gonna fix them...
15:38:48 <apevec> jruzicka, mburned, my concern is that master clients could get new dep from Liberty reqs
15:38:54 <jruzicka> Hmm, I need to go to next summit.
15:39:14 <mburned> apevec: yes, we need to watch that
15:39:16 <apevec> unless client team actively watches requirements updates (those are automatic from global reqs)
15:39:40 <mburned> apevec: so far, they seem mostly safe
15:39:50 <mburned> i looked at heat yesterday, only concerning one was pbr
15:40:00 <apevec> mburned, only heatclient team  (shardy actually)  commited doing that in https://review.openstack.org/182672
15:40:15 <apevec> mburned, pbr should be fine, I'm updating it
15:40:43 <apevec> jruzicka, ^ have a look at that review BTW, to see the upstream stable clients story
15:40:53 <ryansb> unfortunately we have to let in new PBR so the gate works
15:41:21 <apevec> shardy, ^ but it's still not completely clarified in https://review.openstack.org/182672 ?
15:41:39 <apevec> ryansb, update PBR is actually better
15:41:52 <apevec> it even dropped bogus pip dep from requirements.txt
15:42:03 <ryansb> ah, well that's good
15:42:36 <apevec> ok, we went into weeds, let's get back to strategy level :)
15:43:03 <apevec> #info Kilo bootstrap repo was bad combination of Juno and new deps in RDO Kilo GA location
15:43:24 <apevec> #action apevec to start Liberty bootstrap with new deps in _testing_ location
15:43:32 <apevec> and make Delorean Trunk use that
15:44:17 <apevec> I think combining RDO Juno + boostrap Kilo created issues when doing real RDO repos
15:44:50 <rbowen> I'm here now, if the meeting is still ongoing.
15:44:52 <number80> i share that opinion
15:44:58 <number80> rbowen: you're more than welcome
15:45:01 <rbowen> I see that it is. :-)
15:45:04 <apevec> also new-pkg procedure mentioned earlier, will require new package to be added to RDO Liberty via rdopkg update
15:45:20 <apevec> rbowen, yes, I think we'll use full hour for sure
15:45:48 <apevec> ok next was about doing bigger pkg changes, like splitting packages
15:46:10 <apevec> #info Changes in packaging which required changes in the Puppet module...
15:46:19 <eggmaster> apevec: will we expect ci for `rdopkg update` for liberty builds? or will those get a pass while we are building up those repos?
15:46:24 <apevec> this needs to be done very early in the cycle
15:46:53 <number80> we need to have puppeteers reviewing these changes too
15:46:57 <apevec> eggmaster, TBD - I'd sanity check, e.g. yum install *rpm works
15:47:03 <eggmaster> seemed like for new kilo builds we had no ci support (at least none that was working)
15:47:03 <apevec> I'd like...
15:47:28 <number80> jpena: you'd be ok, if I add you as reviewer when needec?
15:47:33 <jpena> apevec: actually, changing packaging very early in the process will not allow us to have it fixed in the puppet side, because stable branches take some time to be ready after release
15:47:34 <apevec> eggmaster, yeah, that's what we'd need to add for Liberty, before liberty-1
15:47:44 <gchamoul> number80: you can count me in as well!
15:47:50 <number80> gchamoul: \o/
15:47:54 <rbowen> There's not going to be a Liberty-1
15:47:54 <number80> gchamoul++
15:47:55 <apevec> jpena, ah good point
15:47:55 <jpena> number80: sure, no problem. Feel free to add me.
15:48:05 <apevec> rbowen, what do you mean?
15:48:22 <apevec> jpena, and actually that brings the good point:
15:48:30 <apevec> packaging changes must keep backward compat!
15:48:32 <rbowen> Unless I misunderstood Theirry's message, we're no longer going to do the point releases.
15:48:39 <apevec> #info packaging changes must keep backward compatibility
15:48:45 <rbowen> Looking for the blog post. One second.
15:48:47 <apevec> rbowen, that's for stable
15:48:55 <jpena> apevec: +1 to that
15:48:57 <apevec> liberty-1 is devel milestone, that's still there
15:48:59 <rbowen> Oh. I guess I did misunderstand, then.
15:49:23 <apevec> here is L schedule https://wiki.openstack.org/wiki/Liberty_Release_Schedule
15:49:40 <number80> apevec, jpena: in some case, that's not possible
15:49:53 <apevec> number80, then you'll get revert from dprince :)
15:49:59 <apevec> like for glance
15:50:18 <number80> yeah, but we need at some point being able to do such changes :/
15:50:21 <apevec> this one https://review.gerrithub.io/230453
15:50:48 <apevec> number80, it's not just puppet where we have folks participating
15:50:55 <number80> that's exactly what I want to avoid in the future :)
15:50:58 <apevec> it's chef/ansible/bash scripts/whatnot
15:51:26 <apevec> number80, default should be to keep backward compat
15:51:28 <number80> well, the problem will be allowing finer-grained deployment too
15:51:34 <number80> agreed on default
15:51:37 <apevec> jpena, and puppet could support both ?
15:51:51 <apevec> i.e. take advantage if subpkg split is available
15:51:58 <apevec> or is that too much to expect?
15:52:29 <apevec> number80, split into new subpkgs and keep meta subpkg for backward compat?
15:52:37 <jpena> apevec: what do you mean? Supporting both the old and new packaging schemes? It looks difficult to me :-/
15:52:38 <number80> if we can't change, then we should also be stricter during package reviews
15:52:51 <apevec> jpena, yeah, I'd guess so
15:53:00 <number80> apevec: yes, we need to enforce meta-subpkg too
15:53:08 <apevec> number80, you can't know in advance...
15:53:25 <number80> apevec: we can enforce having meta subpkg for all service
15:53:39 <jpena> apevec: I can't think of an easy way to support two types of packages for the same platform
15:54:18 <apevec> jpena, yeah, you'd need to query is some package avialable or not...
15:54:31 <number80> jpena: we couldn't have puppet-modules starting to support a newer type starting a specific upstream release?
15:55:05 <apevec> number80, so shall we test drive such changes asap: repropose glance api/registry and proposed sahara split
15:55:15 <apevec> and see first if backward compat is doable
15:55:30 <jpena> number80: yes, that is doable (we did that for neutron lbaas/fwaas in this cycle, for example). The only issue is timing: we cannot do anything liberty-specific that breaks backwards compatibility until the stable/kilo branch is ready
15:55:35 <number80> apevec: for glance it's not possible, we had conflicting needs
15:55:47 <number80> jpena: I see
15:56:08 <number80> apevec, jpena: let's reschedule this discussion as soon as we have liberty branch then
15:56:19 <apevec> number80, I think there was some combination which should work, but forgot... let's just start it again
15:56:29 <number80> ok
15:56:35 <apevec> number80, for puppet-* ?
15:56:45 <apevec> jpena, what is ^ that expected?
15:56:47 <number80> apevec: yes, it seems to be easier
15:56:57 <apevec> actually, stable/kilo for puppet-* ?
15:57:07 <apevec> and master would be then open for L changes
15:57:19 <number80> from my understanding master is currently kilo for puppet-
15:57:25 <apevec> yep
15:57:34 <gchamoul> number80: yes!
15:57:42 <apevec> so question is when stable/kilo for puppet-* is expected?
15:58:14 <jpena> apevec: I'm not aware of a set date, from https://etherpad.openstack.org/p/liberty-summit-design-puppet-master-branch they say "master breaks when there is packaging from upstream", which in RDO means.. now
15:58:41 <apevec> right
15:58:42 <jpena> gchamoul: do you know if there is already a defined date for stable/kilo branch in puppet-* ?
15:58:58 <shardy> apevec: AFAIK I lost the argument and should abandon that patch
15:59:13 <gchamoul> jpena: no date yet! and the PTL is on PTO ...
15:59:14 <shardy> apevec: maybe confirm with stevebaker, but I belive we plan to just keep releasing from the master branch
15:59:42 <apevec> shardy, ok, but you commit to keep deps Kilo-compatible?
16:00:19 <apevec> stevebaker, ^
16:00:40 <apevec> shardy, otherwise we can publish master relase in RDO Kilo repo
16:00:49 <apevec> ahem, cannot !
16:01:11 <mburned> apevec: well, we can, but people won't be too happy...
16:01:32 <apevec> mburned, what do you mean?
16:01:46 <shardy> apevec: we need to have that discussion with stevebaker, my personal opinion is yes, but stevebaker normally handles releases for heatclient, so ultimately he gets the final say (also he's PTL atm.. ;)
16:02:38 <apevec> shardy, ack
16:02:50 <apevec> ok, time is up, let's quickly review remaining low points...
16:03:10 <apevec> #info Improving reviewing process
16:03:19 <mburned> apevec: i mean we could physically ship the package, but it would break users
16:03:26 <mburned> so they'd be mad if we did update it
16:03:32 * mburned was trying to be glib...
16:03:59 <apevec> mburned, that's what I'm trying to ensure w/ shardy / stevebaker - we don't want to break anything
16:04:10 <apevec> ensure backward compatible deps is first step
16:04:13 <number80> I crossed the points already dealt in the trello card
16:04:13 <mburned> apevec: yes, i agree
16:04:20 <apevec> but also keeping backward compat CLI, API etc
16:04:28 <apevec> number80, thanks
16:04:50 <apevec> #info Identifying maintainers for every component
16:05:14 <number80> I'd like we encourage community members here
16:05:18 <apevec> also touched, I'll try to expand rdoinfo to be our "pkgdb" for everything we ship
16:05:25 <apevec> yes!
16:05:54 <apevec> #info delorean/master stopped or stuck
16:06:14 <apevec> that's under discussion, we're looking for better hosting
16:06:38 <apevec> also we shall puppetize it, so we can rebuild delorean server easily
16:06:54 <apevec> #info delorean notification
16:07:00 <gchamoul> apevec: I take this task!
16:07:05 <apevec> should be fixed w/ better hosting and puppetizations
16:07:08 <apevec> gchamoul, thanks!
16:07:31 <apevec> now quickly + points ( yes, we have them! :)
16:07:34 <number80> gchamoul++
16:07:34 <jpena> gchamoul: if you need help or a betatester, let me know ;)
16:07:49 <gchamoul> jpena: ack!
16:08:02 <apevec> #info Delorean Trunk worked fine (we it was working)
16:08:31 <apevec> #info and last but not least: More community participation <3
16:08:41 <kashyap> apevec: number80: And any packaging experts, not sure if you've noticed this response yet upstream -- http://lists.openstack.org/pipermail/openstack-dev/2015-June/065679.html
16:08:47 <apevec> thanks everybody who participated in Kilo cycle, more fun stuff is coming!
16:08:54 <number80> thanks to alphacc without whom we couldn't have shipped this release in time \o/
16:08:58 <gchamoul> thx everybody!
16:08:58 <kashyap> Err sorry, didn't notice the meeting in progress :-(
16:09:11 <apevec> #topic open floor
16:09:26 <apevec> kashyap, it's just appropriate for open floor, lemme have a look...
16:09:27 <kashyap> apevec: Okay, I think I arrived at right time.
16:09:29 <rbowen> kashyap: Interesting. That's actually very relevant to the meeting, it seems.
16:09:31 <kashyap> Exactly.
16:09:59 <kashyap> rbowen: I was looking at scroll, and totally forgot meeting has started. As I'm switching between Nova channel and here.
16:10:17 <kashyap> apevec: Yeah, especally the last paragraph.
16:10:19 <number80> important
16:10:38 <kashyap> apevec: What is the hurry for Thomas, I don't see.
16:11:01 <number80> I do not get it too :/
16:11:05 <rbowen> Hmm. Having Debian/Ubuntu as part of the "official" packaging, and CentOS/Fedora/SUSE *not* makes a pretty obvious statement.
16:11:08 <apevec> me neither, I guess he wants to offload work,
16:11:17 <apevec> it was all him
16:11:17 <rbowen> that is, Ubuntu is the right place to deploy OpenStack.
16:11:22 <kashyap> He seems to be in a big hurry.
16:11:23 <apevec> and Ubuntu was just taking his work
16:11:37 <kashyap> So, someone might want to comment and ask about what's the hurry
16:11:42 <jruzicka> So I'm just releasing rdopkg-0.28 with `rdopkg reqquery`
16:11:59 <gchamoul> jruzicka++ !!!
16:12:03 <jruzicka> which is able to query requires versions across rdo/fedora repos
16:12:19 <jruzicka> source can be requirements.txt, $THAT from git, .spec file
16:12:28 <apevec> number80, we need to have a look at opensuse specs and see how we could work with them
16:12:30 <kashyap> jruzicka: There's another topic in discussion.
16:12:34 <kashyap> :-)
16:12:43 <jruzicka> open floor is open :)
16:12:48 <jruzicka> sry
16:13:01 <number80> apevec: I suggest that we split this in two part: gerrit integration for review as we do for delorean and figure out the tooling part
16:13:02 <kashyap> Open floor == one topic at a time.
16:13:13 <number80> *later
16:14:11 <apevec> number80, right, that's what derekh suggested: we donate openstack-packages namespace so we can get deb/rpm spec reviews going in the open
16:14:27 <apevec> and infra tooling could be developed at its own pace
16:14:41 <apevec> we have delorean which is fine for now
16:15:08 <apevec> and deb could have whatever they want, if they don't like delorean design
16:15:15 <apevec> sbuild or whatnot
16:15:30 <number80> I'll ping opensuse folks btw
16:15:48 <apevec> number80, we already got pinged, I'll fwd you email from derek
16:15:58 <number80> ok
16:16:22 <apevec> but I wanted to quickly review  their specs before replying
16:16:59 <apevec> I did in the paste and noticed separate changelog file which I liked
16:17:02 <apevec> past
16:17:22 <jruzicka> oh yes, separate changelog sounds good to me
16:17:35 <apevec> I forgot where's their dist-git ...
16:18:12 <apevec> anyway, we'll followup on that
16:18:28 <apevec> meeting is running over, let's release the channel
16:18:39 <apevec> last chance for meeting minutes!
16:18:46 <apevec> 3
16:18:57 <apevec> 2 1
16:19:02 <apevec> thanks everybody!
16:19:05 <apevec> #endmeeting