15:29:22 <ttx> #startmeeting incub_sync
15:29:23 <openstack> Meeting started Thu Jun  5 15:29:22 2014 UTC and is due to finish in 60 minutes.  The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:29:24 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:29:27 <openstack> The meeting name has been set to 'incub_sync'
15:29:28 <ttx> jraim: around?
15:29:32 <jraim> yep
15:29:35 <ttx> #topic Barbican
15:29:54 * ttx looks up the LP pages
15:30:26 <ttx> jraim: when do you plan to do a juno-1 ?
15:30:51 <ttx> in sync withe the integrated release, or when ready ?
15:31:02 <jraim> we usually try to stay in sync
15:31:27 <jraim> all our releases since incubation have been in sync with integration timelines
15:31:35 <ttx> jraim: OK, juno-1 is next week, with a tag pushed to master in a window going from Tuesday to Thursday
15:32:01 <jraim> for the havana release, there was a wiki page with the dates on it...do we have one for Juno?
15:32:01 <ttx> We abandoned the concept of creating a branch for dev milestones
15:32:10 <ttx> (no more milestone-proposed)
15:32:16 <jraim> ahh, okay
15:32:25 <ttx> https://wiki.openstack.org/wiki/Juno_Release_Schedule*
15:32:29 <ttx> err
15:32:33 <ttx> #link https://wiki.openstack.org/wiki/Juno_Release_Schedule
15:32:55 <jraim> perfect, thanks
15:33:00 <ttx> so just let me know when you want to apply the tag and which SHA you want the tag applied to
15:33:06 <jraim> will do
15:33:10 <ttx> not necessarily between Tue and Thu, your call
15:33:22 <jraim> we have some PRs circling that I want to get the status of, then we should know
15:33:36 <ttx> I think I saw you were using a barbican-specs repo ?
15:33:49 <jraim> the PR is in to infra, just waiting for the final approvals
15:33:52 <ttx> ok
15:34:10 <ttx> jraim: is https://launchpad.net/barbican/+milestone/juno-1 up to date with your j-1 goals ?
15:34:29 <jraim> its close, but we're planning a cleanup once the barbican-specs stuff lands
15:34:48 <ttx> jraim: NB: you generally want to set a priority to any blueprint you add there.
15:35:15 <ttx> The idea being we plan to use the -specs repo as the entry point for new feature, rather than encourage people to file BPs
15:35:18 <jraim> I'll make sure they are all filled out during the clean up
15:35:33 <jraim> yep, we're excited about the -specs approach
15:35:38 <ttx> so the milestone page serves as a communication tool and should be controlled by the project drivers
15:36:02 <ttx> but since LP lets anyone set target milestones, we use the priority field to check it's blessed
15:36:32 <jraim> are there understood meanings for the various statuses?
15:36:32 <ttx> I even have an autokick script that will remove BPs from milestones if they aren't prioritized
15:36:46 <ttx> yes, see https://wiki.openstack.org/wiki/Blueprints
15:37:04 <ttx> might be outdated with all the -specs approach though
15:37:16 <jraim> understood
15:37:30 <ttx> Priority and Implementation fields are what you should maintain
15:37:41 <ttx> and their meaning is still current
15:37:55 <jraim> okay
15:38:21 <ttx> #action ttx to check https://wiki.openstack.org/wiki/Blueprints for validity in -specs world
15:38:53 <ttx> so yeah, on https://launchpad.net/barbican/+milestone/juno-1 you should fix the "undefined" and the "unknown"
15:39:10 <ttx> jraim: other questions ?
15:39:15 <jraim> just one about integation
15:39:21 <jraim> we got a lot of questions about it at the Summit
15:39:26 <ttx> jraim: want me to create the other milestones in LP with due dates matching the integrated release ?
15:39:34 <ttx> jraim: sure ask
15:39:37 <jraim> sure, if you want that would be helpful
15:39:46 <jraim> I wasn't orignally planning on trying for integration this cycle
15:39:50 <ttx> #action ttx to create barbican milestones
15:39:54 <ttx> I have a script for that, so fast
15:40:05 <jraim> what would be your thoughts on us attempting that?
15:40:22 <jraim> any minefields you see? I don't want to waste the team and TC's time if we think there isn't a high chance
15:40:32 <ttx> jraim: you mean, graduate within this cycle ?
15:40:37 <jraim> yes
15:41:00 <ttx> in all cases you can't be "integrated in Juno release" since the Juno contents are decided before the cycle starts
15:41:13 <ttx> but you can aim for graduation at the end of Juno to be part of K release
15:41:22 <jraim> okay, that seems reasonable
15:41:29 <ttx> and I think it is reasonable
15:41:35 <jraim> most of the questions were just about wanting us to be integrated before people started deployment work
15:41:55 <jraim> okay, i'll start reviewing the requirements and see where we are with an aim to asking late in the cycle for K
15:42:01 <ttx> the release lags behind the dev cycles anyway
15:42:09 <ttx> OK, talk to you next week, tehn
15:42:14 <ttx> kgriffs: around?
15:42:16 <jraim> awesome, thanks
15:42:58 <kgriffs> o/
15:43:06 <ttx> #topic Marconi
15:43:11 <ttx> kgriffs: o/
15:43:42 <kgriffs> howdy
15:43:46 <ttx> kgriffs: planning to tag juno-1 next week ? Or some other time ?
15:44:15 <ttx> #info Barbican planning to do juno-1 in sync with Juno release cycle
15:44:36 <kgriffs> yep. I'd like to continue getting the team comfortable with the cadence of the integrated projects
15:44:49 <ttx> #info Marconi planning to do juno-1 in sync with Juno release cycle
15:45:03 <ttx> kgriffs: ok, so the new process is just a tag on master, based on a SHA you provide
15:45:09 <kgriffs> ah, ok
15:45:19 <ttx> as we dropped usage of a release branch for lowly milestones
15:45:28 <ttx> nobody backported anything to them anyway
15:45:29 <kgriffs> so I just send you the SHA when we are ready to go?
15:45:45 <kgriffs> ttx: makes sense
15:45:48 <ttx> kgriffs: yes
15:46:06 <ttx> kgriffs: milestoens are not really important anyway... all commits should work ;)
15:46:13 <kgriffs> do you prefer IRC or an email or?
15:46:24 <ttx> but you can implement a soft freeze to slow down crazy patches while you try to get a working SHA
15:46:27 <kgriffs> ttx: heh, gotchya
15:46:32 <ttx> kgriffs: IRC or email
15:46:47 <kgriffs> kk
15:46:47 <ttx> https://launchpad.net/marconi/+milestone/juno-1 looks good
15:46:57 <ttx> expect maybe that essential task which is not started
15:47:15 <kgriffs> yeah... I was just following up with the team on that to see what is going on there
15:47:33 <kgriffs> I suspect it will get bumped to j-2
15:47:45 <ttx> kgriffs: want me to create all the Juno milestones with dates matching the release schedule ?
15:47:54 <kgriffs> it really is essential then, because v1.1 of the api requires it
15:47:55 <ttx> I'll run the same script as Barbican
15:48:02 <kgriffs> ttx: that would be awesome!
15:48:03 <ttx> #action ttx to create marconi milestones
15:48:23 <kgriffs> btw, I came across a reference on the wiki to a "future" series
15:48:23 <ttx> it might fail miserably due to Launchpad ACL but then I'll ping you to add me :)
15:48:36 <kgriffs> kk
15:48:38 <ttx> kgriffs: yes, it's a way to categorize future work
15:48:45 <ttx> I can create that too
15:48:55 <ttx> #action ttx to create future series for Marconi
15:49:07 <kgriffs> so, what goes in future vs., say j-2 or j-3 ?
15:49:11 <ttx> jraim: let me know if you want it as well
15:49:31 <ttx> things that are pushed back to next cycle. useful around feature freeze
15:49:57 <ttx> "future" series has "next" and "ongoing" milestones
15:49:58 <jraim> jraim: that's fine with me
15:50:05 <jraim> ha
15:50:09 <kgriffs> ah, ok. makes sense. I could definitely have used that for the Juno freeze. It will be handy for next time.
15:50:09 <jraim> ttx: that's fine with me
15:50:09 <ttx> next is for "not in this cycle"
15:50:23 <ttx> "ongoing" is for work that is never really finished
15:50:29 <ttx> like "increase coverage"
15:50:42 <ttx> that avoids to push it back milestone to milestone
15:50:57 <ttx> #action ttx to create barbican future series too
15:51:02 <kgriffs> makes sense
15:51:04 <ttx> kgriffs: ok, anything else ?
15:51:39 <ttx> we can keep some questions for next week :)
15:51:42 <kgriffs> just a quick note that we are putting the finishing touches on our tempest tests and will be making that gate voting ASAP
15:51:51 <ttx> kgriffs: great news!
15:51:59 <ttx> #info Marconi are putting the finishing touches on our tempest tests and will be making that gate voting ASAP
15:52:02 <kgriffs> also, py3k compat is coming along nicely. We have an intern doing great work there.
15:52:12 <ttx> feel free to use the  #info tag yourself
15:52:19 <ttx> so that it appears in the automated summary
15:52:24 <kgriffs> #info py3k compat is coming along nicely. We have an intern doing great work there.
15:52:29 <ttx> here you go :)
15:52:32 <kgriffs> ttx: thanks for the reminder!
15:52:34 <ttx> devananda: around ?
15:52:46 <ttx> kgriffs: np!
15:53:59 <devananda> ttx: o/
15:54:03 <ttx> #topic Ironic
15:54:11 <ttx> devananda: looks like you have your milestones and series already set
15:54:23 <ttx> So... juno-1 sometimes next week ?
15:54:29 <devananda> ttx: i think you created them for us a while back
15:54:59 <devananda> fwiw, we've drunk the specs coolaid, and pushed all our BPs back, and are focusing on clean up right now
15:55:19 <ttx> As I told the others, we dumped the milestone-proposed-based process to do a simple tag for juno-1
15:55:22 <ttx> on master
15:55:23 <devananda> aiming to merge the nova.virt.ironic driver into nova by j2, as opposed to adding more features
15:55:36 <devananda> ah, that's convenient
15:55:41 <ttx> so just gove me a SHA for it when you want it tagged
15:55:48 <ttx> give*
15:55:52 <devananda> we probably wont have any new features in j1 -- just lots of bug fixes
15:56:01 <devananda> that's why no BPs are targeted to it right now
15:56:04 <ttx> that's what your juno-1 page says, for sure :)
15:56:32 <devananda> several specs are in flight and aiming for j2 / j3
15:56:33 <ttx> devananda: heard of my autokick script ? I told jraim about it
15:56:51 <ttx> it may be used to enforce LP missing consistency
15:56:58 <devananda> ttx: nope
15:57:00 <devananda> sounds interesting
15:57:09 <ttx> i.e. make sure people don't pollute your milestoen pages by adding random stuff to it
15:57:11 <devananda> kicks anything missing an approved spec?
15:57:19 <ttx> .. not quite
15:57:33 <ttx> but removed BPs that are in the milestone page that don't have a priority
15:57:44 <devananda> ah, cool
15:57:47 <ttx> priority is a field only drivers can set
15:57:48 <devananda> i kicked one of those manually today
15:57:53 <ttx> so it shows you blessed it
15:58:02 <ttx> everythign else can be autokicked
15:58:03 <devananda> ++
15:58:13 <ttx> so that we can truly use this page as a communication tool
15:58:18 <devananda> link?
15:58:26 <ttx> rather than as a wall where everyone writes
15:58:44 <ttx> devananda: no link yet
15:59:01 <ttx> it will replace the script that I run to adjust series goal automatically every 2 hours
15:59:25 <ttx> new one will adjust series goals AND autokick blueprints for projects using -specs
15:59:33 <ttx> #info ironic using specs
15:59:43 <devananda> ah, gotcha. sounds good -- i know many folks look at the LP/blueprint status as a guidepost, so keeping it cleaner is important
15:59:45 <ttx> kgriffs: btw, is marconi planning to use specs (or already using them) ?
16:00:07 <ttx> devananda: the tradeoff being, you need to prioritize BPs you put there
16:00:18 <devananda> it's probably not news to anyone, but like most projects, we're short on review (and specs review) bandwidth
16:00:30 <ttx> devananda: fwiw I also work on a spec2bp script that will file BPs in LP for specs you approve
16:00:44 <ttx> so that you don't have that manual step
16:00:55 <devananda> i already make a point to prioritize the BPs, though right now i'm also prioritizing unapproved ones
16:01:18 <ttx> think: "spec2bp this-spec juno-2 high
16:01:19 <ttx> "
16:01:30 <devananda> ahh - that's be handy
16:01:44 <ttx> now if the LP API will just let me do that...
16:02:05 <devananda> :)
16:02:07 <ttx> anyway, our limited time is up... did you have an urgent question?
16:02:18 <devananda> ttx: nope! if you dont have any Q for me ...
16:02:22 <devananda> then let's wrap. thanks much!
16:02:30 <ttx> I have more, but that's for next week's episode.
16:02:33 <ttx> #endmeeting