08:41:33 <ttx> #startmeeting ptl_sync
08:41:33 <openstack> Meeting started Tue Jun 10 08:41:33 2014 UTC and is due to finish in 60 minutes.  The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot.
08:41:34 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
08:41:36 <openstack> The meeting name has been set to 'ptl_sync'
08:41:39 <ttx> #topic Nova
08:41:57 <ttx> #link https://launchpad.net/nova/+milestone/juno-1
08:42:22 <ttx> Page looks good, progress -- not so good
08:42:26 <mikal> So, we've had some gate problems which are making things more exciting
08:42:31 <ttx> no kidding
08:42:35 <johnthetubaguy> yeah, agreed, its not so different from last week
08:42:48 <mikal> I see "needs code review" as a good sign there
08:42:52 <ttx> At this point we should probably reduce to the stuff that is already approved an in flight
08:42:55 <mikal> i.e. at least there's some code
08:43:01 <ttx> and*
08:43:05 <johnthetubaguy> yeah, I think its trimming time
08:43:12 <mikal> sdague asked for some more logging in nova-network, so I've been working on that
08:43:20 <mikal> It _might_ help nail down some gate problems
08:43:22 <ttx> mikal: We need to tag sometimes between now and Thursday
08:43:25 <johnthetubaguy> there are lots of −1ed (for a good reason) patches
08:43:38 <johnthetubaguy> so those go to j-2 right?
08:43:48 <mikal> Yeah
08:43:54 <ttx> If we trim the list to the "good ones that just need a bit more hours to pass the gate I think that's a resasonable objective
08:44:00 <mikal> Given the state of the gate, I feel like if things aren't reviewing well they're not going to make it
08:44:08 <ttx> agreed
08:44:08 <johnthetubaguy> agreed
08:44:17 <johnthetubaguy> OK, I can sort out the list
08:44:22 <mikal> Unless the j-1 date might move because of the gate?
08:44:29 <mikal> Thanks johnthetubaguy
08:44:38 <ttx> mikal: no, I don't think that would change anything
08:44:47 <mikal> Ok, just checking
08:45:27 <ttx> johnthetubaguy: so let's just keep in list stuff that is approved and in-flight, or almost approved
08:45:34 <ttx> that way we can trigger the tag when all those merge
08:45:46 <mikal> ttx: what's the process for tagging?
08:45:49 <mikal> Do you do that or do I?
08:45:51 <johnthetubaguy> ttx: sounds good, will sort that
08:46:08 <ttx> mikal: I do it, you just give me a SHA (or an algorithm to determine it)
08:46:15 <ttx> like "when that merges"
08:46:19 <mikal> Ok
08:46:38 <mikal> We can do that interactively on IRC
08:46:47 <ttx> yes we can
08:47:09 <ttx> mikal: on the bugs side...
08:47:21 <mikal> Yeah, I got a bit upset about that last week
08:47:22 <ttx> I guess we should applythe same logic
08:47:31 <mikal> I'm going to assume you didn't see the nova meeting last week
08:47:38 <ttx> let's keep only stuff that is already in-flight + milestone-critical stuff
08:47:43 <mikal> I agree for targetted bugs for j-1
08:47:51 <ttx> and move everything else to j-2
08:47:53 <johnthetubaguy> mikal: correctly upset though
08:47:56 <mikal> However, we have a pretty big bug problem in general, with our 1,200 bugs
08:48:11 <johnthetubaguy> mikal: we need to teach people to stop targeting bugs, people do it to get more reviews it seems?
08:48:39 <mikal> Oh, that hadn't occurred to me as a thing people would do, but it makes sense now that you say it
08:48:42 <johnthetubaguy> I kinda like reserving targeting for these last few days, and major bloopers
08:48:44 <ttx> mikal: so, about bugs
08:49:03 <mikal> There was some brain storming in the nova meeting last week about bug automation
08:49:04 <ttx> once issue is that they serve two purposes: task tracking (for devs) and bug report (for users)
08:49:07 <mikal> Which you probably have thoughts on
08:49:23 <ttx> the first category usually is well-maintained
08:49:30 <ttx> the other category is usually mostly ignored
08:49:48 <mikal> Yeah, I feel like ignoring user bugs is a really bad user experience
08:49:55 <mikal> But we do it a lot
08:50:02 <mikal> And digging out of this backlog is going to be hard
08:50:27 <ttx> Quite often, devs file bug when they fix something, but the bug actually was reported before by a user, and then if we are lucky we find the dupe
08:50:34 <johnthetubaguy> (sub category: bugs a dev raise because a user reported it to them)
08:50:42 <ttx> and then there is the targeting issue
08:50:46 <mikal> ttx: that is true
08:50:49 <johnthetubaguy> ttx: +1
08:50:55 <mikal> I am very sure there are dupes and already fixed things in there
08:51:01 <mikal> But we can't find them because there's so many
08:51:06 <ttx> Which is mostly because we have a single-dimensional priority/targeting system
08:51:19 <ttx> so there is no way for, say, the vmware folks to have their priority list
08:51:22 <mikal> I think its also because we have a cultural problem to be honest
08:51:29 <mikal> We have a lot of work on features, but not a lot on bug fixes
08:51:35 <ttx> so they abuse the milestone target to do it
08:51:39 <mikal> I think we need to talk about how to incent the behaviour we want
08:52:09 <ttx> we are trying to fid ways to have multiple priorities/targeting/tasklists in storyboard so that parallel groups can all express that
08:52:10 <mikal> I think we're talking about two different things here
08:52:21 <ttx> but it's more complex than it seems
08:52:21 <johnthetubaguy> mikal: quite a few "features" are looking to fix "systemic" bugs, but it does feel that way
08:52:23 <mikal> But I agree with you that something richer than LP would help
08:52:45 <ttx> mikal: basically we need people to be able to create arbitrary, sorted lists of bugs/tasks
08:52:48 <mikal> johnthetubaguy: sure, but those need to go and close the reported bugs they resolve as well
08:53:16 <ttx> the "release" one (which corresponds to the milestone target list) would just be one
08:53:26 <mikal> ttx: that would be nice
08:53:28 <ttx> anyway, that's long-term
08:53:36 <mikal> Although it doesn't help actually close bugs faster than we do now
08:53:39 <johnthetubaguy> mikal: need to go? agreed, the bugs should get closed that are related, but they are hard to find now, but lets take this offline
08:53:41 <mikal> It just makes them more organized
08:53:44 <ttx> in the short term, you should own the milestone target
08:53:57 <ttx> if someone else's use of it renders it useless for you...
08:53:59 <mikal> Agreed
08:54:05 <ttx> then you should encourage them to use a tag instead
08:54:17 * johnthetubaguy nods with approval
08:54:19 <ttx> like vmware-j1-list
08:54:32 <ttx> it's a bit dirty but will do the trick
08:54:38 <mikal> Ok
08:54:55 <ttx> that said, i'm fine with keeping them in the milestone list, at least until we near milestone tag
08:55:03 * johnthetubaguy likes the tag alternative
08:55:09 <ttx> it's just a bit painful to clean up now
08:55:25 <mikal> johnthetubaguy: are you happy to do the cleanup or shall I?
08:55:44 <johnthetubaguy> mikal: you should sleep, and fix logging, I can take the first stab
08:56:05 <mikal> johnthetubaguy: ok, thanks
08:56:07 <ttx> #info milestone and bugs should be reduced to in-flight stuff (with reviews already approved) and we plan to tag when all that backlog merges
08:56:30 <johnthetubaguy> mikal: assuming you check the j-1 list tomorrow, to keep me honest
08:56:39 <mikal> johnthetubaguy: I can do that
08:56:41 * mikal makes a note
08:56:42 <ttx> If anything is just shy of one core review, it might make sense to do it now to keep it in list
08:56:56 <johnthetubaguy> ttx: you are reading my mind
08:57:34 <johnthetubaguy> at least that was my plan yesterday, but I ran out of work hours
08:59:02 <ttx> Once the list is refined we'll track how fast we burn it
08:59:02 <johnthetubaguy> ttx: duno if you have anything more from your side, but how is *-specs looking to you at this point?
08:59:28 <mikal> Do we want to have a quick meeting 24 hours or so before the deadline to review state of play?
08:59:32 <ttx> johnthetubaguy: it seems to result in cleaner objectives
09:00:14 <johnthetubaguy> ttx: thats true, just worried about the speed, we now have a specs backlog, so the quick spec reviews are hard to find, sigh
09:01:10 <ttx> Looking at the juno roadmap now...
09:01:19 <johnthetubaguy> looking forward to those multi-dimentional priorities, so we have spec review priority
09:01:27 <ttx> juno-2 and juno-3 are full with unprioritized blueprints
09:01:49 <johnthetubaguy> ttx: they are not approved, should be no unapproved that have been accepted into juno
09:01:54 <ttx> so if I were to enable my autokick script it would remove most of them
09:02:06 <johnthetubaguy> ah, thats a good point
09:02:33 <ttx> trying to see what would work best
09:02:34 <johnthetubaguy> I was looking at this list: https://blueprints.launchpad.net/nova/juno
09:02:37 <mikal> johnthetubaguy: priority of undefined == unapproved?
09:02:42 <johnthetubaguy> the unapproved ones just don't have code yet
09:02:48 <mikal> i.e. you always set a priority?
09:03:07 <johnthetubaguy> mikal: well, not been setting a priority until the get approved, unless its super high priority
09:03:11 <ttx> mikal: we use priority as a way to say that you blessed it
09:03:29 <mikal> Ok
09:03:32 <johnthetubaguy> mikal: talking of which, we need to be better at setting those, I am being a bit arbitrary at the moment
09:03:35 <ttx> which is why my script proposes to remove target milestone from anythign that has no prio
09:03:38 <mikal> j-2 also has way too much from one developer
09:03:43 <johnthetubaguy> mikal: but lets take that offline
09:03:48 <mikal> johnthetubaguy: ok
09:04:19 <ttx> johnthetubaguy: it seems your workflow is slightly different though
09:04:36 <ttx> you use unprioritized as a queue of stuff that might get approved
09:05:02 <johnthetubaguy> ttx: I was doing, I gave up, people keep adding stuff into milestones, maybe just run your script?
09:05:36 <ttx> let me pastebin what it would do
09:05:40 <mikal> Yeah, if you're setting values which stop the script from kicking the stuff we've approved, then run the script
09:06:45 <ttx> the script just removes unprioritized stuff (assumes it's been added by someone else) and just adjusts series goal to match
09:06:46 <ttx> http://paste.ubuntu.com/7622514/
09:07:26 <mikal> A quick scan makes me think those changes would be ok?
09:07:55 <johnthetubaguy> the setgoal, I guess we approved those specs now?
09:07:57 <ttx> I can run it now, then I'll enable it to ru every ~2 hours to keep it ok
09:08:30 <ttx> "setgoal" is when the spec is targeted to juno-X but has no series goal (juno) set. So it's missing from the https://blueprints.launchpad.net/nova/juno page
09:08:38 <ttx> yay LP consistency
09:08:51 <ttx> the script enforces that consistency
09:08:58 <johnthetubaguy> ah, I see, cool
09:09:05 <johnthetubaguy> ttx: go for it I think
09:09:24 <ttx> mikal: you ok with all these ?
09:09:29 <mikal> Yes
09:09:41 * ttx removes --dryrun
09:09:50 <johnthetubaguy> sweet, thanks
09:10:02 <ttx> we'll see how many people complain
09:10:15 <ttx> the script leaves a note in the whiteboard when it kicks a blueprint out
09:10:22 <mikal> Heh
09:10:25 <mikal> Someone will always complain
09:10:54 <johnthetubaguy> +1
09:11:10 <johnthetubaguy> well the fourth time it gets kicked out they may ask questions
09:11:27 <johnthetubaguy> ttx: you can tell them to bug me in the message, if thats helpful?
09:13:42 <ttx> fixing a small bug in my script, sorry for the wait
09:13:55 <ttx> johnthetubaguy: no that's fine
09:14:02 <ttx> mikal: anything else ?
09:14:09 <johnthetubaguy> ttx: no problem, nothing like our crazy work queue to test things :)
09:14:10 <mikal> Not that I can think of
09:14:15 <ttx> example message: https://blueprints.launchpad.net/nova/+spec/remove-compute-flavors-to-flavor-object
09:14:21 <mikal> I'd like to talk one day about general ways to get more bugs fixed in nova
09:14:26 <mikal> But that doesn't have to be today
09:14:31 <mikal> j-1 is a bigger priority this week
09:14:44 <ttx> (see whiteboard)
09:14:56 <ttx> mikal: agreed
09:15:08 <johnthetubaguy> ttx: perfect
09:15:14 <ttx> johnthetubaguy: ping me when you cleaned up the j-1 lists
09:15:24 <johnthetubaguy> ttx: will do
09:15:24 <ttx> so that I get an idea of how much we are waiting on
09:15:31 <johnthetubaguy> cool
09:15:35 <mikal> Sounds good
09:15:41 <mikal> And I will take a look at j-1 tomorrow as well
09:15:48 <mikal> But I really appreciate your effort johnthetubaguy
09:15:53 <ttx> we might need to readjust goals depending on how today runs in the gate
09:16:04 <ttx> johnthetubaguy is the awesome
09:16:08 <johnthetubaguy> mikal: thanks, appreciated
09:16:12 <mikal> Yeah, I am assuming the gate will be a mess this week
09:16:13 <mikal> :)
09:16:15 <johnthetubaguy> ttx: :)
09:16:23 <mikal> (To johnthetubaguy, not the gate)
09:16:35 <johnthetubaguy> lol
09:17:30 <mikal> So, I guess that's it for this week's 1:1
09:17:33 <mikal> Well, really 1:2
09:17:39 <mikal> We're ganging up on you
09:18:37 <johnthetubaguy> ttx: catch you in a bit once j-1 is cleaned up
09:19:41 <mikal> ttx: do you endmeeting these, or is this done and I can wander off?
09:21:03 <ttx> mikal: you can wander. We'll close it when all ptl syncs are done today
09:21:17 <mikal> OK cool
09:21:20 <mikal> Thanks guys
09:21:22 <mikal> Talk more later
09:21:32 <johnthetubaguy> aww, juno-2 looks much better now :)
09:21:40 <johnthetubaguy> catch you later
11:27:58 <johnthetubaguy> ttx: quick heads up, juno-1 list is in better shape now, in some ways, in other ways it looks empty, https://launchpad.net/nova/+milestone/juno-1
11:29:29 <johnthetubaguy> we may need to punt more, but there is still some hope the remaining bits might get reviewed in time
11:30:39 <ttx> johnthetubaguy: if anything accidentally makes it, we can switch the target back to j-1
11:39:25 <sdague> johnthetubaguy: realistically consider it a 12 hr minimum delay after approve to land
11:44:33 <eglynn> ttx: o/
11:44:48 <eglynn> ttx: ... ceilo up now?
11:45:01 <eglynn> #link https://launchpad.net/ceilometer/+milestone/juno-1
11:45:16 <eglynn> we're not in too bad a shape for juno-1
11:45:36 <eglynn> hbase-events-feature should land, modulo the gate slowness that sdague refers to above ^^^
11:45:43 <ttx> eglynn: o/
11:45:48 <ttx> #topic Ceilometer
11:45:59 <ttx> #link https://launchpad.net/ceilometer/+milestone/juno-1
11:46:05 * eglynn pastes ...
11:46:10 <eglynn> we're not in too bad a shape for juno-1
11:46:15 <eglynn> hbase-events-feature should land, modulo the gate slowness that sdague refers to above ^^^
11:46:27 <eglynn> (... two patches just landed BTW that should help with the high failure rate in the ceilo units)
11:46:38 <eglynn> concerned about hbase-resource-rowkey-enhancement BP
11:46:46 <ttx> eglynn: are the 3 remaining blueprints approved and in-flight, or still needing approvals ?
11:47:08 <eglynn> one related patch already landed for hbase-resource-rowkey-enhancement ... https://review.openstack.org/78244
11:47:16 <eglynn> but the main one is a bit stalled https://review.openstack.org/87249
11:47:25 <eglynn> will prolly have to bump the BP if there isn't significant traction by EoD
11:47:36 <eglynn> concerned also about grenade-upgrade-testing
11:47:44 <eglynn> ... it turns out all the changes are on the grenade side
11:47:48 <ttx> yeah, ideally we should only have in-flight stuff ny eod, given the gate backlog
11:48:07 <eglynn> k ... the grenade review is stalled due to lack of reviewer bandwidth
11:48:26 <eglynn> ... I've reached out to sdague and dtroyer about this, and Sean is fully loaded with gate fire-fighting
11:48:38 <sdague> eglynn: I just approved it through
11:48:38 <eglynn> ... Dean *may* be able to help though when he comes on-line
11:48:42 <ttx> can be early j-2
11:48:45 <eglynn> sdague: good man! :)
11:48:51 <eglynn> sdague: thank you sir!
11:49:08 <sdague> no prob
11:49:20 <ttx> eglynn: OK, let's keep those last 3 in
11:49:33 <ttx> and we'll adjust early tomorrow
11:49:45 <ttx> let's try to tag sometimes tomorrow to not stretch on Thursday
11:49:49 <eglynn> ... so the main concern is then really only hbase-resource-rowkey-enhancement, I'll circle back with Nadya on that
11:49:52 <eglynn> yep aggred
11:49:55 <eglynn> *agreed
11:49:59 <ttx> eglynn: on the bugs side...
11:50:14 <eglynn> bugs are mainly good, I gave the commit log another sweep for untarget'd bugs that have fixes already landed
11:50:28 <eglynn> ... I think the 3 in-progress bugs should be landable
11:50:46 <ttx> #info 3 remaining BPs, hbase-events-feature in-flight, hbase-resource-rowkey-enhancement a bit stalled, grenade-upgrade-testing dependent on grenade resources
11:51:08 <ttx> eglynn: how are their reveiws looking ?
11:51:23 <eglynn> this bug is low priority, so would not loose sleep if I had to punt it ... https://bugs.launchpad.net/ceilometer/+bug/1293337
11:51:42 <eglynn> on reviews, I'm pushing the cores to concentrate on juno-1 target'd stuff today
11:52:07 <ttx> OK, I propose we punt to j-2 anything that's not approved and in-flight in gate by EOD
11:52:19 <eglynn> ... the backlog of post-juno1 reviews can wait until after the j1 tag is cut
11:52:25 <eglynn> yep, agreed on that
11:52:26 <ttx> #info Will punt to j-2 anything that's not approved and in-flight in gate by EOD
11:52:46 <ttx> #Shooting for tagging on Wednesday
11:52:50 <ttx> #info Shooting for tagging on Wednesday
11:53:09 <eglynn> cool, juno-2 planning starts at weekly meeting on Thurs
11:53:27 <eglynn> ... so would be good to have juno-1 in the bag on Wednesday
11:53:37 <ttx> Looking at what would happen if I ran my autokick script on juno BPs now
11:53:48 <eglynn> k
11:53:49 <ttx> eglynn: http://paste.ubuntu.com/7623122/
11:54:15 <eglynn> SETGOAL means?
11:54:19 <ttx> so there would be two juno-3 BPs that we would remove from milestone target
11:54:30 <ttx> *GOAL means adjusting series goal
11:54:43 <ttx> i.e. the "series goal" field in the BP
11:54:54 <eglynn> a-ha I see
11:55:02 <ttx> which can be out of sync with milestone, due to lack of LP consistency between those fields
11:55:21 <ttx> so the *GOAL actions just adjust series goal based on milestone target value
11:55:47 <eglynn> OK I'll chase down those BPs, get my i's dotted and t's crossed
11:55:59 <ttx> eglynn: should I run the script now ? It will remove the milestone target and add a message on the whiteboard about removal of unprioritized BPs
11:56:19 <eglynn> ttx: yep, let's give it a whirl
11:56:38 <eglynn> ttx: ... only the BPs in your paste will be impacted, right?
11:56:45 <ttx> yes
11:56:54 <eglynn> BTW I just fixed the series goal on grenade-upgrade-testing
11:57:01 <ttx> See for example now: https://blueprints.launchpad.net/ceilometer/+spec/instance-per-disk-measurement
11:57:54 <ttx> milestone was cleared and message was added to Bp whiteboard
11:58:04 <eglynn> cool, looks reasonable
11:58:28 <ttx> OK, we'll discuss automating the script run every 2/3 hours at the meeting today
11:58:41 <ttx> Anything you'd like to add to the meetign agenda for today ?
11:58:42 <eglynn> yep, that sounds like a plan
11:58:49 <eglynn> nothing specific
11:59:17 <ttx> eglynn: basically, te script ensures that only the BPs that you blessed (with a priority set) show up in those milestone plans
11:59:35 * SergeyLukjanov lurking
11:59:49 <ttx> hence tuyrning them into real project drivers roadmap, rather than a mix-and-match for stuff loosely proposed by people
12:00:13 <ttx> ideally that should result in way less time spent fixing those
12:00:30 <ttx> eglynn: anything else ?
12:00:38 <eglynn> ttx: so effectively we need to start seeding the practice of folks ...
12:00:43 <eglynn> (a) not filing BPs in LP until the corresponding spec has landed
12:00:44 <eglynn> and:
12:01:06 <eglynn> (b) not setting the "milestone target unless the blueprint has been properly prioritized by the project drivers"
12:01:26 <ttx> eglynn: right. i actually work on a script to automate blueprint creation from spec -- so that you (the project drivers) can do it with limited work
12:01:26 <eglynn> ^^^ are those the two main process changes that'll be visible to most folks?
12:01:36 <eglynn> ttx: excellent!
12:01:44 <ttx> you could even consider that filing a BP is a drivers job
12:01:53 <ttx> all people should have to do is file a spec
12:01:56 <eglynn> yeah, that would make sense
12:02:10 <ttx> eglynn: work is a bit delayed since damn Lp doesn't have an API for creating BPs
12:02:18 <ttx> so I have to leverage the webclient
12:02:24 <ttx> fun.
12:02:37 <ttx> ok, shara time
12:02:38 <eglynn> sounds messy ;)
12:02:42 <ttx> #topic Sahara
12:02:45 <ttx> eglynn: thx!
12:02:47 <ttx> SergeyLukjanov: o/
12:02:57 <SergeyLukjanov> ttx, hey!
12:03:02 <SergeyLukjanov> #link https://launchpad.net/sahara/+milestone/juno-1
12:03:21 <ttx> #info 2 blueprints left
12:03:28 <SergeyLukjanov> so, only changes that are now in gate are in the mp
12:03:38 <SergeyLukjanov> milestone*
12:03:39 <ttx> cool
12:03:48 <ttx> SergeyLukjanov: including for bugs ?
12:03:51 <SergeyLukjanov> yup
12:03:56 <ttx> that's how I like it
12:04:09 <ttx> Let's shoot for tagging when that is merged
12:04:21 <ttx> #info All targeted changes are in-flight in the gate
12:05:02 <ttx> SergeyLukjanov: so let me see what autokick would do to your blueprints
12:05:05 <SergeyLukjanov> ttx, I'm monitoring their progress and send you confirmation when all changes will be landed
12:05:24 <SergeyLukjanov> ttx, ok
12:05:44 <ttx> http://paste.ubuntu.com/7623169/
12:05:57 <ttx> It would kick 4 blueprints out of j-2
12:06:45 <ttx> You migth want to check if those are covered by approved specs or if you want to let them fly in below radar
12:07:11 <ttx> and/or let me just run the script now
12:07:11 <SergeyLukjanov> ttx, okay, I'll check them
12:07:46 <ttx> Goal being to try to enable te script to run automatically every 2/3hours
12:08:11 <ttx> #action Sergey to check the 4 j-2 blueprints that would get kicked out of j-2 if autokick was enabled
12:08:31 <ttx> SergeyLukjanov: anything you'd like to add to the meeting agenda ?
12:08:47 <SergeyLukjanov> ttx, you could start the script, I'll return back bps to j2 if needed
12:09:02 <SergeyLukjanov> our specs-related stuff is on review
12:09:15 <ttx> ok, running script
12:09:30 <ttx> See effect at: https://blueprints.launchpad.net/sahara/+spec/cluster-secgroups
12:09:35 <SergeyLukjanov> it's not going very fast, the prev. week was hadoop summit => decreasing review speed and not so good quorum
12:09:59 <SergeyLukjanov> ttx, ack
12:10:13 <SergeyLukjanov> ttx, so, it resets milestone and series
12:10:20 <ttx> yes
12:10:32 <ttx> I shall add it to the release tools at some point
12:10:37 <ttx> hmm, that makes me think...
12:11:19 <ttx> Could use your quick review on https://review.openstack.org/#/c/98123/
12:11:30 <ttx> Before I self-approve myself
12:11:32 <SergeyLukjanov> ttx, looking
12:12:58 <ttx> SergeyLukjanov: it's the script I'll use for milestone tagging this week
12:13:59 <SergeyLukjanov> ttx, now parsing (((release_date.month % 11) + 2) / 7) + 1
12:14:11 <ttx> fun uh
12:14:20 <ttx> I'll probably wait for at least one tag to be successfully run with it before APRVing it
12:14:48 <SergeyLukjanov> ttx, what's about testing it on sandbox?
12:15:01 <ttx> SergeyLukjanov: I'll probably change it so that it parses 'J' as the a year.seq thing, rather than the milestone date
12:15:14 <ttx> it seems less error-prone
12:15:26 <SergeyLukjanov> sounds good
12:15:38 <SergeyLukjanov> the scripts looks good so far
12:15:53 <ttx> SergeyLukjanov: yeah, i'll ping you again when ms2version uses alphabet rather than publication dates
12:16:22 <SergeyLukjanov> ttx, ok, I'll take a look on it after change
12:16:53 <ttx> SergeyLukjanov: which TZ are yo uin currently ?
12:17:00 <ttx> dhellmann: around?
12:17:02 <SergeyLukjanov> ttx, UTC+4
12:17:09 <ttx> ok, back home I see
12:18:20 <SergeyLukjanov> ttx, yup
12:18:31 <ttx> SergeyLukjanov: cool. Anything else ?
12:18:51 <SergeyLukjanov> ttx, oh, one more thing
12:19:07 <SergeyLukjanov> we're now in progress of merging sahara-dashboard to horizon
12:19:33 <SergeyLukjanov> mostly all needed patches are on review, but it's lack of review to make it merged
12:20:51 <SergeyLukjanov> so, we're now blocked by lack of reviews, I hope that it'll be better during the juno-2 or we'll need to rollback to the sahara-dashboard for juno
12:21:42 <SergeyLukjanov> #link https://review.openstack.org/#/q/topic:bp/merge-sahara-dashboard,n,z
12:23:07 <ttx> SergeyLukjanov: I think it's fair to raise that in the meeting
12:23:25 <ttx> Cross-project priority communication is what it's for
12:23:45 <SergeyLukjanov> ttx, yup, thanks
12:24:07 <SergeyLukjanov> oh, last 3 changes failed in gate with not sahara-related issues, rechecking now...
12:24:10 <ttx> SergeyLukjanov: add it just before "open Discussion" at https://wiki.openstack.org/wiki/Meetings/ProjectMeeting#Agenda_for_next_meeting
12:24:22 <SergeyLukjanov> ttx, ack
12:29:10 <SergeyLukjanov> ttx, btw, we should have 2014.1.1 today, final testing atm
12:30:11 <SergeyLukjanov> ttx, I've updated the lp page for sahara j1
12:30:26 <SergeyLukjanov> ttx, we're only waiting for https://review.openstack.org/#/c/94460/ to be landed
12:31:36 <ttx> ok
12:46:22 <ttx> SergeyLukjanov: OK, simplified version @ https://review.openstack.org/#/c/98123
12:47:54 <SergeyLukjanov> ttx, looking
12:48:31 <ttx> This version of ms2version.py will work even if the release date is not defined, and for RCs
12:51:26 <SergeyLukjanov> ttx, yup, I've tested it on sahara milestones and works good
12:51:55 <SergeyLukjanov> ttx, +1 from me
12:52:36 <ttx> coolthx
14:00:08 <ttx> dolphm: ready when you are
14:00:32 <dolphm> ttx: o/
14:00:41 <ttx> #topic Keystone
14:00:55 <ttx> #link https://launchpad.net/keystone/+milestone/juno-1
14:01:11 <ttx> #info 2 blueprints left
14:01:36 <ttx> dolphm: are they both in-flight and waiting for the gate to process them ? Or do they need more reviews ?
14:02:01 <dolphm> yes and no - we have 3 patches left to land. one i have yet to propose myself :( one is ready to gate, and the other needs reviews
14:02:45 <ttx> dolphm: hmm, given the gate backlog, I think by EOD we should restrict juno-& targets to stuff that is queued
14:02:49 <ttx> juno-1*
14:02:55 <dolphm> the one i need to propose is an additional topic to round out document-v2-to-v3-transition
14:03:09 <dolphm> that sounds fair
14:03:14 <ttx> dolphm: you think you can propose and get it reviewed by EOD ?
14:03:19 <dolphm> ttx: yes
14:03:46 <ttx> OK, then just adjust at the end of your day so that it reflects review state
14:03:56 <dolphm> ttx: will do
14:03:59 <ttx> ideally we want to tag tomorrow, and use Thursday as a safety valve
14:04:16 <ttx> for stuff that will get caught in gate retries
14:05:16 <ttx> Looking at what my BP autokick script would do for keystone:
14:05:21 <ttx> http://paste.ubuntu.com/7623707/
14:05:34 <ttx> That means you don't have any unprioritized blueprint
14:05:46 <ttx> we just need to set the series goal for 3 blueprints
14:05:55 <dolphm> yay! i tried to clean up a few last week in prep for that
14:05:56 <ttx> so it looks like it's safe to enable the script to run for keystone ?
14:06:00 <dolphm> ttx: ++
14:06:14 <ttx> coolbeans
14:07:08 <ttx> looking at targeted bugs
14:07:14 <ttx> https://bugs.launchpad.net/keystone/+bug/1226171
14:07:36 <ttx> The only thing I can find linked in there would be:
14:07:48 <ttx> https://review.openstack.org/#/c/74214/
14:08:10 <ttx> Which doesn't look like a bugfix at all
14:08:22 <dolphm> ttx: it's a juno-1 targeted bp as well
14:08:30 <ttx> ah ok, so both are linked
14:08:49 <ttx> I suspect that's one of the "needs reviews" ?
14:08:58 <dolphm> ttx: yes
14:09:09 <ttx> At this point I think it's unlikely to make it, but let's give it until EOD
14:09:11 <dolphm> ttx: and i actually just +A'd one of the three, so we're down to 2
14:09:33 <ttx> This one + the one you have to propose ?
14:09:40 <dolphm> ttx: yes
14:09:41 <ttx> OK
14:10:28 <ttx> #info One blueprint in flight, 2 still needing proposal/review (will be punt by EOD if not approved by then). Bug is actually covered by targeted BP
14:10:43 <ttx> Anything you'd like to add to the meeting agenda ?
14:10:46 <dolphm> ttx: no sir
14:10:53 <ttx> OK ten, i'll let you work on that code
14:10:57 <ttx> +h
14:11:05 <dolphm> ttx: ttyl!
14:11:14 * dolphm puts head back into the sand
14:11:15 <ttx> jgriffith: ready if you're already around
14:20:58 <ttx> dhellmann: looks like jgriffith is not around, so you could fit now if you want
14:22:41 <dhellmann> ttx: sure, sorry, my znc instance died and I didn't realize
14:22:43 <dhellmann> I was actually online 2 hrs ago, but my irc client wasn't
14:22:52 <ttx> that happens
14:22:57 <ttx> dhellmann: got time now ?
14:23:05 <dhellmann> sure
14:23:10 <ttx> #topic Oslo
14:23:25 <ttx> #link https://launchpad.net/oslo/+milestone/juno-1
14:23:35 <ttx> #link https://launchpad.net/oslo.messaging/+milestone/juno-1
14:24:32 <ttx> First one has 4 "undefined" blueprints, I suspect you're holding on prioritizing them on spec approval ?
14:25:02 <dhellmann> yeah, I should go ahead and toss those to j2 as well
14:25:17 <dhellmann> or should I move them out altogether until the specs are approved?
14:25:18 <ttx> So the trick is, my automated script would remove those (milestoned but not prioritized)
14:25:30 <ttx> remove == clear the milestone target field
14:25:36 <dhellmann> that's fine
14:25:46 <ttx> OK, just making sure that wouldn't kill your workflow
14:26:17 <ttx> dhellmann: I think at this point you can move to j-2 anything that's not in-flight, or almost approved
14:26:23 <ttx> given the gate backlog
14:26:27 <dhellmann> I've been focusing on the specs, so I can bring the blueprints in as part of the approval process
14:26:37 <dhellmann> yeah, that's going to be a lot of it
14:26:54 <ttx> dhellmann: that's the idea yes, still working on a script to mostly automate that for yoy
14:26:54 <dhellmann> we got a slow start on specs, since we didn't agree to do it until right before the summit
14:27:13 <dhellmann> would the script bring blueprints in, too, or just take them out?
14:27:37 <ttx> just take them out. The CLI tool would help you bring them in
14:27:49 <dhellmann> cli tool?
14:27:56 <ttx> but the automated script would just take them out
14:28:21 <ttx> working on a spec2bp CLI that will do most of the Launchpad blueprint-filing work for you
14:28:27 <ttx> when you approve a spec
14:28:29 <dhellmann> oh, nice
14:28:44 <ttx> you'd just run the tool to get that spec into LP
14:29:00 <ttx> nice, except Lp doesn't have an API for creating specs
14:29:07 <ttx> so it takes longer than expected
14:29:17 <ttx> and will likely require manual steps
14:29:25 <ttx> anyway
14:29:50 <ttx> so you have 3 prioritized ones still in progress in that j-1 page
14:29:54 <ttx> +1 on the oslo.messaging page
14:30:25 <dhellmann> yeah, I'll move those to j2 by hand
14:30:28 <ttx> If they are not already in the gate pipe to get merged, i suggest you defer them yes
14:30:46 <ttx> same for targeted bugs
14:31:17 <ttx> dhellmann: here is what would happen if I ran the autokick script for oslo now:
14:31:25 <ttx> http://paste.ubuntu.com/7623815/
14:31:35 <ttx> basically it would kick those 4 unprioritized ones from juno-1
14:31:44 <ttx> If that sounds good I can run it now
14:31:46 <dhellmann> what is "cleargoal"?
14:32:00 <ttx> it removes the "juno" series goal to match the target milestone
14:32:11 <dhellmann> ah, ok
14:32:15 <ttx> (LP doesn't enforce consistency between those 2 fields)
14:32:30 <dhellmann> sure, that all looks fine
14:32:38 <dhellmann> and then I'll fix up the others by hand
14:32:40 <ttx> ok, running
14:32:52 <ttx> Let's see what would happen to oslo.messaging...
14:33:22 <ttx> nothing there
14:33:44 <ttx> OK, so I should be able to run that script on cron, as far as you're concerned
14:33:56 <ttx> dhellmann: anything you'd like to add to meeting agenda ?
14:34:09 <dhellmann> there's no juno-2 for oslo.messaging, yet, do you have a script to create those or should I do it by hand?
14:34:30 <ttx> dhellmann: I haz script
14:34:45 <ttx> #action ttx to create oslo.messaging milestones
14:34:47 <dhellmann> ah, mark created a "1.4.0" milestone
14:35:18 <dhellmann> we can keep that, but we should add the intermediate ones
14:35:49 <ttx> dhellmann: ok
14:36:06 <dhellmann> so a little cleanup work for me, is there anything else we need to talk about this week?
14:36:21 <ttx> nope
14:36:35 <dhellmann> cool, sorry for the time snafu
14:36:37 <ttx> unless you have something to add to meeting agenda, we are done
14:36:47 <ttx> We'll try to tag tomorrow
14:37:02 * mestery is ready when ttx is ready.
14:37:05 <ttx> if what's in-flight by EOD makes it by then
14:37:21 <ttx> yep, david-lyle is not around, so skipping Horizon
14:37:27 <ttx> #topic Neutron
14:37:37 <ttx> mestery: o/
14:37:37 <dhellmann> ttx: ok, thanks
14:37:40 <ttx> #link https://launchpad.net/neutron/+milestone/juno-1
14:37:47 <mestery> hi!
14:37:52 <mestery> Yes, that should be accurate now.
14:37:53 <ttx> #info 4 blueprints still in progress on that page
14:38:17 <mestery> I think we can land 2 of them by Thursday, maybe 3.
14:38:22 <ttx> mestery: as I suggested to others, I think given the gate backlog we should restrict targets to stuff already approved and in flight
14:38:34 <mestery> ttx: OK, that makes sense, no issues on my part then.
14:38:36 <ttx> except milestone-critical issues
14:38:54 <ttx> mestery: maybe give the reviews until EOD and then punt anything that's not in the pipe ?
14:38:57 <mestery> This one (https://blueprints.launchpad.net/neutron/+spec/ipv6-provider-nets-slaac) has a patch which is in re-check, and can then be merged.
14:39:02 <mestery> ttx: Perfect
14:39:29 <mestery> I'll send a note to the ML to let the neutron know the plan for Juno-1 then.
14:39:29 <ttx> You can start scrubbing the list if anything will definitely not make it
14:39:39 <mestery> Yes, I will do that.
14:39:46 <ttx> and then by EOD we reduce to what's in-flight
14:39:56 <ttx> then hopefully it merges tomorrow and we tag
14:40:05 <ttx> and then we have Thursday to handle Murphy's law
14:40:09 <mestery> Cool, pperfect
14:40:12 <mestery> ttx: :P
14:40:26 <ttx> mestery: on the bugs side...
14:40:36 <ttx> That's a lot of targeted bugs
14:40:41 <ttx> I think same rules apply
14:40:57 <mestery> I agree, that makes sense.
14:41:10 <ttx> remove now those that are far away in review, reduce list to in-flight stuff by EOD
14:41:11 <mestery> I'll scrub the bugs today as well and do the same thing as for BPs: Only things in flight by EOD have a chance at Juno-1.
14:41:16 <ttx> ack
14:41:54 <ttx> Looking at what my autokick cleanup script would do to neutron Bps now
14:42:27 * mestery has been grooming his milestones in LP like a freshly cut lawn. :)
14:43:02 <ttx> http://paste.ubuntu.com/7623860/
14:43:05 <mestery> I think it would kick nothing out, I was looking at Juno-2 (and even Juno-3) this week yet.
14:43:13 <ttx> most of those are just series goal alignment
14:43:17 <ttx> only one kick
14:43:20 * mestery looks.
14:43:23 <ttx> tenant-delete (from juno-3)
14:43:28 <mestery> I think that makes sense.
14:43:34 <mestery> That one may have snuck in. :)
14:43:40 <ttx> If you approve I can run the script now
14:43:53 <ttx> and then start making it a cron starting tomorrow morning
14:44:03 <mestery> It looks good to me, thanks for writing it!
14:44:17 <ttx> ok, processing
14:44:34 <ttx> Anything you'd like to add to meetign agenda for today ?
14:45:01 <mestery> Possibly something around the "ssh timeout" bug from the gate.
14:45:09 <mestery> I've debugged this, and it actually looks like a nova issue: https://bugs.launchpad.net/neutron/+bug/1323658
14:45:12 <ttx> mestery: sounds like a good topic
14:45:19 <mestery> I alerted nova team in-channel, but would be good to get broader eyes on this one.
14:45:35 <ttx> mestery: just edit https://wiki.openstack.org/wiki/Meetings/ProjectMeeting
14:45:37 <mestery> jogo eyeballed it quickly last night.
14:45:41 <mestery> ttx: Will do, and thanks!
14:45:46 <ttx> great thx!
14:45:53 <ttx> jpich: around ?
14:45:58 <jpich> yep
14:45:59 <ttx> #topic Horizon
14:46:07 * mestery wanders off. :)
14:46:18 <ttx> #link https://launchpad.net/horizon/+milestone/juno-1
14:46:33 <ttx> 19 (!) blueprints still targeted
14:46:47 <jpich> I removed the stuff that wasn't started but I take it it's not sufficient at this stage?
14:47:12 <ttx> jpich: at this point it's unlikely to make it to juno-1 if it's not aready approved and in the gate pipe
14:47:27 <jpich> I see
14:47:36 <ttx> so I would suggest you remove anything that's not nearing final approval
14:47:39 <jpich> I think there's a couple that might be approved today but probably not many
14:47:46 <ttx> well, push it back to j-2
14:47:49 <jpich> Ok, will do
14:48:09 <ttx> then by the end of the day just remove anything that is not queued in the gate
14:48:21 <ttx> goal being to tag sometimes tomorrow, Thursday if things go wrong
14:48:48 <jpich> Ok
14:48:53 <ttx> While you're at it you can set a priority for the two "undefined" ones and add an assignee to the unassigned one
14:49:24 <ttx> jpich: same for the bugs; you still have 5 targeted
14:49:28 <jpich> Sure, didn't noticed the unassigned one
14:49:37 <ttx> by the end of the day it would be good to only have those that are in the queue
14:49:53 <jpich> Makes sense
14:50:03 <ttx> jpich: "end of day" can include early tomorrow morning, since you seem to be in France right now
14:50:15 <jpich> Indeed :) Cheers
14:51:02 <ttx> basically tomorrow we need to have the list reflect the picture of what's approved and waiting in the gate pipe
14:51:13 <ttx> and then pray it all makes it soon enough*
14:51:19 <jpich> heh
14:51:53 <ttx> jpich: are you or mrunge being present at the cross-project meeting at 21:00 UTC ?
14:52:02 <jpich> lcheng should be there
14:52:08 <ttx> SergeyLukjanov had a topic to discuss with Horizon folk
14:52:12 <ttx> ok, good
14:52:16 <jpich> Ok I'll let him know
14:52:45 <ttx> Anything you'd like to add to the agenda yourself ?
14:53:14 <jpich> No, though I'm curious about that script that removed blueprint with no priority you mentioned earlier?
14:53:26 <ttx> jpich: it's for projects using -specs repos
14:53:35 <ttx> and if my book is correct Horizon doesn't
14:53:40 <jpich> Aah! Ok
14:53:46 <jpich> Yup, that's my understanding too
14:54:02 <jpich> Is there an agenda somewhere for these PTL syncs?
14:54:05 <ttx> jpich: the idea being, not asking contributors to file a spec AND a blueprint as the entry point for submitting features
14:54:18 <jpich> That totally makes sense
14:54:20 <ttx> and use blueprints as a PTL-only tool
14:54:38 <ttx> (or at least the milestone view)
14:54:53 <ttx> so we remove anythign not prioritized (blessed by PTL) from BP milestone views
14:55:10 <ttx> For non-specs using projects, the script only adjusts the series goal
14:55:16 <ttx> which is mostly harmless
14:55:41 <ttx> (script makes sure it's coherent with what's in the "milestone target" field)
14:56:10 <jpich> Yup, cool, thank you for the explanation
14:56:14 <ttx> no there isn't an agenda for the sync. We publish logs though :)
14:56:30 <ttx> ok, ttyl, thanks for covering Horizon here
14:56:38 <jpich> Ok! Thanks
15:04:26 <notmyname> ttx: can we do our sync early?
15:05:27 <ttx> on a call
15:05:41 <ttx> notmyname: ^
15:05:53 <ttx> will ping you if I escape early
15:05:53 <notmyname> ack
15:17:25 <notmyname> ttx I've got to commute. I'll be back online ASAP
15:30:40 <ttx> notmyname: ready when you are
15:30:58 <ttx> (still on my call but parallelizing)
15:42:15 <ttx> zaneb: if you're around now, we can switch, notmyname is apparently lost in commute
15:42:28 <zaneb> sure, np
15:42:34 <ttx> #topic Heat
15:42:52 <ttx> #link https://launchpad.net/heat/+milestone/juno-1
15:43:03 <ttx> 6 blueprints still open
15:43:21 <zaneb> I did some gardening :)
15:43:39 <ttx> zaneb: given gate backlog, I think it will be more realistic to only keep stuff that's in-flight or that will be approved by the end of the day
15:43:41 <zaneb> these have mostly been delayed by the gate issues
15:43:48 <ttx> that way we cna tag tomorrow, Thursday in the worst case
15:44:27 <zaneb> actually, I suspect that first one has been merged, I will check on it
15:44:39 <ttx> zaneb: do you think only keeping stuff that is in-flight on the target milestone by EOD is agreeable ?
15:44:50 <zaneb> that sounds fine
15:44:57 <ttx> same for bugs
15:45:03 <zaneb> I think most of this stuff actually is in-flight
15:45:12 <zaneb> but it's all low-priority anyway
15:45:19 <ttx> I doubt all those bugs are in flight :)
15:45:42 <ttx> just defer to j-2 anything that doesn't have an approved review
15:45:45 <zaneb> no, the bugs are not
15:45:49 <zaneb> ok
15:46:02 * ttx looks at what the autokick script would do to your blueprints
15:46:43 <ttx> http://paste.ubuntu.com/7624117/
15:46:54 <ttx> it would adjust series goal on a number of things
15:47:04 <ttx> and remove 3 BPs from j-2
15:47:40 <ttx> does that sounds acceptable ? If yes I can run it now
15:48:17 <zaneb> yep, that all looks reasonable
15:48:21 <ttx> (goal being to only keep blessed blueprints on those targeted lists, and avoid asking contributors to file a spec AND a blueprint)
15:48:44 <ttx> zaneb: ok, I'll run the script now and add you to the cron starting tomorrow
15:48:57 <zaneb> cool, thanks
15:49:11 <ttx> it should result in a lot less manual scrubbing and maintenance of that list
15:49:27 <zaneb> +1 for that :)
15:50:04 <ttx> Ok, that's all I had -- basically by EOD try to reduce the juno-1 list to in-flight stuff, then we plan to tag on Wednesday when all that finally merges
15:50:14 <ttx> anything you wanted to discuss in the meeting today ?
15:50:31 <zaneb> nope, that all sounds good
15:50:41 <notmyname> ttx: here now
15:50:46 <zaneb> thanks ttx
15:50:56 <ttx> great timing
15:51:00 <ttx> zaneb: thx!
15:51:03 <ttx> #topic Swift
15:51:13 <notmyname> hello
15:51:20 <ttx> notmyname: hi!
15:51:41 <ttx> Can't do a more direct medium today, I can do that early tomorrow though if you want
15:51:49 <notmyname> hmm...
15:51:52 <ttx> (PST)
15:51:59 <ttx> Or we can just talk here
15:52:04 <notmyname> ok. so let's cover the high level today, and you can determine if you want something else tomorrow
15:52:24 <ttx> so... next swift release?
15:52:29 <notmyname> yes.
15:52:47 <notmyname> ...just getting in...trying to organize my thoughts...
15:53:09 <notmyname> storage policies is going well. last couple of things should be finished today
15:53:29 <notmyname> which gives us the goal of merging to master this week
15:53:49 <notmyname> and I'm working with mordred to figure out how to make that happen in a reasonable time frame, given the status of the gate
15:54:24 <notmyname> ie with the current 27-29 patches, the current gate would take weeks to months to merge
15:54:38 <notmyname> so, let's assume all that's solved
15:55:04 <notmyname> so from there, we will land a couple of other pending, non-SP patches and then have a release
15:55:09 <notmyname> well, actually an RC
15:55:23 <ttx> got disconnected, missing any message between "master this week" and "ie with the current"
15:55:57 <notmyname> just on: "and I'm working with mordred to figure out how to make that happen in a reasonable time frame, given the status of the gate"
15:56:06 <notmyname> *one
15:56:08 <ttx> ok
15:56:55 <ttx> notmyname: IIRC we would have an RC tagged on master, rather than do the milestone-proposed dance like for the "coordinated" release, right ?
15:56:56 <notmyname> so assuming those are all landed, then we need an extended RC period for this release, given the scope of what's in it. and I've already got soft commitments from at least 3 companies to do QA
15:57:19 <notmyname> correct. RC tagged on master, but would need a branch if things are found that need to be in the release
15:57:30 <ttx> notmyname: ack
15:57:42 <ttx> #info Swift RC tagged on master, but would need a branch if things are found that need to be in the release
15:58:14 <notmyname> so what I'm thinking now is RC this week (assuming gating issues solved), then a 2 week RC. assuming things are good, then formal release at the end of the two weeks
15:58:26 <ttx> notmyname: sounds good
15:58:34 <notmyname> note that this could change depending on what, if anything is found in the RC period
15:58:52 <ttx> notmyname: do you have a version number in your head ?
15:58:53 <notmyname> with me so far? :-)
15:59:18 <notmyname> ok. as to the version number (please don't info this yet) ;-)
15:59:23 <ttx> (so that I can create a $VERSION-rc1 milestone)
15:59:28 <notmyname> the next release with storage policies will be 2.0
15:59:34 <ttx> ooooh.
15:59:49 <ttx> That will be our secret.
16:00:01 <notmyname> and since that carries some bigger meaning, you can imagine that it will garner some additional marketing efforts outside of the dev community
16:00:16 <notmyname> and I'm working on coordinating those things now
16:00:26 <notmyname> so for you and me, this is a release like normal
16:00:27 <ttx> notmyname: do you prefer me to hold on 2.0.0-rc1 milestone creation ?
16:01:08 <notmyname> ttx: yes. I'd prefer that we create that when it's ready to happen. the reality of the gate is that we'll have some time to kill there ;-)
16:01:15 <notmyname> ie instead of doing it today
16:01:16 <ttx> notmyname: ok
16:01:20 <notmyname> ok, one last thing there
16:01:26 <notmyname> one more confounding factor
16:01:49 <ttx> #info Next Swift release hopefully in RC at end of week (depending on gate health)
16:02:28 <notmyname> I'm having surgery on my collar bone on thursday, so I'm not sure about my ability to click buttons. but I will, or get someone (prob clayg or torgomatic) to proxy for me if necessary
16:02:42 <notmyname> I have no idea what recovery time will be
16:02:59 <ttx> notmyname: OK. Get well soon!
16:03:02 <notmyname> thanks
16:03:29 <ttx> #action ttx to buy a bike helmet on Amazon
16:03:29 <notmyname> I think that's the summary. obviously there are a lot of details there yet to be worked out. do you need anything else from me right now?
16:03:33 <notmyname> yes!!!
16:04:01 <ttx> notmyname: nope, sounds good. Anything you wanted to add to meeting agenda for tonight ?
16:04:11 <notmyname> I'm good
16:04:27 <ttx> ok, ttyl then
16:04:47 <ttx> SlickNik: if you're around you can jump the queue
16:05:45 <ttx> as we lost markwash
16:08:05 <ttx> markwash: o/
16:08:14 <markwash> ttx: hi sorry didn't realize my connection had dropped
16:08:18 <ttx> #topic Glance
16:08:21 <ttx> markwash: that happens
16:08:29 <ttx> dhellmann had the same excuse :)
16:08:42 <markwash> especially when you're fumbling with a laptop and vpn and not paying attention :-)
16:08:49 * dhellmann is a trend-setter
16:08:50 <ttx> https://launchpad.net/glance/+milestone/juno-1
16:08:58 * markwash covers his eyes
16:09:10 <ttx> 2 blueprints still up there
16:09:32 <markwash> looks like some bumping is in order :-(
16:09:35 <ttx> markwash: are any of them likely to merge before we need to tag stuff ?
16:09:46 <ttx> i.e. ~ tomorrow ?
16:09:51 <markwash> no
16:10:11 <ttx> markwash: ok, you should probably bump everything then
16:10:36 <ttx> and if you're not waiting on something specific to get merged, we cna probably tag soon
16:10:57 <markwash> no wait
16:11:03 * ttx searches the gate pipe for glance changes
16:12:35 * ttx waits
16:12:44 * markwash chuckles
16:13:01 <ttx> markwash: just send me a SHA to tag "juno-1" before EOD tomorrow and I'll make it happen ?
16:13:15 <markwash> okay sounds good
16:13:32 <ttx> markwash: you should also clean up the bugs list
16:13:40 <markwash> ah good point
16:13:50 <markwash> ttx based on my look at gerrit there is nothing in the queue at all right now
16:14:46 <ttx> markwash: I'm fine with keeping anything that you think you can get approved before EOD in the list
16:14:55 <markwash> so we can just go with tagging 9c87169c78a01f7c057734f641d428a8804334f9
16:15:13 <ttx> but I don't see anything
16:15:27 <ttx> #info Glance juno-1 can be tagged on 9c87169c78a01f7c057734f641d428a8804334f9
16:15:45 <ttx> markwash: OK, will do it before the TC meeting, that gives you some time to cancel :)
16:16:15 <ttx> so let's see what the autokick script would do to your BPs
16:16:30 <ttx> http://paste.ubuntu.com/7624251/
16:16:59 <ttx> markwash: apart from adjusting a few series goals, it would just remove te juno-2 target milestone from storage-policies-vmware-store
16:17:20 <ttx> (because that spec is not prioritized)
16:17:28 <markwash> okay I'm going to have a second look at that one to decide if it should go ahead and be prioritized
16:18:02 <ttx> markwash: OK, ideally do it before the project meeting as I'd like to set up that script in cron soon
16:18:17 <markwash> yeah, we just missed prioritization in our previous discussions
16:18:26 * markwash has a cat that is trying to contribute to the conversation
16:18:26 <ttx> #action markwash to figure out what to do with storage-policies-vmware-store
16:18:31 <markwash> done
16:18:35 <markwash> I already prioritized it
16:18:36 <ttx> oh. ok
16:18:42 <ttx> so I can run the script now
16:18:50 <markwash> absolutely
16:18:57 <ttx> let's do that
16:19:12 <ttx> anything you'd liek to add to meetign agenda today ?
16:19:20 <ttx> damn fingers
16:19:48 <ttx> your hands should be full with the TC items already
16:19:52 <markwash> I don't think so, I'm curious if PTL ish folks are concerned about the catalog or graffiti stuff but I guess I should just rely on the ML and them raising their own points
16:20:04 <markwash> yeah, speaking of TC
16:20:09 <markwash> and specifically glance gap analysis
16:20:13 <ttx> you can informally raise it in open discussion, if you're still around by then
16:20:14 <markwash> I *think* I'm ready for that discussion
16:20:27 <ttx> markwash: I'm sure you are
16:20:34 <markwash> it looks like we don't really have any gaps, except maybe with docs
16:21:11 <markwash> is the format just: folks ask me questions about gaps they think might be there?
16:21:17 <ttx> markwash: yeah, just a formality
16:21:21 <markwash> or do I need a more formal input to the process
16:21:30 <markwash> s/need/need to provide/
16:21:36 <ttx> nope, we'll just go through the list and ask questions if we have doubts
16:21:45 <markwash> okay great
16:21:48 <markwash> then bring it on!
16:21:49 <markwash> :-)
16:21:49 <ttx> I don't expect we'll have that many, but we need to check
16:21:52 <ttx> cool
16:21:57 <ttx> SlickNik: around?
16:22:02 <ttx> markwash: thx!
16:22:07 <SlickNik> ttx here
16:22:08 <ttx> #topic Trove
16:22:09 <markwash> thank you!
16:22:19 <ttx> https://launchpad.net/trove/+milestone/juno-1
16:22:26 <ttx> 5 BPs still on the map
16:22:55 <SlickNik> Yup, 1 or 2 are really close to merging.
16:23:00 <ttx> SlickNik: so I think we need to reduce that list to stuff that has all apporvals lined up, by EOD
16:23:10 <SlickNik> And I'm going to bump the other 3.
16:23:19 <ttx> SlickNik: sounds good
16:23:26 <SlickNik> I can do that.
16:23:28 <ttx> Same thing for bugs
16:23:39 <ttx> Get them approved and in the gate pipe by end of day, or bump them
16:23:50 <ttx> so that we have a clear view of the last milestone tag blockers
16:23:59 <SlickNik> Actually let me bump the ones I know won't make it right now.
16:24:06 <ttx> even better!
16:24:27 <ttx> Goal being to tag sometimes tomorrow, and keep Thursday as a safety net
16:24:56 <ttx> Just email or IRC me a SHA when you have all you want in, and I'll push the tag to master
16:25:48 <SlickNik> Okay, will send you the SHA on IRC by EOD today
16:26:23 <ttx> SlickNik: it's fine if you still have a few in-flight and we tag on Wednesday
16:26:35 <ttx> but if you've got all you think you'll have, then yes, let's tag
16:27:10 <SlickNik> There's a couple in flight. Gonna get core to close on the reviews for them today.
16:27:21 <SlickNik> Will send you the SHA once that's done.
16:27:46 <ttx> SlickNik: OK, as long as that happens before EOD tomorrow we're good
16:27:59 <ttx> SlickNik: anything you wanted to add to meeting agenda for today ?
16:28:20 <ttx> jgriffith: around?
16:28:32 <SlickNik> Nope.
16:28:49 <ttx> SlickNik: ok, thx!
16:29:01 <SlickNik> ttx , Thank you!
16:29:10 <SlickNik> Will catch you later. :)
16:29:27 <ttx> And that concludes our 1:1 syncs for today
16:29:31 <ttx> Thanks everyone
16:29:44 <ttx> #endmeeting