08:00:37 <ttx> #startmeeting ptl_sync
08:00:38 <openstack> Meeting started Tue Jun 17 08:00:37 2014 UTC and is due to finish in 60 minutes.  The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot.
08:00:39 <mikal> Heh
08:00:40 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
08:00:42 <openstack> The meeting name has been set to 'ptl_sync'
08:00:49 <ttx> #topic Nova
08:00:54 <mikal> Hello
08:01:02 <ttx> mikal: yay, I didn't forget this time.
08:01:16 <mikal> Neither did I
08:01:21 <mikal> Its like a personal best for the both of us
08:01:32 <ttx> #link https://launchpad.net/nova/+milestone/juno-2
08:04:35 <ttx> As it stands it looks quite good, but i suspect the autokick script has been busy keeping crap entries out
08:04:35 <ttx> mikal: how.. representative is it of what you expect to land during the next 5 weeks ?
08:04:35 <ttx> I certainly like that most of those show up as "under review" already
08:05:04 <mikal> So, there's a pleasing amount of "needs code review" there
08:05:05 <mikal> We do need to start reviewing specs more actively again though, there's a lot blocked up in that process
08:05:05 <mikal> Although, review bandwidth is our obvious problem once again
08:05:53 <mikal> Its a little hard to tell
08:06:05 * johnthetubaguy waves
08:06:07 <mikal> I agree that needs code review is good, although it remains to be seen if that's all the code for each of those bps
08:22:10 <mikal> Yeah, in some cases its pretty obvious why they're taking a break
08:22:11 <mikal> Is that an unsplit?
08:22:12 <mikal> ttx: we decided you're doing all of nova
08:22:12 <johnthetubaguy> mikal: maybe, I think we just joined back with the rest of the world
08:22:12 <mikal> ttx: you there?
08:23:07 * ttx emerges from the other side of the netsplit
08:23:16 <mikal> Heh, we had a nice meeting without you
08:23:24 <ttx> mikal: yt?
08:23:37 <mikal> Basically we're code talking review backlog and spec review backlog
08:23:44 <mikal> talking code even
08:23:49 <mikal> ttx: can you hear me?
08:24:06 <ttx> o/
08:24:10 <mikal> Hi!
08:24:14 <ttx> So I was saying...
08:24:27 <ttx> <mikal> I agree that needs code review is good, although it remains to be seen if that's all the code for each of those bps
08:24:27 <ttx> <ttx> it should be. If it's just that intermediary code is in review, it should be set to Good progress
08:24:27 <ttx> <ttx> Basically "needs code review" means "all code is now up for review"
08:24:36 <ttx> <ttx> otherwise you keep going back to good progress and it's a bit useless as a progress marker
08:24:38 <johnthetubaguy> mikal: so, we might want to try little blueprints without specs at somepoint soon, but lets just see how its going
08:24:49 <ttx> <ttx> mikal: how do you want to address that?
08:24:49 <ttx> <ttx> I was pretty sure that adding a formal spec approval would just make the pipe longer, not faster
08:24:49 <ttx> <ttx> since the same resources are used in both reviews
08:24:49 <ttx> <ttx> At the start it will trigger a slowdown as people adjust to the new shape of the tube
08:24:49 <ttx> <ttx> In the end it should be slightly faster since you should spend less time reviewing the whole idea at code review time
08:24:56 <ttx> <ttx> mikal: Do you think a specific "spec review day" at the start of a milestone would help fast-approving a pack of them ?
08:25:21 <mikal> Oh, a spec review day is an interesting idea
08:25:36 <ttx> I think it would give a fast feedback loop
08:25:36 <mikal> Although to be honest I think our biggest problem is we rely on a small number of very busy people
08:25:44 <johnthetubaguy> ah, cool, we spoke about a spec proposal freeze for Juno-2 and Juno-3 on 3rd July
08:25:45 <ttx> you could ask BP proposers to handg out
08:26:14 <mikal> I think the idea of a spec review day should be included in the spec proposal freeze announcement
08:26:24 <mikal> And having a faster feedback loop sounds good to me
08:26:28 <johnthetubaguy> A combination sounds good
08:26:35 <ttx> mikal: it's not a magic bullet, but I think having multiple people fast-iterating on them could help fast-approving a few
08:26:47 <johnthetubaguy> people often catch me on IRC, and it does help resolve things quicker
08:26:51 <mikal> I think we also need to remind -drivers to be reviewing specs
08:26:55 <mikal> I know I haven't been doing enough of it
08:27:17 <ttx> mikal: it's a bit tricky to prioritize. Been struggling with it myself
08:27:20 <johnthetubaguy> mikal: we did stop doing it that last few weeks on purpose
08:27:26 <ttx> I guess we'll get used to it
08:27:49 <mikal> I think its the "very busy person" problem to be honest
08:27:52 <ttx> mikal: OK, that's all I had. j2 status looks in sync with what you know of today , which is good
08:27:52 <johnthetubaguy> mikal: that was the Juno-1 push, but yeah, we need to get back on the wagon with that stuff
08:28:02 <mikal> But anyways, yes. We should refocus on specs for a while and then freeze new proposals
08:28:25 <johnthetubaguy> yeah, my only worry is the stuff we want that is not yet through spec reviews, so not on the lp radar yet really
08:28:40 <johnthetubaguy> but the freeze date, and a review day should help that
08:28:42 <ttx> mikal: e might need to be a bit less strict in spec review approval. There might be a middle ground between "no spec review at all" and "spend 72 patchsets for every spec"
08:28:58 <mikal> johnthetubaguy: do you think it would help if we pulled out a list of stuff we really want from -specs and ask drivers to focus on it?
08:29:03 <johnthetubaguy> ttx: +1 I think the little guys need to get through faster
08:29:05 <ttx> just having the doc around at code review time is useful
08:29:22 <johnthetubaguy> mikal: I plan to create that as part of the priority setting
08:29:31 <mikal> I agree that we don't need absolute perfection in specs
08:29:32 <ttx> so in theory even if we accepted them all directly it would be better than what we were doing with BPs
08:29:41 <mikal> ttx: agreed
08:29:51 <ttx> so I wouldn't nitpick them to death
08:29:58 <ttx> OK, I need to run
08:30:14 <ttx> Anything you wanted to discuss at meeting later/tomorrow ?
08:30:33 <mikal> No, I think I am good
08:30:48 <mikal> johnthetubaguy: thanks for being awesome once again
08:31:01 <johnthetubaguy> :)
08:31:04 <johnthetubaguy> no problem
08:31:12 <ttx> OK then, ttyl
08:31:17 <mikal> Laters
08:31:27 <mikal> johnthetubaguy: I'm going to wander off to cook dinner, talk more later
08:31:43 <johnthetubaguy> mikal: sounds good, enjoy dinner
08:31:58 <johnthetubaguy> mikal: thinking June 26th for spec review day
08:32:15 <mikal> What day of the week is that?
08:32:21 <mikal> I'd avoid Mondays and Fridays
08:32:26 <johnthetubaguy> release day, so thursday I think
08:32:34 <mikal> Sounds good to me
08:32:59 <johnthetubaguy> cool, gives a week for loose ends
08:33:16 <mikal> Works for me
08:33:39 <mikal> Ok, dinner time for me
08:33:39 <mikal> Bye!
08:34:00 <johnthetubaguy> bye
08:34:13 <johnthetubaguy> seems internet broke again anyways
11:44:27 <eglynn> ttx: o/
11:44:47 <ttx> eglynn: o.
11:44:52 <ttx> #topic Ceilometer
11:45:07 <eglynn> hey
11:45:20 <ttx> #link https://launchpad.net/ceilometer/+milestone/juno-2
11:45:26 <eglynn> so almost everything we bumped from juno-1 has now landed
11:45:31 <ttx> Looks good, if not a bit empty
11:45:44 <eglynn> yeah the cupboard is still relatively bare for j2
11:45:51 <eglynn> as planning is still in progress
11:45:57 <eglynn> filing of BP specs discussed at last week's upstream meeting
11:46:00 <ttx> There might have been a few things that got autokicked that you might want to push back in
11:46:17 <eglynn> cool enough I'll check that
11:46:33 <ttx> The trick with the new system is that some features may just land without appearing on the release radar at all
11:46:53 <eglynn> yeah I'll keep an eye on that
11:46:54 <ttx> so it's good to check that most major ones are accounted for
11:47:07 <eglynn> BTW we've a long laundry list of possible work items for j2, so no shortage of possibilities
11:47:14 <eglynn> we have a few in-flight specs reviews ...
11:47:21 <eglynn> https://review.openstack.org/#/q/status:open+project:openstack/ceilometer-specs,n,z
11:47:32 <eglynn> but I'm expecting a lot more by EoW
11:47:33 <ttx> indeed
11:47:57 <eglynn> BTW we've had persistent gate problems the past few days with a timing issue in the py26 build
11:48:06 <ttx> I'd like us to look into the gap coverage plan and progress there
11:48:16 <eglynn> I've curated the wiki page a bit
11:48:21 <ttx> https://wiki.openstack.org/wiki/Governance/TechnicalCommittee/Ceilometer_Gap_Coverage
11:48:21 <eglynn> #link https://wiki.openstack.org/wiki/Governance/TechnicalCommittee/Ceilometer_Gap_Coverage
11:48:23 <eglynn> yeap
11:48:35 <eglynn> should be good for review I think
11:48:49 <ttx> I think you're in good shape there
11:48:50 <eglynn> should I plan to be on-hand during the TC meeting this evening for this topic?
11:48:55 <ttx> No, I can report back
11:49:00 <eglynn> cool enough
11:49:07 <ttx> I mean, you can come, of course
11:49:13 <ttx> but I'll report back on progress
11:49:34 <eglynn> the progress reported on the wiki is up-to-date, I've sanity-checked my updates with each of the "drivers"
11:50:06 <ttx> OK, no significant delay compared to the initial plan, right ?
11:50:26 <eglynn> nope, good front-loaded progress for juno-1 as agreed with the TC
11:50:34 <ttx> #info Gap coverage is on track, expected to be finished by j2
11:50:40 <eglynn> and all remaining action is good shape to for juno-2
11:50:48 <eglynn> shape to *land
11:51:10 <ttx> Do you expect a lot of the -specs might be j2 material ? or more of j3 material ?
11:51:43 <eglynn> some will definitely be j2, which is why I'm eager to get that stuff proposed ASAP
11:51:56 <ttx> agreed.
11:52:35 <ttx> We built a backlog when we switched to specs (with people retroactively filing specs for stuff they already worked on)but I suspect this will be less of an issue
11:52:46 <ttx> as we go on
11:52:58 <eglynn> the -specs process is working ok I think, with just some minor compalining about the Kafkaesque bureaucracy ;)
11:53:22 <ttx> You're free to place the cursor where it makes the most sense
11:53:41 <ttx> i.e. only require specs for high-profile changes if that makes more sense
11:54:07 <ttx> but having multiple entry points makes the process more complex
11:54:26 <ttx> so I would rather have a light template for basic stuff and fasttrack them through
11:54:26 <eglynn> yeap, I'm erring on the side of requiring a spec in general to get folks used to the idea
11:54:48 <eglynn> but defo open to fasttracking the non-contraversial/simpler stuff
11:54:48 <ttx> Not everything should require endless nitpicking and two +2
11:55:13 <ttx> OK, anthing you want to discuss at cross-project meeting tonight ?
11:55:14 <eglynn> yeap, I've also tried to minimzie spelling/grammar nitpicks for -specs reviews
11:55:25 <eglynn> nothing specific I guess
11:55:30 <ttx> OK, questions?
11:55:40 <eglynn> quick heads-up on the ceilo mid-cycle July 2-4, many of us will be kinda off-grid for those 3 days
11:55:47 <eglynn> #link https://wiki.openstack.org/wiki/Sprints/ParisJuno2014#Ceilometer
11:55:55 <eglynn> mid-cycle attendence shaping up OK so far ...
11:56:05 <eglynn> ... at least another two attendees in the pipeline, which would make 7 for ceilo in total
11:56:23 <ttx> cool
11:56:31 <eglynn> not huge, but definitely reaches quorum
11:57:02 <eglynn> that's all I got for today ...
11:57:29 <ttx> ok, great ttyl
11:57:35 <ttx> SergeyLukjanov: around?
12:04:26 <SergeyLukjanov> ttx, yup
12:04:29 <SergeyLukjanov> ttx, sorry, I've been sending documents for visa
12:04:29 <ttx> #topic Sahara
12:04:34 <ttx> fun
12:05:00 <ttx> https://launchpad.net/sahara/+milestone/juno-2
12:05:06 <SergeyLukjanov> #link https://launchpad.net/sahara/+milestone/juno-2
12:05:23 <ttx> Looks good, a bit ambitious maybe
12:05:38 <SergeyLukjanov> ttx, it's not final/clean yet
12:05:55 <ttx> just evolve it as reality changes
12:06:45 <ttx> SergeyLukjanov: I wanted to attrct your attention to https://review.openstack.org/#/c/97872/2
12:06:59 <SergeyLukjanov> ttx, I think it's already looks liek our plans for j2
12:06:59 <ttx> proposal to require some sort of translations support in integrated projects
12:07:13 <ttx> If I'm not mistaken, that would create an instant gap for Sahara
12:07:20 <ttx> do you have plans in that area ?
12:07:46 <SergeyLukjanov> ttx, yup, I've seen it, we already have everything needed configred in sahara (babel, scripts, traslation jobs, transifex project and etc.)
12:07:59 <SergeyLukjanov> ttx, the only gap is lack of the _(..) wrapped strings
12:08:12 <ttx> SergeyLukjanov: ok
12:08:19 <SergeyLukjanov> ttx, last two assignments doesn't complete this work :(
12:08:56 <SergeyLukjanov> ttx, so, it could be prioritized and done in j2
12:09:11 <ttx> OK, just trying to see if that would place you in some impossible spot
12:09:20 <ttx> but apparently, not really
12:09:44 <ttx> How is the removal of extra repositories going ?
12:09:50 <SergeyLukjanov> ttx, yup, just wrap lines with _
12:10:27 <SergeyLukjanov> ttx, we have tasks to move sample jobs out of it
12:10:53 <ttx> dashboard move is ready and pending on horizon devs, as we saw last week
12:11:04 <ttx> what about the other two?
12:11:12 <SergeyLukjanov> ttx, and then we'll have only hadoop swift fs in extra, but we're still not sure about the future of it
12:11:29 <ttx> image-elemnets was merged already ?
12:11:44 <SergeyLukjanov> ttx, nope, we decided to keep it as is
12:12:02 <SergeyLukjanov> ttx, I was thinking that we already discuss it with you several weeks ago...
12:12:11 <ttx> yes, certainly :)
12:12:34 <ttx> i just need to remember
12:12:59 <ttx> So in the end, only -dashboard will get merged
12:13:24 <SergeyLukjanov> so, summary status: keep -image-elements as is, merge -dashboard to horizon, keep only hadoop swift fs in -extra (no releases)
12:13:59 <ttx> ok, so the only risk is with -image-elements ... IIRC you said that it had to be in sync with the release
12:14:13 <SergeyLukjanov> ttx, we're thinking about moving hadoop swift fs to separated repo but we're now in the progress of endless discussions
12:14:31 <ttx> so having it outside the release management but still kept in sync with official releases sounds a bit brittle to me
12:14:37 <SergeyLukjanov> ttx, we'll push the same tags to it and we'll have docs about buidling corresponding images
12:14:51 <SergeyLukjanov> ttx, and we're planning to publish a base set of images for each release
12:15:05 <ttx> can the main software work without the corresponding image-elements ?
12:15:30 <SergeyLukjanov> ttx, yup, if you have correctly prepared image (with installed hadoop)
12:15:33 <ttx> i.e. can we put ourselves in a strange corner if for some reason we publish one without the other ?
12:15:43 <SergeyLukjanov> ttx, and for some plugins you just need the centos image w/o any preparations
12:16:15 <ttx> because today you're around and I trust you to be around when we'll need to push -image-elements
12:16:44 <ttx> but we need to plan for the worst and make sure that the integrated release can continue to work even if you lose interest in release management
12:17:42 <SergeyLukjanov> ttx, it's fair
12:17:43 <ttx> but then, if the image-elements can be rebuilt from instructions that are provided with the main software...
12:18:21 <SergeyLukjanov> ttx, in fact we need tag in -image-elements just to mark the version of scripts
12:18:21 <dhellmann> ttx: I'm ready when you are
12:18:26 <ttx> I guess that's less of an issue
12:18:59 <ttx> SergeyLukjanov: could you remind me why they can't be put in sahara itself ? It's a size issue, right ?
12:19:34 <ttx> SergeyLukjanov: I think it's fine to ship separately as long as they can be regenerated from a script that we ship in sahara itself
12:19:44 <ttx> we clos ethe loophole then
12:19:50 <ttx> dhellmann: o/
12:19:58 <dhellmann> o/
12:20:02 <SergeyLukjanov> ttx, it was very long discussions with tons of pros and cons and eventually the pros number for keeping it as is were much bigger than others
12:20:31 <ttx> SergeyLukjanov: ok, we'll talk again about it -- I just want to make sure the integrated release is self-sufficient
12:20:55 <ttx> and not depending on something that nobody knows how to release
12:20:58 <ttx> except you :)
12:21:05 <SergeyLukjanov> ttx, yup, I got your point, I'll take a look on how could we couple sahara integrated release to -image-elements
12:21:11 <ttx> SergeyLukjanov: did you have a topic for today's meeting?
12:21:23 <SergeyLukjanov> ttx, I'm just pushing the tag to the repo :)
12:21:34 <SergeyLukjanov> ttx, I think no topics from my side for today
12:21:41 <ttx> ack
12:21:49 <SergeyLukjanov> ttx, thank you
12:22:23 <ttx> #topic Oslo
12:22:31 <ttx> dhellmann: sorry for the lateness
12:22:44 <ttx> https://launchpad.net/oslo/+milestone/juno-2
12:23:01 <dhellmann> ttx: no problem
12:23:19 <ttx> dhellmann: Looks good, expecting a lot more to emerge from -specs, or mostly complete ?
12:23:31 <dhellmann> we're a little slow approving our specs, but I think we have the process down now
12:23:46 <dhellmann> I have a list of a few of them to propose we accept at the meeting friday
12:23:57 <ttx> dhellmann: which makes me thing we need to decide on that rootwrap spec
12:24:03 <ttx> think*
12:24:26 <dhellmann> there are 2 rootwrap specs, do you mean the daemon mode one?
12:24:35 <ttx> tthe daemon one is not ready
12:25:01 <ttx> the ionice one I think is good to go as long as the doc clearly expresses the security tradeoff
12:25:13 <ttx> but that's slightly off-topic
12:25:24 <dhellmann> it looks like there has been an update on that one since you left your request
12:25:44 <ttx> dhellmann: yes, probably just waiting on me
12:25:45 <dhellmann> although there's a promise of more detail to come, as well, so that makes me think it's not done
12:25:52 <ttx> https://launchpad.net/oslo.messaging/+milestone/juno-2
12:26:01 <dhellmann> oh, no, that's "in the" implementation not "on the"
12:26:21 <ttx> same, looks good, if not a bit empty
12:26:49 <ttx> like i said earlier, with autokick removing stuff, we need to make sure no major feature flies under the release radar
12:27:09 <ttx> since we can't really rely on people adding them back to the milestone page anymore
12:27:20 <ttx> that's the downside of this approach
12:27:38 <dhellmann> yeah, I'll make sure as specs are approved their bps are updated with priority and target
12:28:50 <ttx> so.. would you say that the current state of the j2 pages shows 50% of what will finally get done ? 75% ?
12:29:24 <dhellmann> it is about 50% of what we said we would do, but we combined a few libraries so it may be closer to 75%
12:29:58 <dhellmann> some of the specs we have up for review weren't discussed at the summit, and some may not be approved
12:30:35 <ttx> No, I mean... not compared to summit plans. Do you think you'll add a lot of extra BPs to match late-approved specs, or not that much ?
12:30:39 <dhellmann> I expect to approve 3 more this week
12:30:45 <ttx> ok
12:30:53 <dhellmann> oh, yeah, we have a lot of specs that I expect to approve
12:31:04 <ttx> and those may still fall in j2, right
12:31:05 <dhellmann> like I said, we got a late start on that
12:31:10 <dhellmann> a few, yes
12:31:14 <dhellmann> the 3 certainly
12:31:19 <ttx> ok
12:31:38 <dhellmann> anything we approve for j3 will be a library we don't expect anyone to use this cycle
12:31:46 <ttx> ok
12:31:54 <dhellmann> I want to keep pushing ahead, so they are ready to be adopted early in k
12:32:03 <ttx> Anything you'd like to discuss at meeting today ?
12:32:13 <dhellmann> I have 4 alpha releases planned for early next week
12:32:28 <dhellmann> all are for libraries already in requirements, but I thought it would be good to give everyone a heads-up that they are coming
12:32:40 <ttx> does that mean that existing libs should have their juno features nailed by j-2 ?
12:32:41 <dhellmann> I'll tag them early monday, unless someone objects in the oslo meeting friday
12:33:06 <dhellmann> that's a good question
12:33:22 <ttx> It would kind of make sense overall
12:33:34 <ttx> if you expect consumers to use those new features...
12:33:49 <dhellmann> I'd like that. I'm not sure if I would cut anyone off, given the fact that we're always running a little ahead of the rest of the project.
12:34:16 <dhellmann> major features I could see holding
12:34:25 <ttx> #info Ideally, existing libraries should have their Juno featureset completed by j2
12:35:00 <ttx> OK, thats all I had
12:35:07 <ttx> anything on your side ?
12:35:12 <dhellmann> #info alpha releases of stevedore, oslo.config, oslotest, and oslosphinx planned for 23 June
12:35:24 <dhellmann> no, that's it
12:35:28 <ttx> cool! thx
12:35:30 <ttx> ttyl
12:35:32 <dhellmann> thanks!
12:36:19 <ttx> notmyname: as noted earlier, you can go at 13:45 UTC if you're interested. that's in 70min?
13:02:47 <notmyname> ttx: my alarm just went off. 13:45 (ie 6:45am pacific) is good with me
13:45:30 <ttx> notmyname: o/
13:46:05 <notmyname> ttx: hello
13:46:12 <ttx> #topic Swift
13:46:18 <ttx> notmyname: how are you doing ?
13:46:20 <notmyname> ttx: thanks for being flexible with the time
13:46:41 <notmyname> ttx: I'm mostly ok. surgery recovery is going pretty well so far :-)
13:47:40 <notmyname> ttx: I have the goal of merging storage policy patches today. reviews seem to be looking pretty good, and I'm hopeful that with today's time we can get it done
13:48:12 <ttx> notmyname: ok, you might want to push those security fixes in as well
13:48:37 <ttx> the VMT will just do a public OSSA once the patch is public
13:48:39 <notmyname> ttx: right. I expect those to be included as well. I've been working with tristanC on the right time
13:48:46 <notmyname> ttx: ah ok
13:49:00 <notmyname> ttx: so then it looks like I should be able to do that this afternoon
13:49:14 <ttx> there might be a few hours gap but I don't think that's critical in this specific case
13:49:26 <ttx> OK, I'll let tristanC know
13:49:57 <ttx> so you might have a RC1 SHA ready for tagging by eod ?
13:50:30 <ttx> fwiw I adjusted tools so that we support 2-step tagging in master for such Swift intermediary releases
13:50:32 <notmyname> that's the goal. at least working its way through jenkins
13:50:39 <notmyname> ok
13:50:50 <notmyname> ttx: meaning that we can do an RC tag and then a final
13:50:50 <notmyname> ?
13:50:52 <ttx> https://review.openstack.org/#/c/99892/
13:51:06 <ttx> swiftrc.sh pushes a RC1 tag and marks all bugs fixreleased on the final milestone
13:51:31 <notmyname> ok
13:51:35 <ttx> then milestone.sh specialcases swift and just tags/uploads tarball without going over bugs again
13:51:53 <ttx> (at final approval time)
13:51:58 <notmyname> ok
13:52:28 <ttx> the only difference with a classic milestone being, we push the RC1 tag and mark bugs fixreleased earlier
13:52:47 <ttx> a sort of lightweight milestone-proposed
13:53:12 <notmyname> ok. I think I follow that
13:53:53 <ttx> so if all goes well, we have a 2.0 milestone page, we tag 2.0-rc1 on master, push all FixCommitted bugs to FixReleased/2.0
13:54:11 <ttx> then when you bless it, we tag 2.0 on master, and upload the resulting tarball on that milestone page
13:54:16 <notmyname> ok
13:54:56 <ttx> If you need to fix something, we get fancy with a release branch, cut out of the RC1 tag
13:55:23 <notmyname> ok
13:55:32 <notmyname> that makes sense
13:55:35 <ttx> probably calling it milestone-proposed so that we get back on our feet with infra scripts
13:55:51 <ttx> but I shall soon push the patch so that we can call it proposed/*
13:56:02 <ttx> I think that works.
13:56:24 <ttx> so I'll wait for your SHA and run swiftrc.sh when I have it
13:56:35 <ttx> notmyname: we should probably create the milestone page now
13:56:42 <notmyname> I will get it to you as soon as I have it
13:56:44 <ttx> so you can start retroactively target BP to it
13:56:53 <notmyname> yes. can you create it in LP?
13:56:57 <ttx> 2.0.0 ?
13:57:00 <notmyname> yes
13:57:17 <ttx> i'll do it now
13:57:46 <notmyname> thanks
13:57:57 <ttx> https://launchpad.net/swift/+milestone/2.0.0
13:58:06 <ttx> so the tag would be 2.0.0.rc1
13:58:18 <notmyname> ok
13:58:22 <ttx> notmyname: anything else you wanted to discuss ?
13:58:38 <notmyname> nope. that's what I've got
13:58:41 <ttx> i'll complain about missing blueprints, but we can do that between RC1 and final :)
13:58:48 <notmyname> :_)
13:59:03 <ttx> anything you want to add to meeting agenda for today ?
13:59:29 <ttx> #info Swift 2.0.0.rc1 hopefully today or tomorrow
13:59:31 <notmyname> nothing specific
13:59:59 <ttx> notmyname: ok, cool. Do you get up early because you can't sleep ?
14:00:13 <ttx> Or some new routine?
14:00:29 <ttx> dolphm: around?
14:00:35 <notmyname> unfortunately today the answer is yes. normally its because of kids, though. I'm normally up between 6:30 and 7:00 on most days
14:00:49 <ttx> notmyname: ok, get better soon!
14:00:53 <notmyname> thanks :-)
14:01:23 <dolphm> ttx: o/
14:01:33 <ttx> #topic Keystone
14:02:14 <ttx> https://launchpad.net/keystone/+milestone/juno-2
14:02:19 <ttx> That's pretty raw
14:02:40 <ttx> Do you have more still baking in the -specs repo ?
14:02:40 <dolphm> juno-2 will be our first milestone which requires proposals to keystone-specs first
14:02:54 <ttx> do you think they will get out of there fast enough ?
14:02:59 <ttx> (to make j2) ?
14:03:32 <dolphm> i believe so
14:03:47 <dolphm> we have a 5 or 6 that are well rounded at this point
14:03:48 <dolphm> https://review.openstack.org/#/q/project:openstack/keystone-specs,n,z
14:04:18 <dolphm> last week we discussed how we want to work the approval process on that repo, which i think we'll finalize today and see a few land
14:04:19 <ttx> OK well, add them as they are approved, if they still make sense for j2.
14:04:50 <ttx> I /think/ in the end we'll have a one-milestone delay, like specs that are approved during j1 can be targetted to j2
14:05:05 <ttx> (except low-flying objects obviously)
14:05:23 <dolphm> i think we were thinking in that direction as well, but we're off to a later start than nova, for example
14:05:45 <ttx> yes, starting the process will always craete a delay/backlog/mess
14:05:56 <ttx> OK, so just add them as they are approved
14:06:15 <ttx> My script doesn't do miracles yet, since LP doesn't have a blueprint-cration API yet
14:06:27 <dolphm> s/yet// ?
14:06:39 <ttx> lifless convinced someone to work on that
14:06:47 <dolphm> oh alrighty then
14:07:07 <ttx> I think he is embarassed that it sucks so much :)
14:07:40 <ttx> or surprised.
14:07:43 <ttx> anyway
14:08:04 <ttx> i didn't have much in store for you. That autokick script basically makes sure the blueprint page looks good :)
14:08:19 <ttx> The trick being, to make sure it contains everything it should
14:08:30 <ttx> so keep an eye for feature sflying below the radar
14:09:01 <ttx> and make sure major ones are mentioned in the milestone page... even if they bypassed the spec process somehow
14:09:30 <ttx> dolphm: anything you wanted to add to today's meeting agenda ?
14:10:38 <dolphm> #info Support for compressed PKI tokens landed in keystone; we'd like to make them the default in keystone & devstack during Juno
14:10:52 <dolphm> just that ^
14:11:29 <ttx> ok, great!
14:11:55 <ttx> that's just for #info right, not for a discussion item ?
14:12:37 <dolphm> i don't believe so; if we suspect we might cause any pain (which i don't think is the case), i'll raise a discussion item
14:13:28 <ttx> dolphm: ack. ttyl then!
14:13:32 <dolphm> /salute
14:14:08 <ttx> jgriffith: ready when you are
14:33:12 <ttx> jpich: representing david today ?
14:33:30 <jpich> ttx: Yes, if needed!
14:33:31 * ttx doesn't see mrunge around
14:33:37 <ttx> jpich: you're in!
14:33:40 <ttx> #topic Horizon
14:33:56 <ttx> https://launchpad.net/horizon/+milestone/juno-2
14:34:31 <ttx> looks a bit too big and heavily needs prioritization and other improvements, but i'll annoy david with it rather than you
14:34:52 <jpich> I'm lucky :-) On the plus side a lot of it is up for review
14:35:51 <ttx> jpich: i wanted to go over the Gap coverage plan progress quickly
14:36:05 <ttx> https://wiki.openstack.org/wiki/Governance/TechnicalCommittee/Horizon_Gap_Coverage
14:36:21 <jpich> Ok
14:36:32 <ttx> Looking at it, only the misison statement is late
14:36:55 <ttx> is the horizon split still doable within juno-2 ?
14:37:32 <jpich> I think the mission statement has a proposal in it, not sure if it needs to be vetted before the item can be marked as complete?
14:38:09 <jpich> rdopieralski is currently doing a lot of work on the split, I think we're still hopeful it'll be doable within juno-2
14:38:10 <ttx> it should be proposed to the governance repo at some point
14:38:18 <ttx> ok
14:38:24 <jpich> Probably there'll be fresher news during the Horizon meeting later today
14:38:48 <ttx> what about your piece, "Integration Framework Tied to Gate" ?
14:39:14 <ttx> Is it still on track for j3 ?
14:39:53 <jpich> There's several folks currently submitting tests for review so I think it's chugging along nicely
14:40:09 <ttx> ok cool
14:40:13 <jpich> (we'd agreed with the Tempest folks back in HK to start this in our own repo since the tests will be very different from the API tests)
14:40:16 <ttx> That's all I had
14:40:22 <jpich> now I don't know when a testing effort can be considered "complete"
14:40:37 <ttx> yes, agreed
14:40:46 <jpich> So there'll be more by Juno-3 for sure :)
14:40:56 <jpich> I didn't have anything to bring up myself
14:41:02 <ttx> Anthing you or someone else on the Horizon team wanted to discuss at the cross-project meeting today ?
14:41:09 <jpich> Not that I'm aware of
14:41:24 <ttx> jpich: ok, let me know if that changes
14:41:30 <jpich> Ok
14:41:33 <ttx> jpich: thx for standing in !
14:41:38 <jpich> No problems! Cheers
14:41:40 <ttx> mestery: ready when you are
14:42:03 <mestery> ttx: o/
14:42:07 <ttx> #topic Neutron
14:42:26 <ttx> https://launchpad.net/neutron/+milestone/juno-2
14:42:28 <ttx> Looks good
14:43:05 <ttx> Did most of those go throug the -specs process ?
14:43:06 <mestery> thanks
14:43:23 <mestery> Yes, some are not approved and we're working on it
14:43:35 <mestery> I will bump those not approved over the next week
14:43:44 <ttx> mestery: wanted to quickly go though the Gap coverage plan, wince I will report progress at the TC meeting today
14:43:54 <mestery> ttx: Cool, I'm ready!
14:44:04 <ttx> https://wiki.openstack.org/wiki/Governance/TechnicalCommittee/Neutron_Gap_Coverage
14:44:23 <mestery> Want me to walk through each item?
14:44:43 <mestery> I was going to prepare an etherpad with progress, but traveling for LBaaS this week
14:45:19 <ttx> yes, quick walkthrough of progress maybe
14:45:51 <mestery> So, Gap 0 has a spec ready for approval: https://review.openstack.org/#/c/95738
14:46:00 <mestery> We have converged there, and coding has also started.
14:46:04 <ttx> ok
14:46:22 <mestery> Gap1: We have 1 API test left to merge, and new scenario tests are being written now (spec is in tempest -specs repo).
14:46:44 <mestery> Gap2 is being worked at the moment, I need to sync with the developer who's assigned to that this week.
14:46:56 <mestery> Gap3 has a patch waiting to be merged (Juno-3)
14:47:07 <mestery> Gap4: There was only one API call which was needed, a WIP patch is out for it.
14:47:23 <mestery> Gap5: We merged a few DVR patches, and more are being reviewed now. We should be landing the majority of them over the new few weeks.
14:47:28 <ttx> ok, so gap4 is late but it's shallow
14:47:33 <mestery> Gap4: Correct
14:47:54 <mestery> Gap6: We have a WIP patch in nova for an API there, and a spec for that should be proposed this week yet on the neutron side.
14:48:00 <ttx> gap5 should probably be retargeted to j2 then
14:48:01 <mestery> Gap7: I'll start that later in Juno-2.
14:48:07 <mestery> Correct
14:48:11 <ttx> feel free to edit that page
14:48:11 <mestery> So, that's a whirlwind update.
14:48:14 <mestery> OK, will do
14:48:59 <ttx> OK, looks like it's taking slightly more time, but still on track
14:49:09 <mestery> That's a fair assessment, yes.
14:49:22 <ttx> next on our busy 15-min, i wanted to talk about https://wiki.openstack.org/wiki/Blueprints#Neutron
14:49:28 <mestery> OK
14:49:43 <ttx> There is something there (and in nova and Oslo instructions) that doesn't work with autokick
14:49:56 <ttx> "Once your design specification has been committed to neutron-specs: "
14:50:04 <ttx> "Propose your blueprint, as above, by selecting the milestone in which you plan to complete the blueprint "
14:50:16 <mestery> OK, shall I remove that part?
14:50:17 <ttx> That will result in them getting punished by autokick
14:50:20 <mestery> :)
14:50:24 <ttx> My proposal is...
14:50:34 <ttx> we get rid of the whole "Once your design specification has been committed to neutron-specs: " section
14:50:53 <ttx> You as driver put the BP on the radar by adding milestone and priority
14:51:03 <mestery> Makes sense to me.
14:51:07 <ttx> then the assignee can update milestone and implementation status to reflect progress
14:51:10 <mestery> I've been doing that already anyways. :)
14:51:15 <ttx> i'll provide a script to do that in one step
14:51:26 <ttx> (including updating the link)
14:51:29 <mestery> OK
14:51:38 <ttx> so that shoud not be that much of a hassle
14:52:04 <ttx> Also would you mind if we collapsed the instructions for Nova/Oslo/Neutron ? they don't seem that much different now
14:52:16 <mestery> I am all for that actually, makes perfect sense.
14:52:36 <ttx> I'm rewriting the page following numerous complains that it advocates a behavior that I seem to punishg
14:52:44 <mestery> :)
14:53:09 <ttx> We'll still ask them to register the blueprint themselves though
14:53:16 <ttx> even if that's a bit bureaucratic
14:53:27 <ttx> it makes them the owner of the spec, which seems right
14:53:38 <ttx> (err... owner of the Bp)
14:54:05 <ttx> OK, tat went faster than I thought. That's all I had
14:54:09 <mestery> :)
14:54:13 <mestery> Same here, thanks ttx!
14:54:14 <ttx> anything you want to add to meeting agenda for today ?
14:54:19 <mestery> Nothing at this time, no.
14:54:49 <ttx> since we have a couple more minutes, could you quickly explain what the two essential blueprints are about ?
14:54:58 <ttx> Neturon Distributed Virtual Router for OVS
14:55:03 <ttx> Neutron DB Migration Refactor
14:55:11 <mestery> DVR is the functionality equivalent for nova multi-host
14:55:15 <ttx> the first one is the DVR thing that we ask in gap coverage right
14:55:17 <ttx> ok
14:55:18 <mestery> Right
14:55:26 <mestery> And the second one covers Gap0
14:55:39 <mestery> It's the spec for how we will move forward with DB migrations in neutron, the healing migration, etc.
14:55:44 <ttx> OK, that's clear
14:55:47 <mestery> cool
14:56:13 <ttx> I could have figured it out by reading them, but since we had one minute left...
14:56:21 <mestery> ;)
14:56:21 * ttx gets lazy with age
14:56:29 * mestery is the same way.
14:56:32 <ttx> mestery: thanks! ttyl
14:56:36 <mestery> thanks! Later.
14:56:53 <ttx> jgriffith: around now ?
14:58:46 <jgriffith> ttx: hola
14:58:54 <jgriffith> ttx: we should probably change my time :(
14:58:57 <ttx> #topic Cinder
14:58:59 <ttx> we should :)
14:59:02 <jgriffith> ttx: I'm driving in to the office more lately
14:59:07 <ttx> I have 2 minutes, let's be quick
14:59:08 <jgriffith> ttx: and it's screwing up our system
14:59:10 <jgriffith> k
14:59:13 <jgriffith> I'm good :)
14:59:16 <jgriffith> all set :)
14:59:21 <ttx> https://launchpad.net/cinder/+milestone/juno-2
14:59:31 <ttx> https://blueprints.launchpad.net/cinder/+spec/task-logging has no assignee ?
14:59:42 <jgriffith> harlow is working on it
14:59:48 <jgriffith> I'll update it to reflect correctly
14:59:51 <ttx> ok, you should assign it to him then
14:59:52 <ttx> ok
15:00:18 <ttx> Otherwise that's all cinder-specs-approved stuff ? Or there are a few direct adds ?
15:00:36 <jgriffith> Some are still direct carry overs from the pre-spec days
15:00:50 <ttx> Are you expecting much more to make it out of cinder-specs in time for j2 ?
15:00:51 <jgriffith> but I've been actively swatting those that have come in after
15:01:01 <jgriffith> ttx: I'm hoping for at least two more
15:01:04 <ttx> ok
15:01:14 <jgriffith> ttx: but honestly my prio right now is catch up on what's in the queue
15:01:26 <ttx> anything you want to add to meeting agenda ?
15:01:27 <jgriffith> if that doesn't happen I'll just stop accepting new things altogether
15:01:32 <jgriffith> nope, I"m good thanks
15:01:49 <ttx> ok, talk to you more next week
15:02:00 <ttx> we can discuss a better time for you too
15:02:22 <jgriffith> ttx: cool, sorry about that
15:46:37 <zaneb> o/
15:47:29 <ttx> zaneb: o/
15:47:32 <ttx> #topic Heat
15:48:30 <ttx> https://launchpad.net/heat/+milestone/juno-2
15:48:31 <zaneb> looks like we got through j-1 relatively unscathed :)
15:49:04 <ttx> The page looks good, but the autokick script might have been hard at work
15:49:16 <zaneb> I suspect so
15:49:34 <zaneb> ooh, I'm gonna move my first one to implemented
15:49:55 <ttx> zaneb: do you have a lot of work still stranded in -specs approval that you expect will be added here ?
15:49:55 <zaneb> patches finally merged
15:50:15 <zaneb> I don't think there's much, if anything, for j-2
15:51:05 <ttx> ok
15:51:06 <zaneb> https://review.openstack.org/#/q/status:open+project:openstack/heat-specs,n,z
15:51:14 <zaneb> actually, that's a longer list than I thought
15:51:22 * zaneb needs to do more reviews
15:51:45 <zaneb> but most of it is more long-term
15:51:58 <ttx> i was wondering... do you ask people to file a blueprint in parallel to filing a spec ?
15:52:05 <ttx> (like nova/neutron do ?)
15:52:34 <zaneb> no, I haven't been
15:52:51 <zaneb> and we haven't had any approved yet, so it's a bit academic at this point ;)
15:53:08 <ttx> hah
15:53:12 <zaneb> but I did have a question about that the other day, w.r.t. a Keystone spec
15:53:50 <zaneb> is it likely that a script will handle this in the future? or should I be encouraging people to create bps as well?
15:54:01 <ttx> Well the benefit of asking them to file the BP is... they are rightly marked as owning it, and then we can use a script to update all relevant fields at approval time
15:54:34 <ttx> I planned to ahve a BP-creation script but it's stalled due to lack of BP creation API in Launchpad
15:54:47 <ttx> so at this point, asking them to create the original BP is not a bad idea
15:54:58 <ttx> since THEN you can update all fields via the script i'll be providing :)
15:55:24 <zaneb> ok, cool. I'll go with that answer next time ;)
15:55:28 <ttx> It just.. feels wrong to ask them to file in two places.
15:55:40 <zaneb> yeah, it does a bit
15:55:51 <ttx> But then, their time is more expandable than yours, generally
15:55:57 <zaneb> specs repo should be _less_ work, ideally
15:56:08 <ttx> if someone needs to do it manually, better be them
15:56:21 <zaneb> I support that :D
15:56:23 <ttx> I just rewrote https://wiki.openstack.org/wiki/Blueprints
15:56:33 <ttx> to account for the new process, autokick script included
15:56:50 <zaneb> oh, nice
15:57:25 <zaneb> so when can we kill launchpad? ;)
15:57:58 <ttx> Working on it
15:58:10 <ttx> zaneb: anything you want to add to meeting agenda for today ?
15:58:24 <zaneb> nope, I'm good
15:58:44 <ttx> OK then, ttyl
15:58:53 <zaneb> thanks ttx o/
15:58:56 <ttx> no markwash yet
15:59:10 <ttx> no Nikhil either. Beer time!
16:02:27 <ttx> markwash: o/
16:02:40 <markwash> hi there
16:02:42 <ttx> #topic Glance
16:02:54 <ttx> https://launchpad.net/glance/+milestone/juno-2
16:03:21 <ttx> Small but consistent
16:03:40 <ttx> markwash: do you have a lot queued in -specs ?
16:03:53 <markwash> yeah, about 7 at this point
16:04:02 <ttx> Any of them likely to make juno-2 ?
16:04:16 <markwash> yes, at least one
16:04:21 <ttx> Do you have a stop date after which you'll stop considering them ?
16:04:36 <markwash> we didn't plan on anything like that
16:04:39 <ttx> ok
16:04:42 <ttx> that's fine
16:04:46 <markwash> we've just been trying to build our glance-specs review momentum so far
16:05:30 <ttx> markwash: i put the "gap coverage plan" on the TC agenda for today -- that's just about how you think you can address the small integartion testing gap that was called out last week
16:05:44 <ttx> we can delay it to next week, agenda is busy
16:05:53 <markwash> yes please, I was going to ask actually
16:05:55 <ttx> but it should be 3 lines on a wiki page
16:05:59 <markwash> oh
16:06:02 <ttx> markwash: OK, that works
16:06:26 <ttx> you might want to have a plan first (with an assignee) before you write those 3 lines :)
16:06:27 <markwash> I think those 3 lines are basically: add more glance tests to tempest in juno-2
16:06:38 <markwash> and then two lines of squiggles :-)
16:06:49 <ttx> yeah, something like that. With a "task owner" :)
16:06:50 <markwash> and hearts
16:06:55 <markwash> okay
16:07:03 <ttx> markwash: your call, we can defer to next week
16:07:13 <markwash> I asked around for volunteers at last team meeting, but made it sound like people needed to do it immediately and no one had time
16:07:23 <markwash> yeah, let's do next week
16:07:29 <ttx> immediately, no. Within juno would be good
16:07:38 <ttx> ok, moving to next meetign agenda
16:08:48 <ttx> what else...
16:09:10 <ttx> anything you'd like to put on cross-project meeting agenda ?
16:09:12 <markwash> I need to update the mission statement proposal again
16:09:24 <markwash> nothing for cross-project from me
16:09:35 <ttx> yes, we'll talk about it at the TC meeting
16:09:47 <ttx> so if you have a new version, better post it before
16:09:57 <ttx> i'l try to ask to cut the nitpikcing
16:10:15 <markwash> I'll see if I can take a pass, I didn't realize it was on the agenda for this week but I suppose that was very silly
16:10:33 <markwash> I have to prep for the ptl webinar as well
16:10:36 <ttx> it's up on the governance change list, so we try to cover it asap
16:10:43 <ttx> but as I said, it will be a busy meeting
16:10:45 <markwash> yeah, that's exactly what I should have expected
16:10:55 <ttx> so we might just skip it anyway
16:11:15 <ttx> we'll see how it goes
16:11:20 <markwash> that might also be best, I'll put in an update to the language sometime tomorrow or thursday in any case
16:11:54 <ttx> That's all I had. The -specs driven workflow certainly makes it simpler to sync between us.
16:11:57 * ttx hugs autokick.py
16:12:00 <markwash> haha
16:12:19 <ttx> markwash: ttyl!
16:12:24 <markwash> thanks
16:17:14 <ttx> SlickNik: o/
16:17:21 <SlickNik> o/
16:17:21 <ttx> #topic Trove
16:17:27 <ttx> https://launchpad.net/trove/+milestone/juno-2
16:17:57 <ttx> SlickNik: so you should set a priority for those 4 "undefined" things, if you want to bless them
16:18:17 <ttx> if not, you should clear their milestone target field so that they don't mess up our view
16:18:40 <ttx> Otherwise looks good
16:18:53 <SlickNik> ttx: Okay will probably do that today.
16:19:19 <SlickNik> Along with bug triage, which I haven't had a chance to do this week, as yet.
16:19:41 <SlickNik> Lot more BPs, and we're making some good progress in juno-2.
16:20:55 <ttx> would you say your j-2 plans is accurately representing what you plan to accomplish for j2 ?
16:20:55 <SlickNik> A couple of them marked not-started have actually begun, so I'll take an action to update the list to better mirror actual progress.
16:21:20 <ttx> OK, wanted to talk about progress on your gap coverage plan
16:21:29 <ttx> https://wiki.openstack.org/wiki/Governance/TechnicalCommittee/Trove_Gap_Coverage
16:21:47 <ttx> Could you quickly go through it and tell me about progress, if any ?
16:22:18 <SlickNik> We've made really good progress to Concern #1.
16:22:54 <SlickNik> We're looking at integration tests right now, and neutron support might actually merge early (in Juno 2).
16:23:10 <ttx> cool!
16:23:35 <SlickNik> We made a bit of progress on the doc front (i.e. updates to the deploy doc), but we still have more work to do here.
16:24:01 <SlickNik> I'm going to take on some of it, and get a couple of other cores to help.
16:24:45 <SlickNik> Will try to get a good chunk done in Juno-2, but I suspect we'll probably need to keep working on docs even past that (through Juno 3)
16:25:20 <SlickNik> For concern #3: We've got a patch for an experimental job in CI infra out already.
16:25:58 <SlickNik> Once that merges, we're going to iron out kinks in it, and look to make it gating.
16:26:18 <SlickNik> And once that happens, we can turn off the old reddwarf-ci
16:26:56 <SlickNik> Review for the experimental job I mentioned
16:26:58 <SlickNik> #link https://review.openstack.org/#/c/98517/
16:28:06 <SlickNik> For Concern #4, I've been working with amcrn and cp16net and we've been doing a good job on staying on top of triage, and process.
16:29:32 <SlickNik> So a couple of main pushes for Juno 2 for us will be around focusing on Concerns #1, and #2.
16:30:53 <ttx> ok
16:31:38 <ttx> I think we can consider #4 done
16:31:49 <ttx> it's more of a policy thiung
16:32:01 <ttx> what about #5 ?
16:33:25 <SlickNik> I alluded to #5 earlier, out of order (sorry!).
16:33:35 <SlickNik> #link https://review.openstack.org/#/c/88349/
16:33:53 <SlickNik> It's close to being done.
16:34:39 <SlickNik> annashen is debugging a couple of failing tests
16:35:47 <SlickNik> But once that's fixed (i.e. the tests are passing) the patch looks in good shape, and we're on track to get that merged for Juno 2
16:36:38 <ttx> oops sorry
16:36:42 <ttx> parallelizing discussions.
16:37:13 <ttx> OK so overall, takes more time than expected but still on track for Juno
16:37:21 <SlickNik> Not a problem. :)
16:37:25 <ttx> SlickNik: feel free to adjust milestone targets on that wiki page
16:37:28 <SlickNik> Yes, that's a good summary.
16:37:40 <ttx> SlickNik: i'll report on your behalf to the TC
16:37:50 <ttx> SlickNik: anything you want to add to meetign agenda for today ?
16:38:19 <SlickNik> ttx: Awesome, thanks. When will the report be? I'll try and be there too, in case anything something comes up.
16:38:59 <ttx> 20:00 utc meeting
16:39:03 <ttx> (TC meeting)
16:39:14 <SlickNik> Ah, today. sounds good!
16:39:35 <SlickNik> ttx: Nope. I'm trying to push out a client release sometime this week with all the bugfixes we've done for juno-1.
16:39:54 <ttx> #info trying to push out a client release sometime this week with all the bugfixes we've done for juno-1
16:40:06 <ttx> ok then... releasing you. ttyl :)
16:40:17 <ttx> #endmeeting