21:01:36 <sarob_> #startmeeting product_working_group
21:01:37 <openstack> Meeting started Mon Nov 23 21:01:36 2015 UTC and is due to finish in 60 minutes.  The chair is sarob_. Information about MeetBot at http://wiki.debian.org/MeetBot.
21:01:38 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
21:01:40 <openstack> The meeting name has been set to 'product_working_group'
21:01:56 <shamail> hi sarob_
21:02:02 <sgordon> \o/
21:02:31 <hughhalf> o/
21:02:37 <shamail> hi all!
21:02:43 <dpk_> o/
21:02:59 <kencjohnston> o/ - IRC only, and not just because of the email I sent :)
21:03:12 <sarob_> #info agenda https://wiki.openstack.org/wiki/Meetings/product-team
21:03:15 <shamail> I am IRC only as well
21:03:16 <kencjohnston> Howdy shamail
21:04:00 <hughhalf> Etherpad for this meeting https://etherpad.openstack.org/p/PWG_11_23_15
21:04:02 <KrishR> o/
21:04:06 <leong> o/
21:04:09 <shamail> no etherpad for this one I thought?
21:04:19 <kencjohnston> hello all
21:04:19 <shamail> etherpad was only temporary while we were adjusting IRC schedules
21:04:26 <sarob_> #topic IRC and or conference call for meeting
21:04:46 <hughhalf> shamail ok, no worries
21:04:57 <shamail> agenda for today
21:04:59 <shamail> #link https://wiki.openstack.org/wiki/Meetings/product-team
21:05:31 <shamail> np hughhalf :)
21:05:44 <sgordon> #link http://lists.openstack.org/pipermail/product-wg/2015-November/000869.html
21:05:50 <rockyg> o/ I'm on
21:06:44 <shamail> sarob_: can you please let us know on IRC when the vote happens too
21:07:13 <kencjohnston> On the topic of IRC meetings #link http://jjasghar.github.io/blog/2015/11/18/characteristics-of-a-successful-chatroom-meeting/
21:07:33 <sgordon> #link http://jjasghar.github.io/blog/2015/11/18/characteristics-of-a-successful-chatroom-meeting/
21:07:36 <hughhalf> sarob_ Makes the observation in the voice call that experience has shown that trying to use voice, IRC and Etherpad tends to mean that the detail resides in whatever is used most
21:08:01 <hughhalf> sarob_ went on to note that this probably means it makes sense to coalesce down to one channel if possible
21:08:12 <sarob_> So before I call for a vote on this topic
21:08:14 * hughhalf will defer to sarob_  to correct him
21:08:30 <sarob_> Who else wants to discuss
21:08:38 <shamail> thx hughhalf, our channels have been basically calls and IRC
21:09:07 <shamail> historically, we did a better job in maintaining links/actions in IRC but that has dropped off
21:09:19 <rockyg> True
21:09:28 <shamail> I think the real candidates (personally) are: 1) IRC only and 2) IRC + call
21:09:41 <sarob_> I prefer IRC
21:09:57 <shamail> sarob_: +1
21:10:06 <kencjohnston> sarob_ +1
21:10:13 <sgordon> sarob_, +1
21:10:14 <rockyg> Not so good for brainstorming and architecting
21:10:19 <shamail> As I mentioned in my reply (http://lists.openstack.org/pipermail/product-wg/2015-November/000870.html)
21:10:32 <dpk_> rockyg: +1
21:10:45 <shamail> My vote would be to use IRC for weekly meetings but still give the sub-teams an option to use call+etherpads+whatever
21:10:59 * hughhalf nods in agreement with shamail
21:11:31 * kencjohnston nods as well
21:11:38 <sarob_> Rockyg is concerned about loosing some brainstorming benefit
21:11:38 <shamail> This will allow us to use the best medium for decision making but also standardize with the preferred method for the community
21:11:50 <leong> Maybe (2) IRC + call for start, and get team familiar with IRC first for the first few meeting?
21:12:24 <leong> something people has no access to internet while "on-the-road" (that's what happened in the past in this group)
21:12:57 <shamail> I've seen the latter happen more often (sgordon and geoffarnold) used to be in IRC but not on phone.
21:13:00 <sgordon> tbh when i am on the road i am actually more likely to have internet
21:13:12 <sgordon> but not necessarily internet i can voip on
21:13:16 <shamail> I'm on the road too and IRC is easier at the moment
21:13:23 <sarob_> Rockyg thinks IRC as standard and conference calls for adhoc discussions
21:13:31 <hughhalf> sgordon agreed
21:13:33 <shamail> sarob_ and rockyg: +1
21:14:12 <dpk_> Kudos - good point, Sean!
21:14:18 <shamail> I think flexibility is good because sometimes calls work much more efficiently (e.g. parking lot items, sub-team working groups)
21:14:24 <rockyg> so, IRC for daily/weekly tasks and discussions -- while planning for midcycles, board and/or summit presentatons, schedule extra voice meetings
21:14:39 <leong> i'm fine on IRC actually.. cuz in the past i do see people are "driving" while participating in cal
21:14:42 <shamail> rockyg: yes, plus roadmap and user story discussions
21:15:09 <rockyg> shamail: exactly
21:15:16 <shamail> fair point leong
21:15:36 <shamail> sarob_: want to call a vote?
21:16:02 <KrishR> some of us have to just get used to searching for conversations in IRC
21:16:24 <sarob_> Almost there
21:16:46 <shamail> KrishR: happy to help with that...generally when use it properly, the meeting logs for IRC do a good job of summarizing items (http://eavesdrop.openstack.org/meetings/product_working_group/2015/product_working_group.2015-08-24-19.02.html)
21:16:58 <shamail> thanks sarob_!
21:18:17 * hughhalf apologises in advance - has another call at half past the hour he'll need to at least drop off voice for.
21:18:35 <shamail> thanks hughhalf
21:18:36 <dpk_> +1 to the trainings, that would really be helpful!
21:18:56 <KrishR> +1 to training
21:19:16 <sarob_> I'm offering to training new members
21:19:30 <shamail> great idea sarob_
21:19:42 <kencjohnston> sarob_ Count me in as well, happy to help people onboard
21:19:45 <shamail> I think it would even be a good page for our wiki in general
21:19:55 <shamail> I'll be glad to help as well
21:20:12 * hughhalf nods
21:21:26 <sgordon> sarob_, can i get you to textualize the options we are voting on here
21:21:32 <sgordon> since it sounds like we're up to 3?
21:21:51 <shamail> sgordon: +1
21:21:59 <kencjohnston> sgordon +1
21:22:13 <sarob_> Okay
21:22:26 <kencjohnston> Being a first time IRC only, it is definitely hard to follow the phone conversation without constant scribing.
21:22:35 <sarob_> Sorry speaking and writing not strong point
21:22:38 <kencjohnston> shamail I feel your pain :)
21:22:47 <kencjohnston> sarob_ It's an impossible tasks, no worries
21:22:48 <shamail> haha kencjohnston, ditto!
21:22:50 <sarob_> Here's what to vote on
21:23:10 <sarob_> Vote for today
21:23:35 <sarob_> To hold the weekly
21:23:53 <rockyg> you found us, Arkady_Kanevsky
21:23:53 <sarob_> Meetings for the project team on IRC only
21:24:06 <sarob_> No conference call or etherpad
21:24:09 <Arkady_Kanevsky> hello team
21:24:19 <kencjohnston> hi @Arkady_Kanevsky!
21:24:20 <sarob_> As part of the regular
21:24:22 <shamail> hi Arkady_Kanevsky
21:24:27 <sarob_> Meetings
21:24:36 <sarob_> Doesn't hold back adhoc
21:24:40 <Arkady_Kanevsky> while we wait; where do we record projects roadmap?
21:24:57 <pchadwick> What is the advantage of IRC only?
21:24:59 <shamail> #link openstack.org/roadmap
21:25:03 <Arkady_Kanevsky> I want to add roadmap for tempest and rally
21:25:05 <shamail> its at that link Arkady_Kanevsky
21:25:23 <rockyg> Ooh!  god question!  I see lots of mail.  It would be great if I could just copy it over to a Prod wg when I see it.
21:25:29 <shamail> oh, I will follow-up with you on that topic via email Arkady_Kanevsky... We haven't reached a new cycle yet to add projects
21:25:33 <sarob_> #startvote hold weekly scheduled product team meetings on IRC only
21:25:35 <openstack> Unable to parse vote topic and options.
21:25:55 <shamail> I think you need options sarob_ ?
21:26:12 <sarob_> sarob_ #startvote hold weekly scheduled product team meetings on IRC only yes no
21:26:14 <Arkady_Kanevsky> thanks shamail, what about project WG keep roadmap for future releases?
21:26:19 <shamail> #vote yes
21:26:38 <kencjohnston> #vote yes
21:26:54 <KrishR> #vote yes
21:26:56 <shamail> I'll add you to the google drive share Arkady_Kanevsky... the last slide deck is at the link I posted earlier
21:26:59 <sgordon> #vote yes
21:27:17 <hughhalf> #vote yes
21:27:21 <shamail> Do we have no votes on the phone?  we need to account for them as well
21:27:30 <pchadwick> #vote no
21:27:31 <shamail> no votes as in a "vote for no"
21:27:34 <shamail> lol
21:27:42 <leong> #vote no
21:27:42 <dpk_> #vote no
21:27:46 <Arkady_Kanevsky> Suggest that we allow votes on IRC or email.
21:27:46 <sarob_> #vote yes
21:27:51 <rockyg> so, one issue here, is the voting didn't really start because of a bad command format
21:27:52 <MeganR> #vote no
21:28:01 <shamail> he did it again
21:28:05 <rockyg> So, this will get redone.
21:28:09 <sarob_> Can't vote formly
21:28:20 <sarob_> Over email
21:28:29 <shamail> ah, I thought your second one took effect?
21:28:38 <shamail> I think over email is a good idea sa
21:28:41 <Arkady_Kanevsky> #vote no - in favor to allow voting on email also
21:28:43 <shamail> sarob_, I meant
21:28:50 <kencjohnston> yeah you want something like this #startvote Should we have our weekly meetings conducted via IRC only? Yes, No, Don't Care
21:28:55 <shamail> there are people (e.g. Carol) that are on vacation atm
21:29:00 <sarob_> sarob_ #startvote hold weekly scheduled product team meetings on IRC only? yes, no, maybe
21:29:08 <sgordon> ok good practice voting everyone
21:29:09 <sgordon> :D
21:29:16 <kencjohnston> sgordon :)
21:29:17 <sgordon> sarob_, it is coming up with your prefix
21:29:22 <sgordon> "sarob_ #startvote"
21:29:29 <sgordon> #startvote has to be start of the line
21:29:30 <openstack> Only the meeting chair may start a vote.
21:29:40 * sgordon slaps openstack around with a trout
21:29:43 <sarob_> sarob_ #startvote hold weekly scheduled product team meetings on IRC only? Yes, No, Maybe
21:30:02 <shamail> not too much sgordon!! it's supposed to be only "a bit" of slapping
21:30:07 <sarob_> sarob_ sarob_ #startvote Hold weekly scheduled product team meetings on IRC only? Yes, No, Maybe
21:30:16 * hughhalf assures everyone that IRC is easier, really :)
21:30:16 <rockyg> #startvote --help
21:30:16 <openstack> Only the meeting chair may start a vote.
21:30:35 <shamail> His syntax looks good... just the prefix
21:31:06 <dpk_> Need to step away for a minute, excuse me please.
21:31:07 <sarob_> Moving on
21:31:13 <shamail> wait
21:31:20 <kencjohnston> Hey team, I've got to leave, I did have one agenda item to discuss. IF we decide to host the Mid-cycle with the Operators Meetup in the UK, Rackspace will host the mid-cycle at our London Office (2 hour train ride from Manchester, by Heathrow). Bonus, the office includes a replica of #10 Downing Street, a slide and a building of James Bond themed things.
21:31:22 <shamail> so are we delaying sarob_ ? voting over email?
21:31:23 <sarob_> I will push the vote to the ML
21:31:26 <shamail> what was the result?
21:31:27 <shamail> okay
21:31:29 <sarob_> Yes
21:31:32 <sarob_> Isn't working
21:31:36 <shamail> can you please assign yourself an #action so its in the log
21:31:55 <sarob_> #topic midcycle planning
21:32:18 <shamail> #action sarob_ to send out a poll for meeting preference to ML
21:32:39 <shamail> Thanks kencjohnston!  We'll keep that as an option.
21:32:45 <sarob_> #action sarob post vote for the meeting IRC to the ML
21:32:52 <shamail> Thanks to Rackspace for volunteering as well
21:33:03 <KrishR> sorry, i have to leave too
21:33:06 <rockyg> ops still debating whether to have a single midcycle (this time Europe), or regional ones.  Once Ops decides on path, Prod WG can settle date and location of Midcycle
21:33:08 <shamail> Take care KrishR
21:33:22 <sarob_> Anyone else?
21:33:34 <shamail> agreed rockyg, I think the ops team is leaning towards a single but no confirmation yet
21:33:41 <Arkady_Kanevsky> I think we need onin NA.
21:33:45 <shamail> I can follow-up with Tom to get closure
21:34:17 <shamail> Arkady_Kanevsky: we might still have one... the discussion is around whether there will only be one "official" while others are regional (e.g. NA could still have another one)
21:34:27 <sarob_> #action Shamail will follow up on ops timing with tom
21:34:35 <shamail> thanks sarob_
21:34:40 <Arkady_Kanevsky> right
21:34:45 <dpk_> back
21:34:49 <shamail> wb
21:35:12 <sarob_> I'm still good with two events
21:35:21 <sarob_> Moving on?
21:35:23 <shamail> two is manageable
21:35:27 <shamail> sarob_: +1
21:36:20 <dpk_> +1 to 2 events
21:37:19 <sarob_> #action sarob propose Jan f2f place and time
21:37:24 <sgordon> #info Ops mid-cycle February 15 & 16, Manchester, UK
21:37:27 <sarob_> Moving on
21:37:29 <sgordon> #link https://wiki.openstack.org/wiki/Operations/Meetups
21:37:44 <sarob_> #topic user story updates
21:37:56 <sarob_> #chair Shamail
21:37:57 <openstack> Current chairs: Shamail sarob_
21:38:19 <shamail> sarob_: did we decide to have f2f seperate from ops-meetup?
21:38:24 <sarob_> Leong Kenny?
21:38:27 <leong> The Rolling Upgrade team met last week
21:38:27 <leong> https://etherpad.openstack.org/p/PWG-Rolling-Upgrades-2015-11-17
21:38:30 <shamail> (sorry for asking this after topic change)
21:38:46 <leong> Reviewing the current user story from the sub-team
21:38:48 <sarob_> Shamail nope, just idea of additional one
21:38:57 <shamail> thx sarob_  :)
21:39:08 <leong> will collecting related blueprint to the Upgrade user story
21:39:33 <leong> Also looking at resources from Rax/Intel OSIC to support the development of the user story (e.g. blueprint)
21:39:33 <sarob_> Any feedback?
21:39:41 <leong> Questions?
21:39:50 <shamail> Hi leong
21:39:57 <leong> next meeting is tomorrow
21:39:58 <leong> :-)
21:40:06 <shamail> Have we identified technical SMEs for this user story already?
21:40:23 <Arkady_Kanevsky> rolling upgrade requires DB hygeine user story
21:40:34 <shamail> You mentioned collecting blueprints but are we going to create cross-project specs too?
21:40:45 <leong> shamail: not yet
21:41:08 <leong> yes. i think we also need cross-project specs
21:41:11 <leong> need to work on that
21:41:17 <shamail> leong: +1
21:41:20 <shamail> thanks!
21:41:33 <leong> DB hygiene.. yes.. I noted that.
21:42:14 <sarob_> Is there any db cleanup work out there yet?
21:42:16 <leong> there is a separate db_hygience user story in draft folder
21:42:18 <rockyg> configuration changes from one release to another also have to be overlaid onto the existing site configs
21:42:54 <sarob_> If work is ongoing make sure it is referenced
21:43:05 <shamail> sarob_: +1
21:43:14 <sarob_> Get the contributors to comment on the user story
21:43:52 <leong> https://github.com/openstack/openstack-user-stories/blob/master/user-stories/proposed/rollingupgrades.rst
21:43:59 <shamail> Arkady_Kanevsky: Please make changes to https://review.openstack.org/#/c/237178/ so that we can review it again
21:44:20 <sarob_> Continue with the next meeting
21:44:24 <leong> db_hygiene is not merged yet
21:44:27 <sarob_> Next topic
21:44:42 <sarob_> Your meeting tomorrow right?
21:45:12 <rockyg> need to ping ops ML on what is missing from upgrade process/code that they need besides DB migrations.
21:45:17 <leong> sarob_: u mean Upgrade? yes we meeting tomorrw
21:45:28 <sarob_> Jay and Derek update on onboarding hosts and VMs
21:45:34 <shamail> #link https://wiki.openstack.org/wiki/ProductTeam/User_Stories/Rolling_Upgrades
21:45:43 <shamail> for meeting details
21:45:52 <sarob_> Thx
21:46:02 <shamail> Jay and Deric on the phone?  Neither are in IRC atm
21:46:07 <sgordon> i can go
21:46:16 <sgordon> complex instance placement >.>
21:46:17 <sarob_> Sure
21:46:17 <shamail> thx sgordon
21:46:21 <sgordon> #link http://specs.openstack.org/openstack/openstack-user-stories/user-stories/draft/complex_instance_placement.html
21:46:37 <sgordon> so ah, basically this is a use case we had defined in the context of the telco working group
21:47:00 <sgordon> it is primarily focused on more complex affinity/anti-affinity placement concepts
21:47:16 <leong> do we need to form a sub-team to work on the Telco user story?
21:47:22 <sgordon> it's been merged into the repo, need to determine next steps to move
21:47:41 <sgordon> theoretically we are thinking the remaining telco wg folk will help work on it
21:47:43 <shamail> sgordon: Could this be merged with "onboarding pets" user story?
21:47:50 <sgordon> as we are winding down the separate working group
21:47:53 <sgordon> mmm not really
21:48:05 <sgordon> in the context calum proposed it i believe it is actually a built for cloud app
21:48:11 <shamail> The second user story (traditional db server shards) was the reason I asked
21:48:14 <sgordon> with many instances involved
21:48:16 <sgordon> ah right
21:48:17 <shamail> got it
21:48:23 <sgordon> yes that was added as part of transition
21:48:34 <sgordon> in that i certainly think it is a requirement seen in some pets too
21:48:44 <leong> the "onboarding" user story has two tracks.. one is led by Jay/Derric(IBM/HP) on "resources". The other one will be led by Gerg on "app"
21:48:48 <sgordon> so in that context maybe
21:48:55 <shamail> gotcha
21:49:36 <sgordon> i need to go back and remind myself of the process to go from draft->proposed
21:49:43 <sgordon> to define next steps
21:50:31 <sarob_> #action sgordon define complex instance placement next steps
21:50:35 <shamail> sgordon: please review https://wiki.openstack.org/wiki/ProductTeam/User_Stories and I (or others) can help with any resulting questions
21:50:38 <Arkady_Kanevsky> do we have a user story submitted for review for it?
21:50:41 <sgordon> ack
21:50:53 <sgordon> it is actually merged as draft
21:50:58 <sgordon> i posted the link in the backlog ^
21:51:16 <sgordon> http://specs.openstack.org/openstack/openstack-user-stories/user-stories/draft/complex_instance_placement.html
21:51:29 <sarob_> Shamail can I move your mitaka ops feedback to the ML
21:51:33 <Arkady_Kanevsky> I see it on the webpage but not in submitted stories.
21:51:36 <leong> shamail: looking at the complex_instance_place at my first quick glance,think that might be different from "onboarding pets"
21:51:48 <shamail> The main thing I am debating is whether complex instance placement a user story belonging to another parent or whether we create a new parent (e.g. Affinity) and add this as one user story under it
21:51:54 <sarob_> So Rockyg can talk stable with the remaining time
21:52:02 <shamail> While your case is for compute, it could also apply to storage resources
21:52:16 <shamail> sarob_: np, happy to move that to ML
21:52:54 <sarob_> #topic stable release team discussion
21:53:10 <sgordon> shamail, it can probably fit under another i suspect
21:53:25 <shamail> leong: I agree, the second user story in complex instance is what made me think onboarding pets but I think it isn't any more
21:53:29 <Arkady_Kanevsky> enterprise usually upgrade once a year. Our current upgrade plan only wokrs from one release to next (whne it works)
21:53:29 <sgordon> shamail, there was already another nova backlog spec that is not super unrelate either
21:53:46 <shamail> thanks sgordon, look forward to hearing your thoughts on how to proceed after reviewing the workflow
21:53:48 <sarob_> Rockyg 75% users on 1 year plus releases
21:53:50 <shamail> next topic :)
21:53:51 <leong> having a second read/thoughts... could be part of the use case scenario in "onboarding legacy app"
21:53:54 <pchadwick> Arkady +1
21:54:14 <leong> :)
21:54:19 <shamail> rockyg: I am working with my organization to see if we can get some interest in helping with stable branches too
21:54:32 <sarob_> Distributions are supporting post supported stable release
21:54:45 <sarob_> S all separately
21:54:52 <Arkady_Kanevsky> does the upstream openstack responsible for support for multiple years and upgrading them or is that job better handled by distros?
21:54:55 <shamail> sarob_: they are supporting but the challenge for consumers is two-fold:
21:54:58 <sarob_> Bad for collaboration and community
21:55:08 <pchadwick> But the fixes all go upstream
21:55:09 <sgordon> a point of clarification here, i believe distributors are typically operating a fork albeit with a minimal delta from day 0
21:55:12 <sgordon> not from stable eol
21:55:12 <shamail> 1) each distro has their own policy of when EOL will occur so can't make same assumptions cross-vendor
21:55:27 <sgordon> the reason for this is that not all changes the distro may want to consume are eligible for upstream stable
21:55:29 <shamail> and 2) for DIY consumers, we are forcing an upgrade almost every year
21:55:32 <sgordon> which has very specific rules
21:55:37 <sarob_> Shamail agreed
21:55:39 <shamail> I'd rather have them upgrade when the window is right
21:55:45 <sarob_> Sgordon agreed
21:55:48 <leong> some vendor distro provides support upto 3-5 years
21:55:56 <sgordon> i dont state that as a reason not to extend stable
21:55:57 <shamail> sgordon: agreed
21:56:07 <sarob_> But we want community to share the load
21:56:16 <sgordon> but simply to state that it should not be a goal to get the distributors having a 100% equal tree
21:56:17 <sarob_> Includes the distributions
21:56:25 <sgordon> that would be a nice side effect
21:56:30 <sgordon> but shouldnt be the goal
21:56:32 <sarob_> Sgordon not my interest
21:56:41 <sarob_> Right
21:56:56 <shamail> and we want to let OpenStack consumers know that regardless of vendors (or even going your own way)... you will have some time to plan for upgrades.
21:57:03 <sarob_> Think security bug two years post release
21:57:20 <shamail> N-2 being supported by community would cover 70%+ of OpenStack clouds
21:57:24 <sarob_> Many other reasons
21:57:27 <shamail> (based on usersurvey)
21:58:30 <sgordon> there are two aspects here, the stable team (project now i guess) and also the stable branch cores for each project
21:58:33 <sarob_> Product team is ideally placed to understand and support stable releAse bugs with some developer time
21:58:37 <shamail> So sarob_ and rockyg, what is the request/discussion with regards to this topic for the product WG?
21:58:41 <pchadwick> We are being asked for 2 year support = n+3
21:58:55 <sgordon> i think immediately, resource commitments
21:59:12 <shamail> pchadwick, agreed... I have seen that too but that might be too much load for community + infra
21:59:15 <sgordon> resource commitments leading to resolving the issues thierry and others cited with this process in the past
21:59:22 <sgordon> which would then allow extension of the eol in future
21:59:23 <sarob_> The question is 1 year public stable isn't enuf
21:59:27 <shamail> sgordon: +1
21:59:33 <sarob_> What is enuf, not sure
21:59:40 <pchadwick> We don't have a problem with committing resource to support
21:59:46 <sgordon> resources here means developers but also possibly infra
22:00:29 <pchadwick> How much infra per supported release?
22:00:32 <shamail> I have already started discussions inside my company... will be able to relay results by next month
22:00:53 <sarob_> Cool
22:00:57 <shamail> pchadwick: good question... I think some of that may also have to do with velocity of changes coming in
22:01:08 <sarob_> Defcore supports three releases now
22:01:10 <pchadwick> My guess is that the velocity is not high
22:01:10 <leong> if this is a decision from the team to support longer release.. i could try to ask if OSIC could help on dev resources
22:01:23 <shamail> pchadwick, I would agree too
22:01:26 <sgordon> pchadwick, well that is another question tho
22:01:33 <sgordon> pchadwick, some people would like to see more velocity
22:01:42 <sgordon> pchadwick, more active backporting of stuff from master
22:01:44 <shamail> leong: it might be good to bring it up with OSIC
22:01:51 <pchadwick> Yes - backporting is an issue.
22:02:12 <sarob_> #action Sarob and team follow up release team on ML
22:02:15 <Arkady_Kanevsky> thanks!
22:02:15 <sarob_> #endmeeting