=== markthomas|away is now known as markthomas === markthomas is now known as markthomas|away === kees_ is now known as kees [16:00] hello [16:00] \o [16:03] hrm [16:04] * slangasek waves [16:05] \o/ === markthomas|away is now known as markthomas [16:06] http://ubottu.com/meetingology/logs/ubuntu-meeting-2/2015/ubuntu-meeting-2.2015-03-31-16.02.html says kees is chair? [16:06] else mdeslaur [16:07] * stgraber waves [16:08] kees: are you chairing? :) [16:08] * mdeslaur waits a minute for kees [16:09] ok, looks like kees is a no-show again [16:09] #startmeeting [16:09] Meeting started Tue Apr 14 16:09:24 2015 UTC. The chair is mdeslaur. Information about MeetBot at http://wiki.ubuntu.com/meetingology. [16:09] Available commands: action commands idea info link nick [16:09] [topic] Apologies [16:09] nobody [16:09] [topic] Action review [16:09] nothing [16:10] [topic] Mailing list archive [16:10] so it looks like we've responded on-list to MAAS [16:10] whoops [16:10] to docker [16:10] does anyone have anything else they'd like to say about the new docker proposal? [16:10] +1 on that, LGTM now [16:11] the previous per-series packaging was scary, but that's gone now [16:11] yeah, +1 from me as well. [16:12] caribou: *prod* [16:12] yes, just want to have TB's opinion on an MRE for sosreport [16:13] it is a fast moving project with many new inclusions [16:13] and not possible to adhere to SRU rules when adding new plugins [16:13] caribou: That description is exactly the opposite of what MREs are (usuaully) for. [16:13] what does that do, roughly? [16:13] so I think that it would be beneficial to have the current upstream version on Ubuntu for all stable rel [16:14] collect configuration & logs on running systems for offline analtysis [16:14] i. e. a program which shows and manually sends data, or automatic in the background, etc? [16:14] it seems to be pretty self-contained and nothing seems to depend on it, so at least there's that [16:15] for instance, a new plugin was added for cloud-init which will not be available to any of the stable release [16:15] since it is not part of any stable release and will only make it to "W" [16:15] it sends it to a location you configure, or to canoincal? [16:15] so the possibility to have the same 'recent' version on stable release would be a bonus [16:15] manual [16:15] i. e. with SRUs is there a chance that we'd suddenly leak private data which it didn't before on that release? [16:15] infinity: I was told that MRE would be a solution for that [16:15] it's not really an MRE [16:15] pitti: manual [16:15] but that's a nomenclature question [16:16] TBH I think I need some more details of what that does, how new versions impact stable releases, etc. [16:16] conceptually, as a tool that's used by support to gather information from a customer's system, I think it makes sense to allow it to be updated [16:17] because the extent of the interface from the user is "run this command, get results back from the Canonical support team" [16:17] pitti: there is confidential data scrubbing built in, but there is always a chance of bugs around this [16:17] caribou: if that's manual configurations, how do me make sure that newer upstream releases work with older configs, and don't suddenly drop config options/information that's sent, or change their format? [16:17] so it seems analogous to me to other exceptions we've made for software where the server interface has changed [16:17] just that in this case the "server interface" is the support team [16:18] pitti: but this would affect the dev release in the same way [16:18] ah, so it does send data to Caonical, not to the admin's servers [16:18] pitti: the tool doesn't send anything [16:19] pitti: it produces a tarball to be uploaded "somewhere" by the user [16:19] ah, ok [16:19] pitti: the only output is a tarball in /tmlp [16:19] s/tmlp/tmp [16:19] I'm not against it conceptually. [16:19] so it's intended for e. g. the Canoincal support team, so it's ok if the format/content changes? [16:19] As Martin says, though, are there config files, is migration guaranteed to be sane, etc? [16:20] yeah, I'm mostly interested in what this does structurally, and what's the worst thing that can happen [16:20] .. if a new upstream version changes format or drops files, etc. [16:20] pitti: worst thing is that some collection would be missing (which is the case in the current situation) [16:20] perhaps we could better decide if you sent an email to the list with a description of what the tool does, who uses it, what config is uses, what it produces, and the types of changes that have happened in the past? [16:20] pitti: this is the current situation with SRU [16:21] mdeslaur: that was my intent, but I wanted a first feeling for it [16:21] mdeslaur: no point in formally proposing it if the first reaction is totally negative [16:21] I'm generally not opposed to SRU exceptions as long as they are done in a safe and sane way [16:22] I'm open to the idea, I think this type of tool is something that is definitely worth considering for an exception [16:22] pitti: I think that regression issues would be restricted to the output content [16:22] ^ agreed; I woudl just like to understand what exactly it is and what the impact is :) [16:22] caribou: right, understood [16:22] mdeslaur: pitti: Fine, I will send an email with all the details requested [16:23] caribou: so I'm trying to find out whether that would break automatic evaluation of the content [16:23] caribou: ok, I think we're all open to the idea, and we'll await your post [16:23] thanks to the TB, this will help in writing the email [16:23] this is all I had [16:23] caribou: thanks [16:23] thanks caribou [16:24] doesn't look like there was anything else to discuss on the list [16:24] [topic] Community bugs [16:24] None [16:24] [topic] Next chair [16:25] looks like it's pitti? [16:25] or kees. :P [16:25] ack [16:25] ;) [16:25] ok, so kees if he's still alive, then pitti [16:25] Yes, that. [16:25] Does anyone have anything else they would like to discuss? [16:26] nothing from me [16:26] not I [16:26] ok, that's it for today folks [16:26] #endmeeting [16:26] Meeting ended Tue Apr 14 16:26:43 2015 UTC. [16:26] Minutes: http://ubottu.com/meetingology/logs/ubuntu-meeting-2/2015/ubuntu-meeting-2.2015-04-14-16.09.moin.txt [16:26] thanks! [16:26] thanks! [16:26] thanks! [16:27] cheers [16:27] thanks! === markthomas is now known as markthomas|away === markthomas|away is now known as markthomas