[16:03] <rharper> \o
[16:03] <caribou> o/
[16:03] <matsubara> o/
[16:03] <jgrimm> o/
[16:03] <arges> o/
[16:03] <thedac> o/
[16:04] <smb> o/
[16:05] <beisner> o/
[16:06] <smoser> o/
[16:06] <smoser> heyt.
[16:06] <smoser> i guess its me.
[16:06] <smoser> whoops
[16:06] <smoser> #startmeeting ubuntu-server-team
[16:06] <meetingology> Meeting started Tue Aug 25 16:06:49 2015 UTC.  The chair is smoser. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
[16:06] <meetingology> Available commands: action commands idea info link nick
[16:06] <smoser> #topic Review ACTION points from previous meeting
[16:07] <smoser> seems like agenda did not get updated i think...
[16:07] <smoser> as my caction item bug 1461242  there is fixe
[16:07] <smoser> i'll remvoe that
[16:07] <smoser> other item listed there is :
[16:07] <smoser>  Thoughts about numad
[16:08] <smoser> anyone know of more content on that ?
[16:08] <rharper> I've not poked the team
[16:08] <smoser> ok, well please add that to TODO list / bump its priority
[16:08] <rharper> smoser: it's a background action item for me to collect team thoughts on whether we should have something like numad and other NUMA related placement stuff
[16:09] <smoser> #action rharper collect team thoughts on whether we should have something like numad and other NUMA related placement stuff
[16:09] <meetingology> ACTION: rharper collect team thoughts on whether we should have something like numad and other NUMA related placement stuff
[16:09] <smoser> #topic Wily Development
[16:09] <smoser> #link https://wiki.ubuntu.com/WilyWerewolf/ReleaseSchedule
[16:09] <smoser> beta1 freeze is thursday.
[16:09] <smoser> and we're past feature freeze now.
[16:09] <smoser> so ffe will have to be opened for any new features uyou want.
[16:10] <smoser> anything else ?
[16:10] <smoser> #subtopic Release Bugs
[16:10] <caribou> yes,
[16:10] <smoser> ok... go caribou
[16:10] <caribou> nm, I'll bring that up at my turn
[16:10] <caribou> carry on
[16:11] <smoser> k
[16:11] <smoser> #subtopic Release Bugs
[16:11] <smoser> #link http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-w-tracking-bug-tasks.html#ubuntu-server
[16:11] <smoser> loading...
[16:13] <smoser> i have one there for keepalived , bu have been out for thelast two weeks.
[16:13] <smoser> i'll try to get proress on that by next week.
[16:13] <smoser> anyone interesated in others ?
[16:13] <smoser> seems like wesley may hav made progress on https://launchpadlibrarian.net/214863711/wily-debdiff
[16:13] <smoser> err.. on https://launchpadlibrarian.net/214863711/wily-debdiff
[16:13] <smoser> someone want to shepard that through ?
[16:14] <smoser> ok. well, that one at very least seems like we shoudl do some mocvement on it.
[16:14] <magicalChicken> smoser: Yeah, I got a fix uploaded for that one
[16:15] <magicalChicken> smoser: I need someone to sponsor it though
[16:15] <smoser> oh. ok. magicalChicken i can see if i can do that for you.
[16:15] <magicalChicken> smoser: Awesome, thanks
[16:15] <rbasak> I'm behind on sponsoring team bugfixes. Shall I gather a list maybe of who in the team is waiting on sponsorship and try and work through them?
[16:15] <rbasak> Though if smoser wants to work on this one feel free :)
[16:16] <smoser> thanks. for those playing along at home, magicalChicken == wesley
[16:16] <rbasak> magicalChicken, smoser: note: on my very quick glance you need to s/Closes/LP: #/ in the changelog entry. Closes refers to Debian bugs so it won't autoclose the LP one otherwise.
[16:16] <smoser> i'm way behind on other things too as a week out did.
[16:16] <smoser> so i'll leave that to rbasak or smoser
[16:16] <smoser> and we'll move on, but yeah, you want to reference the ubuntu bug with:
[16:16] <rbasak> I'll happily take an action to sponsor all outstanding sponsorship requests before the next meeting.
[16:17] <magicalChicken> rbasak: Aah, i didn't know that. I'll fix that
[16:17] <smoser>  LP: #1478149
[16:17] <rbasak> mag	no problem!
[16:17] <smoser> moving on.
[16:17] <smoser> k ?
[16:17] <smoser> #topic Server & Cloud Bugs (caribou)
[16:17] <caribou> my request for sponsorship of the rsyslog merge didn't get picked up
[16:17] <caribou> & we're passed FF
[16:17] <rbasak> Sorry :-/
[16:17] <caribou> I'dl like the audience opinion on going for FFE on this one
[16:18] <caribou> so it gets its bits shaken before LTS
[16:18] <rbasak> I was swamped around feature freeze and didn't manage to get through all requests.
[16:18] <rbasak> I still have a pile of FFEs to do.
[16:18] <caribou> rbasak: no worry, I pinged a few others who were swamped as well :)
[16:18] <smoser> caribou, your rsyslog ?
[16:18] <caribou> I have a potential sponsor now if I get the FFE through
[16:18] <smoser> oh. merge.
[16:19] <rbasak> I'm not sure it makes sense to FFE everything we missed. It just means that we have less time to fix bugs.
[16:19] <caribou> smoser: yes, current is 7.4.4 and debian has 8.9.0
[16:19] <smoser> i'd personlly feel ok to push a ffe for rsyslog.
[16:19] <smoser> as we would like to have that newer version for x
[16:19] <rbasak> OTOH I have no objection to individuals driving their own FFEs.
[16:19] <smoser> and having it cook longer would be good
[16:19] <caribou> I'm fine with preparing it & let the server team drive it
[16:20] <rbasak> I don't want to take on driving more FFEs - I have a number I'm taking care of already
[16:20] <rbasak> And if I take on more, then they're only going to slip anyway.
[16:20] <caribou> rbasak: true; ok I'll lead this one & may ask for help  on my way
[16:20] <smoser> ok. well, then . seems like unless someone steps up that will drop
[16:20] <smoser> :-(
[16:21] <caribou> smoser: it won't, I'll do it
[16:21] <rbasak> I'm fine with that caribou - thanks.
[16:21] <smoser> ah. ok. good.
[16:21] <smoser> #topic Weekly Updates & Questions for the QA Team (matsubara)
[16:21] <smoser> caribou, above, if you do have questions, please feel free to ask.
[16:21] <matsubara> nothing new to report smoser
[16:21] <caribou> smoser: k
[16:21] <smoser> #topic Weekly Updates & Questions for the Kernel Team (smb, sforshee, arges)
[16:21] <smb> Nothing here that I can think of right now. Are there questions?
[16:23] <smoser> k
[16:23] <smoser> #topic Upcoming Call For Papers
[16:23] <smoser> anything here ?
[16:24] <smoser> i dont have anything.
[16:24] <smoser> #topic Ubuntu Server Team Events
[16:24] <smoser> anyone speaking or attending soon and want to mention ?
[16:24] <smoser> #topic Open Discussion
[16:24] <rharper> smoser: on the bcache-tools sru to trusty
[16:25] <smoser> ah. yeah.
[16:25] <rharper> smoser: you were saying that we probably don't need the TB exception since we wouldn't be regressing things vs. upstream ?
[16:26] <smoser> unles we put it into an image, then we're virtually guaranteed to not regress aything
[16:26] <rharper> wouldn't it go into either cloud image or ephemeral? or just rely on them to pull it down from archive as needed ?
[16:26] <rbasak> I don't think the SRU team will accept it under current SRU policy without a TB-approved exception, but we can see.
[16:26] <rharper> updated curtin for example, will auto pull in lvm2, mdadm and bcache-tools
[16:26] <smoser> sru team would probasbly accept it.
[16:27] <smoser> other than putting it into an image.
[16:27] <smoser> if its not in an image, then it wont regress anything.
[16:27] <smoser> its generally ok to put new things ito old releases for important feature / hardware enablement./
[16:27] <rbasak> I agree that it probably won't regress anything. I'm sure the SRU team won't object on that basis either.
[16:27] <smoser> but putting it into a maas ephemeral image means it becomes part of the default install of a maas from ubuntu
[16:28] <smoser> which i can see as possible potential for regression
[16:28] <rbasak> But AFAIK no "important feature" has ever been SRU'd as new package that wasn't hardware enablement without a TB exception.
[16:29] <rharper> in either case (as I have a write up for the TB); the bigger issue IMO is the edge testing on bcache-tools
[16:29] <rbasak> Anyway, it doesn't really matter. It won't create extra or duplicate work whichever way we decide to approach this, so I don't mind either way.
[16:29] <rharper> while both server and maas teams have been using the bcache-tools package and bcache feature
[16:29] <rbasak> If the SRU team want an exception from the TB then we can ask for one - there won't be any harm done.
[16:30] <smoser> rharper, well, putting buggy bcache-tools into trusty isnt necessarily bad on its own.
[16:30] <rharper> I don't feel those have been edge tested, ie, what happens when we drop the cache device, changing cache modes, recovery, twiddling the sysfs writable values on bcache;
[16:30] <rharper> smoser: it's an LTS
[16:30] <rharper> so it can hurt for longer
[16:30] <smoser> except for when it is annoyingly buggy
[16:30] <smoser> and bcache-utils *is* annoyingly buggy
[16:30] <rharper> well
[16:30] <rharper> sorta
[16:30] <rharper> the main function doesn't appear that way
[16:31] <rharper> but it's quite awkward to deal with
[16:31] <smoser> right.
[16:31] <smoser> which could happen unintentionally
[16:31] <rharper> which is why I started on that bcache-release script to help folks "cleanup" the mess
[16:31] <rharper> yes
[16:31] <smoser> thats the point i think is important really.
[16:32] <smoser> is that you're essentially suggesting it become part of a default install
[16:32] <smoser> and thus it requires significantly more thought
[16:32] <rharper> as per maas request
[16:32] <smoser> than just adding a package to the archive that will not be used by someone unless they "opt in"
[16:32] <rharper> to make trusty  ~= vivid ~= wily w.r.t storage config features
[16:32] <rharper> ok
[16:33] <smoser> so.. i'd say go to TB i guess.
[16:33] <rharper> and include some bits on in archive, vs. in image
[16:33] <smoser> and be clear that your intent is to add it to a "default install". as i think thats the intent.
[16:33] <rharper> and a follow up with maas, can they get by with 'in archive' vs. 'in image'
[16:34] <smoser> if instead curtin will install it into the ephemeral image and then into the target only when it is needed, then it requires much less scrutiny in my opintion
[16:34] <smoser> becase even then, its essentially "opt in" by a user of maas.
[16:34] <rharper> that's how it is today
[16:34] <rharper> and unless maas complains about the extra hit to archive to pull in deps
[16:34] <rharper> likely not since we're not going to put lvm2 nor mdadm into default install, no ?
[16:35] <rharper> smoser: it didn't seem likely given your discussion re: mdadm + mail dep in #ubuntu-devel the other week
[16:35] <rbasak> That's going to slow down the install though, no?
[16:35] <rharper> so I don't think bcache-tools not in default install is a significant burden since it still has lvm2 and mdadm to install
[16:35] <rharper> rbasak: indeed
[16:35] <rbasak> We don't really want curtin to have to install packages locally in the long term.
[16:35] <rharper> but we'd need all 3 deps to be in
[16:35] <smoser> shoot. i had to follow up on that... i thought the discussion ended with 'lets add it'.
[16:35] <rbasak> It might be acceptable for Trusty though.
[16:35] <rharper> smoser: maybe it did; I only saw the initial discussion w.r.t the mail deps
[16:36] <smoser> i'm on same page with rbasak.
[16:36] <rharper> folks saying, no if I have a raid I really would like to have it send an email if something is wrong (w.r.t the madm dep on postfix)
[16:36] <smoser> we want the default install to have those things, so we should work to get them into wily and then X
[16:36] <smoser> but if we can live with trusty being less than perfect than that is good.
[16:36] <rharper> so trusty and vivid need runtime deps installed via curtin
[16:37] <rharper> wily could be fixed and in=place for x
[16:37] <rbasak> Yeah. X is only round the corner now anyway.
[16:37] <rharper> trusty and vivid
[16:37] <rharper> but, yes
[16:37] <rharper> unless you rebuild those images IIUC
[16:37] <smoser> well the images are re-built, but we'd have to add those packages.
[16:37] <rharper> sure
[16:38] <rbasak> That's a good point. If you implement in curtin with a test, it'll always be possible to get a local speed up by hacking your local ephemeral image if it matters to you.
[16:38] <smoser> ok. so i think this is beaten.  i guess you should go ahead to TB.
[16:38] <smoser> rharper, and we should get those packages into wily cloud and maas images.
[16:38] <rharper> smoser: ok, can you add the action items then ?
[16:38] <rharper> are we OK with the level of edge testing then ?
[16:39] <smoser> #action rharper send email to TB about bcache-utils into trusty
[16:39] <meetingology> ACTION: rharper send email to TB about bcache-utils into trusty
[16:39] <rharper> that was the only thing holding me back before sending to TB
[16:39] <caribou> bcache-utils == bcache-tools ?
[16:39] <rharper> yes
[16:39] <smoser> right
[16:40] <smoser> #action smoser, rharper get other packages into cloud-image necessary for storage features.
[16:40] <meetingology> ACTION: smoser, rharper get other packages into cloud-image necessary for storage features.
[16:40] <rharper> smoser: ok, I'm good
[16:41] <smoser> #topic Announce next meeting date, time and chair
[16:41] <smoser> next meeting will be Tuesday, September 1 at 16:00 UTC
[16:41] <smoser> chair will be gnuoy
[16:41] <smoser> #endmeeting
[16:41] <meetingology> Meeting ended Tue Aug 25 16:41:54 2015 UTC.
[16:41] <meetingology> Minutes:        http://ubottu.com/meetingology/logs/ubuntu-meeting/2015/ubuntu-meeting.2015-08-25-16.06.moin.txt
[16:42] <caribou> smoser: thanks!
[17:00] <jsalisbury> #startmeeting
[17:00] <meetingology> Meeting started Tue Aug 25 17:00:28 2015 UTC.  The chair is jsalisbury. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
[17:00] <meetingology> Available commands: action commands idea info link nick
[17:00] <jsalisbury> ##
[17:00] <jsalisbury> ## This is the Ubuntu Kernel Team weekly status meeting.
[17:00] <jsalisbury> ##
[17:00] <jsalisbury> [LINK] https://wiki.ubuntu.com/KernelTeam/Meeting
[17:00] <jsalisbury> [LINK] https://wiki.ubuntu.com/KernelTeam/ReleaseStatus/Wily
[17:00] <smb> o/
[17:00] <jsalisbury> # Meeting Etiquette
[17:00] <cking> o/
[17:00] <henrix> o/
[17:00] <ppisati> o/
[17:00] <jsalisbury> #
[17:00] <jsalisbury> # NOTE: '..' indicates that you are finished with your input.
[17:00] <jsalisbury> #       'o/' indicates you have something to add (please wait until you are recognized)
[17:01] <jsalisbury> [TOPIC] Release Metrics and Incoming Bugs (jsalisbury)
[17:01] <jsalisbury> Release metrics and incoming bug data can be reviewed at the following link:
[17:01] <jsalisbury> [LINK] http://kernel.ubuntu.com/reports/kt-meeting.txt
[17:01] <jsalisbury> ..
[17:01] <jsalisbury> [TOPIC] Status: CVE's
[17:02] <jsalisbury> The current CVE status can be reviewed at the following link:
[17:02] <jsalisbury> [LINK] http://kernel.ubuntu.com/reports/kernel-cves.html
[17:02] <jsalisbury> ..
[17:02] <jsalisbury> [TOPIC] Status: Stable, Security, and Bugfix Kernel Updates - Precise/Trusty/Utopic/Vivid (bjf)
[17:02] <bjf> Status for the main kernels, until today:
[17:02] <bjf>   *     Precise - Verification & Testing
[17:02] <bjf>   *      Trusty - Verification & Testing
[17:02] <bjf>   *  lts-Utopic - Verification & Testing
[17:02] <bjf>   *      Vivid  - Verification & Testing
[17:02] <bjf>  
[17:02] <bjf> Current opened tracking bugs details:
[17:02] <bjf>   * http://kernel.ubuntu.com/sru/kernel-sru-workflow.html
[17:02] <bjf> For SRUs, SRU report is a good source of information:
[17:02] <bjf>   * http://kernel.ubuntu.com/sru/sru-report.html
[17:02] <bjf>  
[17:02] <bjf>  
[17:02] <bjf> Schedule:
[17:02] <bjf>  
[17:02] <bjf> cycle: 16-Aug through 05-Sep
[17:02] <bjf> [17:02] <bjf>          14-Aug   Last day for kernel commits for this cycle
[17:02] <bjf> 15-Aug - 22-Aug   Kernel prep week.
[17:03] <bjf> 23-Aug - 29-Aug   Bug verification & Regression testing.
[17:03] <bjf> 30-Aug - 05-Sep   Regression testing & Release to -updates.
[17:03] <bjf> ..
[17:03] <jsalisbury> [TOPIC] Open Discussion or Questions? Raise your hand to be recognized (o/)
[17:04] <jsalisbury> Thanks everyone
[17:04] <jsalisbury> #endmeeting
[17:04] <meetingology> Meeting ended Tue Aug 25 17:04:19 2015 UTC.
[17:04] <meetingology> Minutes:        http://ubottu.com/meetingology/logs/ubuntu-meeting/2015/ubuntu-meeting.2015-08-25-17.00.moin.txt
[17:05] <kamal> thanks jsalisbury