[16:01] <jamespage> arosales, I see you in the chair today - OK with that?
[16:01] <arosales> jamespage, yes sir
[16:02] <jamespage> arosales, good man!
[16:02] <smoser> o/
[16:02] <jamespage> \o
[16:02] <arosales> startmeeting ubuntu-server-team
[16:03] <arosales> #startmeeting ubuntu-server-team
[16:03] <meetingology> Meeting started Tue Nov 12 16:03:06 2013 UTC.  The chair is arosales. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
[16:03] <meetingology> Available commands: #accept #accepted #action #agree #agreed #chair #commands #endmeeting #endvote #halp #help #idea #info #link #lurk #meetingname #meetingtopic #nick #progress #rejected #replay #restrictlogs #save #startmeeting #subtopic #topic #unchair #undo #unlurk #vote #voters #votesrequired
[16:03] <arosales> #topic Review ACTION points from previous meeting
[16:03]  * arosales doesn't see any action items from the previous meeting
[16:03] <arosales> #topic Saucy Development
[16:03] <arosales> I guess we should update that to trusty dev
[16:04] <jamespage> done
[16:04] <arosales> #link https://wiki.ubuntu.com/TrustyTahr/ReleaseSchedule
[16:04] <arosales> Looks like next milestone is the Feature Definition Freeze
[16:04] <arosales> Alpha 1 on Dec 19th
[16:05] <arosales> #subtopic Release Bugs
[16:05] <jamespage> which means feature definition freeze is at the end of vUDS
[16:05] <arosales> #link http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-s-tracking-bug-tasks.html#server
[16:05] <arosales> jamespage, ah good point
[16:06] <arosales> be good to finalize those features in vUDS
[16:06] <arosales> so looking @ http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-s-tracking-bug-tasks.html#server
[16:06] <arosales> looks to have 27 bugs for ubuntu-server
[16:06] <jamespage> quite a few of those are SRU tasks for juju-core
[16:06] <jamespage> I got a bit carried away
[16:07] <arosales> jamespage, thanks or logging them
[16:07] <arosales> need to have those back into the lts
[16:07] <arosales> one critical bug
[16:07] <jamespage> arosales: I need to apply for a MRE for juju-core
[16:07] <arosales> http://launchpad.net/bugs/1229275
[16:07] <jamespage> yah
[16:07] <arosales> jamespage, +1 on MRE for juju-core, moving pretty fast am
[16:07] <jamespage> so all of the fixes are avaliable in the stable juju ppa
[16:07] <jamespage> but the distro package is now out-of-date
[16:07] <jamespage> for saucy
[16:08] <arosales> thus the SRUs
[16:08] <jamespage> yup
[16:08] <arosales> is 1229275 a fix in maas though?
[16:09] <jamespage> roaksoax, is the maas multi-env destroy fix already in proposed?
[16:09] <jamespage> that might be a dupe arosales
[16:09] <roaksoax> jamespage: yes
[16:09] <jamespage> roaksoax, ack
[16:09] <roaksoax> jamespage: in fact, is already released
[16:09] <jamespage> arosales: yes the maas tasks for that can be dropped
[16:09] <arosales> roaksoax, can you update 1229275
[16:10] <arosales> jamespage, ok if we hit the high unresolved bugs?
[16:10] <roaksoax> sure
[16:10] <arosales> roaksoax, thanks
[16:10] <jamespage> good with me
[16:10] <arosales> only one critical,
[16:10] <arosales> next are highs
[16:10] <arosales> http://launchpad.net/bugs/1208455
[16:11] <arosales> looks like stefan bader is assigned
[16:11] <arosales> in progress and confirmed . .  .
[16:11] <arosales> looks like rbasak assigned this one
[16:12] <arosales> but no objections by stefan
[16:12] <jamespage> I'm not entirely sure why that is high
[16:12] <jamespage> smb is not here to defend his position!
[16:12] <arosales> looks like not action needed atm though
[16:12] <jamespage> agreed
[16:12] <rbasak> I think somebody probably told me to assign it when I wanted an assignment at a previous meeting.
[16:12] <jamespage> its an odd edge case IMHO
[16:12] <jamespage> rbasak, I remember that
[16:13] <arosales> http://launchpad.net/bugs/1245251
[16:13] <rbasak> IMHO, we should either stop tracking it, or assign someone
[16:13] <hallyn_> that'll get fixed when we push 1.1.4 to trusty
[16:13] <rbasak> Then we can focus on the stuff we intend to fix.
[16:13] <arosales> hallyn_, is that for apparmor?
[16:13] <hallyn_> yes
[16:13] <arosales> hallyn_, thanks
[16:14] <arosales> http://launchpad.net/bugs/1199791
[16:14] <arosales> the next ones are for zul
[16:14] <zul> uh?
[16:14] <arosales> zul I think you are the assignee
[16:14] <zul> oh wait..yeah still pending its going to be changing in the trusty cycle
[16:14] <arosales> ok
[16:14] <arosales> zul and for http://launchpad.net/bugs/1223010
[16:15] <zul> (damn daylight daying hours)
[16:15] <zul> arosales:  i talked to upstream last week they are going to be moving to oauthlib
[16:15] <arosales> zul thnks
[16:15] <arosales> thanks
[16:15] <arosales> https://bugs.launchpad.net/maas/+bug/1228085
[16:15] <arosales> looks like gavin has a fix
[16:15] <arosales> but needs to be worked in saucy
[16:16] <arosales> roaksoax, any opinions?
[16:17] <arosales> jamespage, SRU needed here?
[16:17] <jamespage> the tasks are raised so most likely
[16:17] <arosales> jamespage, any actions needed for the SRUs?
[16:18] <arosales> http://launchpad.net/bugs/1236439
[16:18] <roaksoax> arosales: that was fixed too
[16:18] <jamespage> arosales: yes - still needed
[16:19] <arosales> roaksoax, ah even better. Could you update the bug if it is indeed fixed in saucy and trusty
[16:19] <jamespage> roaksoax, is it?
[16:19] <jamespage> I just checked in 2.2
[16:19] <roaksoax> jamespage: yeah I fixed it differently, IIRC. Gonna have a deeper look
[16:20] <jamespage> arosales: that neutron bug is reference upstream inthe havana release notes
[16:20] <jamespage> roaksoax, ack
[16:20] <arosales> roaksoax, thanks, could you update the bug post your research?
[16:20] <jamespage> I've pinged upstream to see if a helper is going to appear for upgraders
[16:20] <arosales> jamespage, ack on the neutron bug
[16:20] <roaksoax> arosales: yup
[16:20] <arosales> roaksoax, thanks
[16:20] <arosales> http://launchpad.net/bugs/1242363
[16:20] <arosales> puppet bug
[16:21] <arosales> packaging issue . .  .
[16:21] <arosales> rbasak, looks to confirmed ruby-hiera  fixes it
[16:21] <arosales> rbasak, next action needed to update puppet deps or add in ruby-hiera?
[16:21] <rbasak> It's on my list.
[16:22] <rbasak> I'm hoping to combine it with a merge when I get to it, and then SRU.
[16:22] <arosales> rbasak, would you like to assign yourself?
[16:22] <rbasak> Done
[16:22] <arosales> rbasak, thank you sir
[16:22] <arosales> thats the last high
[16:22] <arosales> have a few undecided that need triaged
[16:23] <arosales> I think most of them are around juju-core
[16:23]  * arosales thinks those are the SRUs jamespage was referring to
[16:23] <jamespage> yes
[16:23] <arosales> #subtopic Blueprints
[16:23] <arosales> jamespage, smoser looks like we also need a trusty topic BP
[16:24] <jamespage> arosales: we do - is that something you can setup?
[16:24] <arosales> jamespage, sure
[16:24] <arosales> #action arosales to set up topic bp for server
[16:24] <meetingology> ACTION: arosales to set up topic bp for server
[16:24] <jamespage> for now - https://blueprints.launchpad.net/ubuntu?searchtext=servercloud-1311
[16:24] <arosales> #link http://status.ubuntu.com/ubuntu-s/group/topic-s-servercloud-overview.html
[16:24] <jamespage> that's what we have on the list for next week
[16:24] <arosales> we should postpone the rest of these though
[16:25] <jamespage> arosales: I'd leave it until after next week
[16:25] <jamespage> we can carry stuff over and close old bp's out
[16:25] <jamespage> https://wiki.ubuntu.com/BlueprintSpec
[16:25] <arosales> jamespage, smoser do you want to step through these and mark postponed as necessary?
[16:25] <arosales> jamespage, ack
[16:25] <jamespage> ^^ blueprint spec for new blueprints
[16:26] <arosales> #action jamespage, smoser,  review all saucy BPs
[16:26] <meetingology> ACTION: jamespage, smoser,  review all saucy BPs
[16:26] <smoser> deal
[16:26] <arosales> where is gaughen
[16:26]  * arosales wanted to put in an action item there too
[16:26] <gaughen> I'm right here!
[16:27] <jamespage> I see gaughen
[16:27]  * jamespage waves
[16:27] <arosales> #action gaughen review saucy BPs
[16:27] <meetingology> ACTION: gaughen review saucy BPs
[16:27]  * gaughen waves back
[16:27] <arosales> ah autocomplete just failed me
[16:27] <arosales> action items set ;-)
[16:27] <arosales> #topic Server & Cloud Bugs (caribou)
[16:27] <gaughen> k
[16:28] <jamespage> mia
[16:28] <arosales> ok
[16:28] <arosales> #topic Weekly Updates & Questions for the QA Team (psivaa)
[16:29] <psivaa> nothing much from us apart from the fact that our services are down at the moment
[16:29] <psivaa> due to 1SS hardware move
[16:29] <jamespage> psivaa, any eta on returning service?
[16:29]  * jamespage hates to ask
[16:30] <psivaa> jamespage: the core services should start late this evening and the rest will be tomorrow
[16:30] <jamespage> ack
[16:30] <arosales> psivaa, ok thanks for the update
[16:30] <psivaa> yw :)
[16:30] <arosales> any other questions for psivaa
[16:30] <arosales> #topic Weekly Updates & Questions for the Kernel Team (smb)
[16:30] <jamespage> mia as well
[16:31] <arosales> jamespage, thanks for letting me know :-)
[16:31] <arosales> #topic Weekly Updates & Questions regarding Ubuntu ARM Server (rbasak)
[16:31] <jamespage> we had one thing we where working on with kernel team
[16:31] <jamespage> openvswitch-dkms drop for 14.04
[16:31] <rbasak> Nothing new to report from me. Any questions?
[16:31] <jamespage> can't quite make it but all of the mainline features we need are in 3.13; only need dkms for experimental stuff
[16:32] <arosales> jamespage, need a vUDS session on that or all coordination happening in a bug?
[16:32] <jamespage> no
[16:33]  * arosales takes it as no vuds sessions needed
[16:33] <jamespage> it will be covered in other sesssions
[16:33] <arosales> jamespage, ack
[16:33] <arosales> #topic Ubuntu Server Team Events
[16:33] <arosales> so lots of stuff wrapping up
[16:33] <arosales> ODS
[16:33] <arosales> RubyConf last  week
[16:33] <arosales> AWS re:Invent this week
[16:34] <arosales> any other events?
[16:34] <arosales> #topic Open Discussion
[16:35] <arosales> all folks in-line with https://wiki.ubuntu.com/BlueprintSpec ?
[16:36] <arosales> jamespage one point of feedback I got, perhaps around "user acceptance"
[16:36] <arosales> is how do we know this particular feature is a "success"
[16:36] <arosales> ie what is the metric to measure the bp was actually successfully
[16:37] <arosales> jamespage, thoughts?
[16:37] <jamespage> its quite subjective; but it could be anything from some dep-8 tests to a more detail decription on how to use a new feature in the docs
[16:37] <hallyn_> or does 'feature is a success' mean that the users got what they wanted?
[16:38] <jamespage> actually that's a good point - 14.04 will have associated ubuntu-server docs; so don't forget to include doc tasks in your blueprints
[16:38] <arosales> sorry, its more of what the folks working on the BP define as success
[16:38] <jamespage> hallyn_, I think it means that you can demonstrate how the use cases documented are fulfilled
[16:38] <arosales> ie if dep-8 test pass that is a _metric_ for success
[16:38] <arosales> but that is definitive, and measurable.
[16:39] <arosales> it should tie directly to the goal, but be more straightforward on how the goal is going to be specifically meet.
[16:40] <arosales> basically what are tangible working towards, and how do we know we are done
[16:40] <arosales> thoughts?
[16:40] <arosales> perhaps this is covered in an existing template point . . .
[16:41] <arosales> crickets
[16:41] <jamespage> those are the ones in my head doing that
[16:41] <gaughen> so I'm way late here - but another event  coming up is vUDS
[16:42] <jamespage> I think it comes down to how do you demonstrate that a feature is implemented
[16:42] <arosales> jamespage, correct
[16:42] <arosales> jamespage, basically I was looking for a way to document _when_ the feature is complete.
[16:42] <hallyn_> that's the halting problem
[16:43] <arosales> hallyn_, please expand
[16:43] <arosales> gaughen, good point on http://uds.ubuntu.com/
[16:43] <arosales> #link http://uds.ubuntu.com/
[16:43] <gaughen> arosales, it's on my mind because of having to host some sessions ;-)
[16:43] <hallyn_> arosales: nah, just being a wiseass
[16:43] <arosales> hallyn_, jamespage so any bp work we define should have a deliverable we can measure and define as done
[16:43] <gaughen> arosales, it's hallyn_'s turn today to be the wiseass
[16:43] <jamespage> yup
[16:43] <arosales> if we don't have that how do we know it was done and done well?
[16:44] <jamespage> so when arosales comes along and say - show me - you can point and say - there!
[16:44] <jamespage> and he can try it himself!
[16:44] <arosales> yup, no ambiguity as to what is going to be delivered.
[16:45] <hallyn_> the bp tracks the work items.  we mark them as done.  we trust that we dont' mark them as done if they're not.  you're asking for something higher level.
[16:45] <arosales> ie _this_ is what we are defining for delivery of this feature and what we will call success
[16:45] <arosales> success = we delivered what we set out to and meet user stories and the goal
[16:45] <arosales> but needs to be tangible, and quantifiable
[16:45] <hallyn_> each work item is that
[16:46] <arosales> hallyn_, so those are pieces
[16:46] <arosales> what are those pieces incrementally working to deliver?
[16:46] <arosales> hallyn_, not high level
[16:46] <hallyn_> as someone said, that's the user stories
[16:47] <arosales> hallyn_, what I am looking for when all work items are done what specifically did the BP deliver?
[16:47] <arosales> is it?
[16:47] <hallyn_> arosales: user stories.  i know what you're getting at, but i don't think it's a good use of our time to try and build test cases - and run them - for each user story
[16:48] <hallyn_> maybe it is, in which case we may have to have fewer work items so we have time for that
[16:48] <hallyn_> but i think that's what uds is for each time - gauge last cycle, plan next.
[16:48] <hallyn_> anyway maybe we ned to discuss elsewhere
[16:49] <arosales> sure, I just don't think we are doing a great job of stating what is tangibly delivered
[16:49] <arosales> hallyn_, not a test case for each user story
[16:49] <arosales> just a specific deliverable stating what this BP is going to be delivered, that we can measure
[16:49] <arosales> perhaps that sets better in the goal
[16:49] <arosales> if the goal is written well. . .
[16:50] <arosales> in any case I have beaten that to death
[16:50] <arosales> I"ll try to write up something for the goal section
[16:50] <hallyn_> ok
[16:50] <arosales> #topic Announce next meeting date and time
[16:51] <arosales> Tuesday 2013-11-19 at 1600 UTC - #ubuntu-meeting
[16:51] <hallyn_> let's not
[16:51] <arosales> thanks for joining
[16:51] <hallyn_> arosales: that's uds
[16:51] <jamespage> thanks arosales
[16:51] <arosales> hallyn_, ah good point
[16:51] <hallyn_> nov 26?
[16:51] <arosales> #action arosales send email to server list to cancel Nov 19 server meeting in liu of UDS
[16:51] <meetingology> ACTION: arosales send email to server list to cancel Nov 19 server meeting in liu of UDS
[16:52] <arosales> nov 26 may collide with us holidy too
[16:52] <hallyn_> eeeeh, maybe.  i'll be here.  misses by 2 days.
[16:52] <arosales> Thanksgiving may later in the week
[16:53] <arosales> Tuesday 2013-11-26 at 1600 UTC - #ubuntu-meeting
[16:53] <arosales> thanks everyone
[16:53] <arosales> #endmeeting
[16:53] <meetingology> Meeting ended Tue Nov 12 16:53:21 2013 UTC.
[16:53] <meetingology> Minutes (wiki):        http://ubottu.com/meetingology/logs/ubuntu-meeting/2013/ubuntu-meeting.2013-11-12-16.03.moin.txt
[16:53] <meetingology> Minutes (html):        http://ubottu.com/meetingology/logs/ubuntu-meeting/2013/ubuntu-meeting.2013-11-12-16.03.html
[16:53] <hallyn_> thanks arosales