[17:01] \o [17:01] * slangasek waves [17:02] * infinity is very not here today. [17:03] infinity: uh, meaning? [17:03] mdeslaur: Mentally, I mean. Completely checked out and concentrating on other things. [17:03] mdeslaur: But I'm clearly present. :P [17:04] I see [17:04] I hope other people show up, I really want to discuss what to do with docker [17:07] We had long talks about it at the CDO sprint. [17:07] But it would be nice if someone could summarize those on the list. [17:07] oh? interesting [17:08] It's going to (likely) involve a "strong suggestion" from Mark, which may or may not result in a sabdfling if we don't all agree with said suggestion. :P [17:08] I keep thinking what would be nice is a pocket for stuff that is in a constant state of flux, for stuff that we want the latest upstream until the next LTS [17:08] The ball's in the server team's court to write a sane proposal and throw it at us, however. [17:08] mdeslaur: $series-volatile. [17:09] infinity: yes, just like that [17:09] mdeslaur: But that really just shifts the problem. [17:09] well, it clearly sets people's expectations [17:09] mdeslaur: And if it's software that will have lots of users, I don't see how it actually solves anything. [17:09] I don't think we're doing our users a favour by having an outdated docker that nobody is going to fix, security-wise [17:09] mdeslaur: Stuff that's known volatile can't ship in the release/updates/security pockets at all, or we have to support two versions, old and latest. [17:10] right, I believe the consensus there was that, given the principles expressed it warrants a bit of an exception for docker; however we're currently waiting for the server team to follow through and express those same principles publicly for the TB to consider as a whole [17:10] mdeslaur: So... You're just moving the package around to tag it differently with a tag no one will read. ;) [17:10] mdeslaur: Unless volatile is opt-in, and then it will be vetoed by Mark because he wants docker and, say, firefox to be available by default without twiddling. [17:11] infinity: well, the tag means "you are going to get the latest here, until the next LTS, with no promises of abi compatibility, or stability" [17:11] unless we don't mind doing that for certain packages in the regular archive [17:11] mdeslaur: Sure, I'm saying that if it's in the default sources.list, no one will pay attention to where apt got it from. But meh. [17:11] such as, for example, docker [17:11] mdeslaur: We already do it for firefox, but I always trot out firefox as the evil exception that should do the exact opposite of setting the rule. [17:11] the kicker is the "supported for 5 years" [17:12] upgrading to the latest and greatest for 5 years is IMHO unachievable [17:12] the docker package is in universe, however, so there's no actual support guarantee anyway? [17:12] true [17:12] and what about stuff like maas? [17:13] MaaS can't even seem to keep the promises they made to me a year ago. [17:13] So, we'll see. :P [17:13] exactly :) [17:13] * stgraber waves [17:13] hi stgraber! [17:13] stgraber: That was a quick flight... [17:13] stgraber: I assumed you were doing something involving oceans. [17:13] stgraber: you missed out a few words about docker [17:13] mdeslaur: He was in the sprint talks, he didn't miss anything here. :) [17:14] stgraber: http://paste.ubuntu.com/10276238/ [17:14] mdeslaur: Except for the volatile bikeshedding. [17:15] infinity: so you're saying you'd simply prefer to allow version upgrades in the universe pocket, rather than having one that's specific for that? [17:15] infinity: yeah, that was just YUL to IAD, I'm heading towards Santa Rosa but got a couple more flights to make it :) [17:15] mdeslaur: As for the maas tangent, the reason I am still carrying that maas SRU policy action item is because the team's recently gone through some upheaval, and I'm hoping I can get them to fix their process in light of them having tossed out half the team. :P [17:16] mdeslaur: I have no opinion on main vs universe in the matter, I honestly think we should treat them both the same, except for what CANONICAL supports. No TB policy should make community support policies harder/different. [17:17] mdeslaur: But on a case-by-case basis, I think it can something be acceptable to apply the firefox exception. I just think those cases are amazingly rare. [17:17] mdeslaur: But "code's moving way too fast to backport because security fixes usually mean a 5% LOC rewrite" is a fair argument, perhaps. :/ [17:18] yeah, that's unfortunately what happened with docker [17:18] it's not a 5 line patch that you just need to backport [17:18] mdeslaur: Yes, and I wasted a year of my life doing subsystem-backports-as-static-functions and other such evil for mozilla. :P [17:19] perhaps a new term is needed, something other than "Micro Release Exception", which doesn't even make sense for Firefox [17:19] mdeslaur: The nail in the mozilla coffin was the combination of that and people wanting/needing the latest and shiniest in web standards, and we caved. Much to my delight. [17:19] giving it a name only increases the chance that we'll use this exception :) [17:19] heh [17:19] "Herpes" [17:20] I think the intersection between "essential to our users to have in a stable release" and "can't be security supported except by tracking upstream" is small enough that we don't necessarily need to generalize [17:20] mdeslaur: I feel docker probably fits both those criteria (code moving too quickly to backport, and users actually needing, rather than wanting, new features as they land) for the next short while. It should stabilise as it actually GETS more users, since they can't break them willy-nilly. [17:21] slangasek: And yes, I agree. Codifying any of this just encourages more people to apply for the exception we don't want to give them. Case-by-case analysis with a default position of "heck no" seems sane to me. [17:21] slangasek: ok, I agree [17:21] infinity: I agree with the "heck no" + exceptions too [17:22] and yeah, once the project matures, this will likely be less of an issue [17:24] so, what specifically do we do with the docker case? wait for the server team to come up with a new proposal, or grant an exception now? [17:26] another aspect of the discussion at the CDO sprint was that we would be getting a formal request from docker upstream, rather than just proxying through Canonical's server team [17:26] I want to see their proposal to make sure they digested the contents of the (multiple) meetings we had on the topic. [17:26] at least in theory [17:26] And that. [17:26] so I'm waiting to see that happen [17:27] oh, great [17:27] ok, so we'll wait then. [17:27] hrm, who is chairing? [17:27] slangasek: was it you? [17:28] um, I didn't think so [17:28] :) [17:28] slangasek: surprise! :) [17:28] 17:23 [INFO] pitti possibly to chair in stgraber's place due to sprint [17:28] That was the last word on the last meething. [17:28] which makes it stgraber's turn this time, no? :) [17:29] I do believe so. [17:29] stgraber: surprise! :) [17:29] He may be AFK running through an airport or something. [17:30] I nominate stgraber to chair the next 3 meetings [17:30] well no one gaveled us in so all the preceding discussion is seemingly "off the record" anyway :/ [17:31] #startmeeting [17:31] Meeting started Tue Feb 17 17:31:36 2015 UTC. The chair is mdeslaur. Information about MeetBot at http://wiki.ubuntu.com/meetingology. [17:31] Available commands: action commands idea info link nick [17:31] [topic] Apologies [17:31] pitti couldn't make it [17:31] [topic] Action review [17:31] "infinity to review and respond to MAAS SRU thread " [17:32] infinity: so, carry? [17:32] As stated, I'll revisit that with the new team when they seem settled. Carry. [17:32] Or, the reorged team. Whatever. [17:32] [topic] Mailing list archive [17:33] docker -> awaiting proposal from server team and/or upstream [17:33] reSIProcate package [17:33] The reSIProcate MRE request looks sane at first glance. [17:34] I seem to have missed this [17:34] https://lists.ubuntu.com/archives/technical-board/2015-February/002080.html [17:34] thanks [17:35] ah, arrived in my email at some point backdated [17:36] looks reasonable to me [17:36] looks reasonable to me also [17:37] ok, let's respond to list [17:37] Doesn't look like there's anything else on the list [17:38] [topic] Community bugs [17:38] None [17:38] [topic] Next chair [17:38] stgraber :P [17:38] since stgraber dodged this time, I think he's up next ;) [17:38] stgraber! :) [17:38] that's it...does anyone have anything else they would like to discuss? [17:39] Some day, we might want to sort out why the community bugs are always zero, and either stop caring, or start driving people toward filing some. [17:39] not me [17:39] I think the bugs are a vestigial process; all the documentation drives people to the mailing list [17:40] Right, so possibly the "stop caring" bit. But I guess it doesn't hurt to take 5 seconds to load the URL and count to 0. [17:40] but we probably shouldn't drop it from our agenda unless we actually remove the launchpad project [17:40] * slangasek nods [17:40] oh, and it's not actually our project to drop :) [17:41] I wonder if we'd be more visible having our meeting in #ubuntu-meeting (if there wasn't a scheduling conflict) [17:42] #endmeeting [17:42] Meeting ended Tue Feb 17 17:42:53 2015 UTC. [17:42] Minutes: http://ubottu.com/meetingology/logs/ubuntu-meeting-2/2015/ubuntu-meeting-2.2015-02-17-17.31.moin.txt [17:42] thanks everyone [17:43] Toodles.