Started logging meeting in #ubuntu-meeting<br />
[12:56:17] &lt;mdz&gt; [link] https://wiki.ubuntu.com/TechnicalBoardAgenda<br />
<a name='0'></a>
[12:57:30] &lt;kees&gt; \o<br />
[12:59:00] &lt;mdz&gt; pitti isn't online, so I assume he isn't going to make it<br />
[12:59:07] &lt;mdz&gt; sabdfl declined in the calendar<br />
[12:59:38] &lt;mdz&gt; cjwatson is online, but he's on holiday, so he presumably won't be here<br />
[12:59:59] &lt;kees&gt; is 3 quorum?<br />
[13:00:04] * mdz nods<br />
[13:00:21] &lt;mdz&gt; we've regarded it as such in the past<br />
[13:00:29] &lt;kees&gt; yeah, that's my memory too<br />
[13:00:33] &lt;mdz&gt; [topic] Action review<br />
<a name='1'></a>
[13:00:41] &lt;mdz&gt; Persia to see if Bryce is willing to serve as LP stakeholder for Ubuntu<br />
[13:01:16] &lt;mdz&gt; I've asked bryce asynchronously for an update<br />
[13:01:22] &lt;mdz&gt; [topic] ffmpeg vs. libav<br />
<a name='2'></a>
[13:01:41] &lt;mdz&gt; I guess this was discussed some at the last meeting, which I wasn't present for<br />
[13:01:57] &lt;mdz&gt; the notes said that we wanted to hear from Reinhard, and he's responded now<br />
[13:01:59] &lt;mdz&gt; [link] https://lists.ubuntu.com/archives/technical-board/2011-May/000891.html<br />
<a name='3'></a>
[13:02:23] &lt;kees&gt; right. given that I've seen both sides of this, I think I'm satisfied to stay where we are: libav<br />
[13:02:47] &lt;kees&gt; trying to track ffmpeg would require a dedicated maintainer, and Ubuntu does not seem to have anyone willing to do that currently.<br />
[13:02:57] &lt;kees&gt; I only see downsides to switching from libav.<br />
[13:03:11] &lt;mdz&gt; libav is the status quo, so we would need a justification to switch away from it<br />
[13:03:50] &lt;kees&gt; right, and I don't see anything significant to do that currently.<br />
[13:04:59] &lt;mdz&gt; it's all feeling a little bit cdrecordish to me<br />
[13:05:46] &lt;mdz&gt; Keybuk, any thoughts?<br />
[13:05:51] &lt;kees&gt; bryce: we're looking at https://wiki.ubuntu.com/TechnicalBoardAgenda and have "Persia to see if Bryce is willing to serve as LP stakeholder for Ubuntu". can you speak to this at all?<br />
[13:06:09] &lt;mdz&gt; <bryce> sure, I'd be happy to help<br />
[13:06:14] &lt;Keybuk&gt; mdz: I don't believe I have the necessary background<br />
[13:06:18] &lt;Keybuk&gt; all I saw was flamewar<br />
[13:06:18] &lt;bryce&gt; kees, yes we spoke a couple UDSes ago, and yes I'd be happy to help<br />
[13:06:38] &lt;kees&gt; bryce: ah-ha, perfect. thanks!<br />
[13:07:06] &lt;kees&gt; Keybuk: did you have additional questions based on the techboard thread?<br />
[13:07:24] &lt;Keybuk&gt; kees: I didn't see anything in the techboard thread that led me to have technical questions<br />
[13:07:49] &lt;Keybuk&gt; nothing suggested ffmpeg was technically better, so I don't see any need to dispute the current maintainer decisions<br />
[13:08:06] &lt;Keybuk&gt; <insert joke about the community council being the one that deals with childish disputes :p><br />
[13:08:16] &lt;kees&gt; Keybuk: okay, so you're okay with status quo too.<br />
[13:08:24] &lt;mdz&gt; OK, so this came in as an inquiry from an upstream developer, suggesting that what the Ubuntu maintainer had done was not in the best interest of our users<br />
[13:08:46] &lt;mdz&gt; I haven't heard of any complaints from our users about it yet<br />
[13:08:47] &lt;Keybuk&gt; mdz: it came from the upstream developer of a package we weren't using though, right?<br />
[13:08:58] &lt;mdz&gt; Keybuk, yes<br />
[13:09:15] &lt;Keybuk&gt; I must admit, I wrote that of us "how dare Ubuntu not use *my* software, and use something else"<br />
[13:09:20] &lt;mdz&gt; if someone wanted to maintain the other fork in Ubuntu as well, and make both available to users, that wouldn't seem unreasonable to me<br />
[13:09:23] &lt;Keybuk&gt; and then failed to find any technical argument from the author as to why we should<br />
[13:09:46] &lt;Keybuk&gt; mdz: agree<br />
[13:09:49] &lt;mdz&gt; but if the maintainer chose to follow libav, the TB can't tell them whether they should package something else<br />
[13:10:07] &lt;mdz&gt; they should be regarded as different software at this point<br />
[13:10:23] &lt;mdz&gt; one is packaged for Ubuntu, the other is not yet (but would be welcome)<br />
[13:10:28] &lt;mdz&gt; kees, does that seem like a reasonable position to you?<br />
[13:10:37] &lt;kees&gt; mdz: yup.<br />
[13:10:53] &lt;mdz&gt; OK, I'll follow up on the list<br />
[13:10:55] &lt;Keybuk&gt; to me also<br />
[13:11:05] &lt;mdz&gt; [action] mdz to summarize consensus on libav/ffmpeg to the mailing list<br />
<a name='4'></a>
[13:11:07] &lt;kees&gt; they would have colliding binary packages, though<br />
[13:11:27] &lt;mdz&gt; kees, that could presumably be fixed in packaging<br />
[13:11:32] * kees nods<br />
[13:11:36] &lt;mdz&gt; [topic] Set series RM to ubuntu-release?<br />
<a name='5'></a>
[13:11:44] &lt;mdz&gt; [link] https://bugs.launchpad.net/ubuntu-community/+bug/174375/comments/21<br />
<a name='6'></a>
[13:11:45] &lt;ubottu&gt; Ubuntu bug 174375 in Launchpad itself "Distribution drivers permissions may need redesign" [Low,Triaged]<br />
[13:11:48] &lt;mdz&gt; the bug mentioned there is now fixed<br />
[13:12:01] &lt;mdz&gt; so in theory we should be able to set the series release manager to ubuntu-release<br />
[13:12:08] &lt;kees&gt; let's do it and see what breaks?<br />
[13:12:18] &lt;mdz&gt; let's tell people that we're doing it, and then do it, and see what breaks :-)<br />
[13:12:26] &lt;mdz&gt; any volunteers?<br />
[13:13:01] &lt;kees&gt; seems like it should be coordinated with skaet at least?<br />
[13:13:14] &lt;mdz&gt; yse<br />
[13:13:15] &lt;mdz&gt; yes<br />
[13:14:05] &lt;kees&gt; I'm not entirely comfortable volunteering myself for this since these discussions have mostly been involved people doing archive admin work, so perhaps cjwatson?<br />
[13:14:15] &lt;kees&gt; s/been //g<br />
[13:14:41] &lt;mdz&gt; we can push this to the next meeting where cjwatson is here<br />
[13:14:42] &lt;mdz&gt; it's not urgent<br />
[13:14:49] &lt;kees&gt; ok<br />
[13:14:52] &lt;mdz&gt; [topic] Measuring installation success/failure<br />
<a name='7'></a>
[13:15:03] &lt;mdz&gt; [link] https://lists.ubuntu.com/archives/technical-board/2011-May/000857.html<br />
<a name='8'></a>
[13:15:10] &lt;mdz&gt; [link] https://lists.ubuntu.com/archives/ubuntu-devel/2011-May/033194.html<br />
<a name='9'></a>
[13:15:45] &lt;kees&gt; aiui, ev is looking for a TB "blessing" for this data gathering.<br />
[13:15:55] &lt;mdz&gt; I like the general idea of gathering data which will give us an indication of how effective our installer is<br />
[13:16:25] &lt;kees&gt; I generally do too. I remain unconvinced that the proposed data gather is substantially useful, though.<br />
[13:17:13] &lt;kees&gt; *gathering<br />
[13:17:14] &lt;mdz&gt; Evan wasn't crystal clear about what he wanted decided<br />
[13:17:18] &lt;mdz&gt; and several issues have cropped up in the discussion<br />
[13:17:30] &lt;mdz&gt; Keybuk was concerned about how the collected data would be shared<br />
[13:17:56] &lt;mdz&gt; kees, I think that's a valid concern, but perhaps not something for the TB to decide<br />
[13:18:11] &lt;mdz&gt; I think it's Evan's responsibility to make it useful, and our responsibility to set policy for what's permissible<br />
[13:18:32] &lt;kees&gt; mdz: that's fair<br />
[13:19:16] &lt;mdz&gt; kees, and FWIW I would recommend to evan that he consider your advice carefully :-)<br />
[13:20:08] &lt;mdz&gt; so the policy questions I think are regarding what data is collected, and what we do with it<br />
[13:20:12] &lt;kees&gt; right. I don't want to get us into the trap where we approve "meaningless data collection" since it's harmless, and then end up on an unregulated slippery slope of "harmful" data collection just happening without review.<br />
[13:20:44] &lt;mdz&gt; what is proposed to be collected is a GUID<br />
[13:21:04] &lt;kees&gt; right, it's a random number. I have no problem with that.<br />
[13:21:31] &lt;mdz&gt; ah, right, he did specify how it would be generated (uuidgen)<br />
[13:21:33] &lt;mdz&gt; so it's random<br />
[13:21:51] &lt;mdz&gt; that ID is associated with an installation attempt which was started<br />
[13:22:16] &lt;mdz&gt; specifically, a Ubiquity installation attempt<br />
[13:22:55] &lt;mdz&gt; it's then used to report back that the installation succeeded<br />
[13:23:37] &lt;mdz&gt; the user implicitly shares their IP address in the process, of course<br />
[13:24:28] &lt;mdz&gt; what's the worst thing that could be done with that information?<br />
[13:24:46] &lt;kees&gt; the correlation of guid to IP can also be seen as an identity leak, since it could be used in the future<br />
[13:25:09] &lt;Keybuk&gt; you could use the table of IPs collected to discern which Fortune 500 companies were using Ubuntu<br />
[13:25:14] &lt;kees&gt; if we did not save the IP on the server side, and did not keep the GUID after install success on the client side, I think that would be okay<br />
[13:25:17] &lt;Keybuk&gt; since they tend to have public IP blocks<br />
[13:26:00] &lt;mdz&gt; kees, agreed, but ideally we wouldn't have to ask for that trust<br />
[13:26:12] &lt;mdz&gt; kees, what's the identity leak?<br />
[13:27:03] &lt;kees&gt; mdz: if the guid is saved on the client and the IP is saved on the server, it can be used to look up from what IP a given system was installed from. it's pretty minor, obviously.<br />
[13:27:30] &lt;kees&gt; (assuming the server data is public)<br />
[13:27:41] &lt;mdz&gt; the GUID would only be saved on the client until the next time it connected to the network<br />
[13:27:46] &lt;mdz&gt; according to evan's proposal<br />
[13:27:52] &lt;Keybuk&gt; if the IP is saved on the server, the information could be used by Canonical Support Sales to identify potential customers and sell support contracts to them<br />
[13:28:06] &lt;kees&gt; right, I was stressing that it is important that guid be removed on the client.<br />
[13:28:21] &lt;Keybuk&gt; if the IP is saved on a public server, it could be used by other support companies, or competitors<br />
[13:28:30] &lt;mdz&gt; I didn't notice if there was discussion of how this impacts OEM installs<br />
[13:28:44] &lt;mdz&gt; we definitely wouldn't want a UUID getting stored on factory installed systems<br />
[13:29:15] &lt;mdz&gt; Keybuk, is there anything evil that Canonical could do that Canonical can't do by virtue of controlling DNS for archive.*.ubuntu.com already?<br />
[13:30:00] &lt;Keybuk&gt; mdz: no, likewise Canonical already collects the IPs of booting Ubuntu machines, and could use that information for the same purposes<br />
[13:30:07] &lt;Keybuk&gt; I'm just answering the question from a perception POV<br />
[13:30:43] &lt;mdz&gt; there are surely already places where Ubuntu systems generate random numbers and send them over the network<br />
[13:30:48] &lt;mdz&gt; like TLS connections<br />
[13:31:34] &lt;mdz&gt; has anyone considered whether this could be done without generating a UUID?<br />
[13:31:36] &lt;mdz&gt; it seems like it could<br />
[13:31:38] &lt;kees&gt; the ephemeral keys in TLS aren't saved by the server usually<br />
[13:32:11] &lt;kees&gt; but they're connection-based, so they don't survive the install.<br />
<a name='10'></a>
[13:32:31] &lt;mdz&gt; http://installreport.ubuntu.com/start followed by http://installreport.ubuntu.com/finish, divide finishes by starts?<br />
[13:32:45] &lt;mdz&gt; MootBot, you are too clever for your own good<br />
[13:33:14] &lt;ScottK&gt; I was one of the objectors to this.  I don't think we should be collecting data from users that's not needed for system operation without opt-in.<br />
[13:33:15] &lt;kees&gt; mdz: right.<br />
[13:33:46] &lt;ScottK&gt; I'm also on a very laggy connection, so if it seems like I'm running behind, that may be why.<br />
[13:33:57] &lt;mdz&gt; ScottK, do you want a copy of the meeting log up to this point?<br />
[13:34:04] &lt;ScottK&gt; mdz: I have it.<br />
[13:34:18] &lt;Keybuk&gt; ScottK: I do agree with mdz that the usefulness of this data is only interesting if it's implicit<br />
[13:34:49] &lt;kees&gt; since ev is not here, perhaps continue this on the TB list?<br />
[13:34:51] &lt;ScottK&gt; Keybuk: I agree that opt-in compromises the utility, but I think without opt-in it's not appropriate.<br />
[13:35:22] &lt;mdz&gt; ScottK, what is the data that you don't feel should be collected in this case?<br />
[13:35:32] &lt;ScottK&gt; Also I think the opt-out mechanism he proposed was sufficiently convoluted that it's equivalent to not having one.<br />
[13:35:59] &lt;ScottK&gt; mdz: I don't think it's appropriate to engage in any user data collection without consent.<br />
[13:36:23] &lt;mdz&gt; ScottK, I understand, but that isn't what I asked<br />
[13:36:26] &lt;ScottK&gt; There are some things that one could inherently collect like how many people hit security.ubuntu.com for updates, but that's needed to make the system work.<br />
[13:36:56] &lt;mdz&gt; ScottK, what data would be collected from users if we went ahead with this proposal?<br />
[13:36:59] &lt;ScottK&gt; mdz: I'm objecting to the entire thing being opt-out.<br />
[13:38:39] &lt;kees&gt; ScottK: do you see having a system hit "http://installreport.ubuntu.com/start" and .../finish as a problem?<br />
[13:39:59] &lt;mdz&gt; I think ScottK is lagging as he warned he might<br />
[13:40:02] &lt;ScottK&gt; I think that's less of a concern since there's not really any information being transmitted beyond hitting the server.  I'd need to think about it.<br />
[13:40:29] &lt;mdz&gt; it's not strictly necessary to make the system work, but I think I would argue that there is (indirect) benefit to the user<br />
[13:40:40] &lt;mdz&gt; if the data is used to improve the quality of the installer<br />
[13:40:41] &lt;ScottK&gt; It's a slippery slope.<br />
[13:40:48] &lt;mdz&gt; ScottK, yes it is<br />
[13:40:56] &lt;mdz&gt; so we're treading cautiously<br />
[13:41:29] &lt;ScottK&gt; I feel like needed to make the system work versus data we'd like to have is a bright line.<br />
[13:41:30] &lt;mdz&gt; unless someone convinces me otherwise, I think that the use of a UUID is not essential to the objective, and so I don't think we need to be concerned about potentially identifying information<br />
[13:41:46] &lt;ScottK&gt; Once you cross it, how to you define the limit?<br />
[13:42:14] &lt;mdz&gt; I think we can distill it to the point where the only information being shared is whether Ubuntu was installed successfully or not<br />
[13:42:16] &lt;kees&gt; hm... do-release-upgrade fetching installer-specific things when it runs, does ubiquity do anything like that on install? maybe we're already hitting a url.<br />
[13:42:30] &lt;mdz&gt; kees, yes<br />
[13:42:33] &lt;mdz&gt; I'm pretty sure<br />
[13:43:34] &lt;kees&gt; so then we're half way there. we just need an on-first-boot url. that's less obvious to me, though.<br />
[13:43:38] &lt;mdz&gt; ScottK, I think we can set limits which make sense<br />
[13:43:51] &lt;kees&gt; ScottK: agreed -- I think having a direct operational benefit is the key.<br />
[13:43:54] &lt;mdz&gt; kees, not quite. I think we need to store some state, and only hit the "finish" URL if we successfully hit the "start" one<br />
[13:44:02] &lt;ScottK&gt; mdz: OK.  I'd like to see the policy for the limit made first.<br />
[13:44:15] &lt;mdz&gt; fair enough. let's try to steer away from the technical implementation<br />
[13:44:31] &lt;mdz&gt; I'm comfortable assuming that we can get to a point where virtually no incidental information is shared, other than what we're trying to collect<br />
[13:45:00] &lt;kees&gt; I would agree. if there is a reason why guid would be required, that should be a separate issue.<br />
[13:45:07] &lt;mdz&gt; so the question is: is it OK to report back whether the installation succeeded or failed?<br />
[13:45:32] &lt;ScottK&gt; I think taking a step back from this use case, I think having a general policy in place is important.<br />
[13:45:38] &lt;maco&gt; mdz: how do you report failed?<br />
[13:45:42] &lt;ScottK&gt; Why is this OK, but not popcon by default?<br />
[13:45:44] &lt;mdz&gt; possible answers include: yes (unconditionally), no (unconditionally), yes (but only opt-in), yes (but only with opt-out)<br />
[13:45:50] &lt;mdz&gt; maco, it's implicit<br />
[13:46:08] &lt;maco&gt; mdz: what's the difference between failed and cancelled?<br />
[13:46:39] &lt;mdz&gt; maco, we're taking it as a given that this is possible, and we can have a separate technical discussion about how to do it<br />
[13:47:06] &lt;kees&gt; in general, I disagree with opt-out.<br />
[13:47:23] &lt;mdz&gt; ScottK, popcon is problematic for a few reasons, not least because there is a lot of identifying information there<br />
[13:47:47] &lt;kees&gt; opt-in is UI-noisy and doesn't give ev what he's really after<br />
[13:47:48] &lt;ScottK&gt; mdz: I agree, but I think someone needs to define the limit of what's OK for opt-out.<br />
[13:47:51] &lt;mdz&gt; ScottK, but to play devil's advocate, our default web browser shares similar information without the user's consent<br />
[13:48:10] &lt;mdz&gt; or rather, with their implicit consent, depending on how you look at it<br />
[13:48:25] &lt;mdz&gt; kees, I agree that it's a UI wart, but why doesn't it give evan what he's after?<br />
[13:48:34] &lt;mdz&gt; because not enough people would click the button?<br />
[13:48:36] &lt;ScottK&gt; mdz: I would argue that doing so it a bad thing and the best that can be said about it is it represents a compromise that we have to live with.<br />
[13:48:41] &lt;kees&gt; I would support "yes" if I could see an immediate benefit to the user. I still don't see one beyond the weak "maybe we have improved the installer" thing.<br />
[13:49:02] &lt;kees&gt; mdz: because the numbers would then have an additional variable of "who clicked it"<br />
[13:49:10] &lt;mdz&gt; ScottK, I don't think we have to live with it, but we do, and our users don't seem to mind<br />
[13:49:31] &lt;ScottK&gt; How many of our users really know?<br />
[13:49:31] &lt;mdz&gt; kees, unless that correlates somehow with success or failure of the installation, it doesn't seem relevant<br />
[13:49:35] &lt;Keybuk&gt; mdz: they're probably completely unaware of it<br />
[13:49:54] &lt;mdz&gt; Keybuk, exactly<br />
[13:50:00] &lt;Keybuk&gt; the key there is whether the information is sufficiently non-identifying that they never *need* to be aware of it<br />
[13:50:18] &lt;mdz&gt; Keybuk, I think a good test is whether, if they *did* know, they would mind<br />
[13:50:18] &lt;Keybuk&gt; ie. if Firefox collected everyone's browsing histories and published them<br />
[13:50:23] &lt;Keybuk&gt; it's something you would want to be aware of<br />
[13:50:28] &lt;mdz&gt; and I don't know the answer to that, honestly<br />
[13:50:30] &lt;mdz&gt; but it's testable<br />
[13:50:30] &lt;ScottK&gt; The existence of branded Firefox packages given the constraints on them is making the (arguable) best of a difficult situation.<br />
[13:50:38] &lt;Keybuk&gt; but Firefox collecting histograms about the average time a DNS lookup takes -> only Firefox cares<br />
[13:50:59] &lt;mdz&gt; Keybuk, what about sharing which extensions you have installed, and which versions?<br />
[13:51:04] &lt;Keybuk&gt; (and any Firefox developer, and anyone doing DNS work, and anyone optimising web sites, etc.)<br />
[13:51:08] &lt;Keybuk&gt; but fundamentally not the user<br />
[13:51:20] &lt;mdz&gt; sharing which web pages you're visiting in order to check for phishing attempts?<br />
[13:52:03] &lt;ScottK&gt; mdz: I would think that would most appropriately be opt-in.<br />
[13:52:04] &lt;mdz&gt; ScottK, I'm not sure it's realistic to come up with a general policy at this point, given there are so many subtleties to this topic<br />
[13:52:08] &lt;Keybuk&gt; sharing everything you type into the awesomebar to third parties? :p<br />
[13:52:16] &lt;mdz&gt; it hasn't come up enough times that it's problematic to handle on a case by case basis<br />
[13:52:34] &lt;mdz&gt; Keybuk, sharing things you START to type into the box, in Chrome's case :-)<br />
[13:52:36] &lt;ScottK&gt; mdz: Perhaps, but I think we need a line in the sand beyone which the TB won't go.<br />
[13:52:57] &lt;Keybuk&gt; mdz: I was just looking at the data we collect, as it happens :D<br />
[13:53:07] &lt;mdz&gt; ScottK, I think we already have such a line drawn at collecting PII, by way of precedent, and I would be comfortable making that explicity<br />
[13:53:33] &lt;mdz&gt; s/ity$/it/<br />
[13:53:50] &lt;ScottK&gt; What's your definition of PII then?<br />
[13:54:22] &lt;mdz&gt; I'm not sure of the best way to specify that. number of bits?<br />
[13:54:45] &lt;mdz&gt; there is always going to be room for interpretation<br />
[13:55:05] &lt;mdz&gt; and it can be really hard to tell<br />
[13:55:15] &lt;kees&gt; I think PII remains a judgement call, even if we explicitly declare it out of bounds<br />
[13:55:56] &lt;mdz&gt; I agree<br />
[13:56:13] &lt;mdz&gt; I think we have to punt on this for the time being; we aren't going to come to a conclusion in this meeting<br />
[13:56:16] &lt;mdz&gt; but we can try to get to some other topics<br />
[13:56:21] &lt;mdz&gt; we can continue the discussion by email<br />
[13:56:27] * ScottK agrees (re punting)<br />
[13:56:28] &lt;mdz&gt; [topic] Policy proposal for partner repository<br />
<a name='11'></a>
[13:56:35] &lt;mdz&gt; [link] https://lists.ubuntu.com/archives/technical-board/2011-May/000875.html<br />
<a name='12'></a>
[13:57:04] &lt;kees&gt; I was curious how this differed from -extras<br />
[13:57:08] &lt;kees&gt; (policy-wise)<br />
[13:57:23] &lt;mdz&gt; kees, is there a written policy for extras which could be shared with partner?<br />
[13:57:37] &lt;kees&gt; mdz: I couldn't find it when I looked earlier this week<br />
[13:57:52] &lt;kees&gt; I think we should check with allison<br />
[13:58:13] &lt;mdz&gt; I'll CC her into the email discussion for input<br />
[13:58:38] &lt;mdz&gt; my view on this is that we'll never get a policy like this right the first time, and it will need to be updated as time goes on<br />
[13:58:41] &lt;kees&gt; beyond that thought, nothing jumped out at me.<br />
[13:58:44] &lt;mdz&gt; if there is a problem, we'll change the policy to prevent further problems of that kind<br />
[13:58:50] &lt;kees&gt; right<br />
[13:59:20] &lt;kees&gt; I'd also be curious to get archive admin opinions on this, since we may be missing some additional implicit things<br />
[13:59:39] &lt;mdz&gt; it doesn't reference the Debian or Ubuntu policy manual, and it probably should<br />
[14:00:09] &lt;mdz&gt; any other comments ? email<br />
[14:00:11] &lt;mdz&gt; [topic] ubuntu-techboard celebrity in Launchpad<br />
<a name='13'></a>
[14:00:16] &lt;mdz&gt; https://lists.ubuntu.com/archives/technical-board/2011-May/000907.html<br />
[14:00:20] &lt;mdz&gt; [link] https://lists.ubuntu.com/archives/technical-board/2011-May/000907.html<br />
<a name='14'></a>
[14:00:26] &lt;kees&gt; seems like we're not ready to drop this, pending additional bug fixes<br />
[14:00:48] &lt;mdz&gt; if james_w says we can't do this yet, then I say we don't do it yet<br />
[14:00:54] &lt;kees&gt; right<br />
[14:01:05] &lt;mdz&gt; we're out of time<br />
[14:01:08] &lt;mdz&gt; is there anything else urgent?<br />
[14:01:10] &lt;mdz&gt; [topic] AOB<br />
<a name='15'></a>
[14:01:44] &lt;mdz&gt; ok, thanks all<br />
[14:01:45] &lt;mdz&gt; #endmeeting<br />
Meeting ended.<br />