Started logging meeting in #ubuntu-meeting
[09:02:30] <Keybuk> [LINK] Today's Agenda: https://wiki.ubuntu.com/TechnicalBoardAgenda
[09:03:11] <Keybuk> [TOPIC] Action Review
[09:03:33] <Keybuk> I don't see any actions in the TeamReports, and my e-mail is still trickling through so I don't have a last-mailed-out agenda
[09:03:43] <Keybuk> does anyone know of any actions they were supposed to do? :-)
[09:04:34] <mdz> I missed the previous meeting due to travel
[09:04:36] <pitti> we didn't have any last time AFAIR
[09:04:43] <pitti> mdz: there was no real previous meeting
[09:04:48] <Keybuk> ok, no problem
[09:04:50] <mdz> there's nothing on https://wiki.ubuntu.com/TeamReports/August2010#Technical Board
[09:04:56] <cjwatson> pitti: welcome to the first ever meeting of the Ubuntu TB
[09:04:56] <Keybuk> mdz: indeed, as I said
[09:05:03] <pitti> we had two agenda points from Keybuk and mdz, but both of you were offline, so we skipped it
[09:05:05] <Keybuk> [TOPIC] brainstorm.ubuntu.com
[09:05:07] <mdz> there's nothing in https://wiki.ubuntu.com/TeamReports/July2010#Technical Board either :-/
[09:05:09] <Keybuk> mdz: your topic
[09:05:14] <pitti> cjwatson: pah semantics :)
[09:05:28] <mdz> so, this came up in some engineering management discussion recently
[09:05:41] <mdz> and I wanted to discuss it with the TB
[09:06:09] <mdz> basically, the question is how to best utilize brainstorm as a mechanism to communicate with our user community
[09:06:11] <pitti> mdz: July> that got cancelled as well, due to lack of topics and people
[09:07:02] <mdz> my feeling on it is that brainstorm hasn't turned out to be a great way to filter suggestions
[09:07:20] <mdz> however, it has been pretty good at highlighting common concerns
[09:08:19] <mdz> in other words, it can tell us what people are thinking about
[09:08:39] <mdz> as such, I think the right way for the Ubuntu project to use brainstorm is to review the highest-voted items from time to time, and respond to them
[09:08:44] <cjwatson> also, without it we'd get even more flooded with bugs :)
[09:08:51] <mdz> a response might be:
[09:08:54] <cjwatson> I agree, in fact I thought that was what we used to do
[09:09:09] <pitti> at least in some UDS preparations we used to look at it
[09:09:11] <mdz> - an explanation of what we think about that issue, and how we might approach it
[09:09:19] <pitti> but indeed we never paid that much attention to it
[09:09:21] <mdz> - a link to some work in progress in that area, to illustrate what we're doing there
[09:09:33] <mdz> - feedback on why the idea isn't useful/relevant given the current goals of the project
[09:10:04] <mdz> cjwatson, we did that at one time, but it wasn't kept up
[09:10:24] <sabdfl> some official feedback on the top n could be useful, but could also just cause a flashpoint to flash
[09:10:30] <mdz> pitti, we used to look at it during UDS preparations as a source of ideas: i.e., is there anything here we haven't thought of which we should add to the list of features to examine?
[09:10:34] <cjwatson> I don't think we need to commit to reviewing the top n
[09:10:37] <mdz> it turned out not to be very useful for that
[09:10:42] <sabdfl> fwiw, the design team looked at the top 50 in kicking off the 11.04 thinking
[09:10:45] <pitti> mdz: I agree
[09:10:45] <mdz> because the items in it are things like "wireless doesn't work as well as we would like"
[09:10:51] <cjwatson> we can respond to things which are particularly worth responding to
[09:14:15] <mdz> the things in brainstorm are in most cases not "features" at all, not as we would think of them
[09:14:15] <cjwatson> and have informal criteria for that
[09:14:15] <mdz> they're feedback
[09:14:15] <mdz> consolidated, collaboratively filtered feedback
[09:14:15] <mdz> and the right thing to do with feedback is to read it and respond publicly
[09:14:15] <sabdfl> further, responding well to the most useful feedback encourages more like that
[09:14:15] <mdz> sabdfl, they looked at them with what in mind? inspiration?
[09:14:15] <sabdfl> and prioritization
[09:14:15] <mdz> right, so I think I'm coming at this from a different angle, looking at it as a communication facility rather than as a data source
[09:14:15] <mdz> it gives us our best chance at having a dialogue with the user community about things
[09:14:15] <mdz> without being overwhelmed
[09:14:15] <mdz> so first, do we agree that that is a useful way to position brainstorm?
[09:14:15] <mdz> not as a wishlist, or a way to get features implemented, but a way to have a structured conversation with our users about what's important to them
[09:14:36] <pitti> that makes it very close to a bug tracker with voting facility
[09:14:47] <pitti> but we don't require very precise information there
[09:14:51] <mdz> pitti, in functionality, yes, but we don't get bugs that say "wifi doesn't work" :-)
[09:14:52] <cjwatson> most of the things in brainstorm are too vague to be bugs
[09:14:53] <Keybuk> right, that'd be what I'd ask in return
[09:14:57] <pitti> so I concur with your perspective
[09:15:04] <Keybuk> how does this fit in with the existing bug tracker, spec tracker and the new stack exchange?
[09:15:31] <mdz> the bug tracker is a tool for developers and testers to track technical defects in Ubuntu
[09:15:35] <pitti> mdz: right, it keeps that kind of fuzzy information out of the bug tracker (or, rather, we get a little less of those)
[09:15:48] <mdz> the spec tracker is a project management tool to keep track of what we're working on
[09:16:02] <pitti> so, it's indeed a nice way to get a filtered view what area causes most problems
[09:16:16] <pitti> (not that it would be very surprising in most cases, though)
[09:16:16] <mdz> stack exchange is Q&A among anyone who is interested in Ubuntu, and is fairly new so we'll see how it ends up fitting in
[09:16:27] <mdz> brainstorm, I propose, should be a gateway between the people who make Ubuntu, and the people who use Ubuntu
[09:16:39] <mdz> Keybuk, make sense?
[09:16:51] <Keybuk> that's a good answer
[09:17:05] <Keybuk> how would the people who make Ubuntu (us) use brainstorm?
[09:17:20] <mdz> so that's the next question
[09:17:47] <mdz> my proposal is that, on a periodic basis, some grouping of the top voted items in brainstorm gets an official response from the project
[09:17:50] <Keybuk> I guess a better question, which teams become responsible for reading every single thing posted to brainstorm?
[09:17:58] <mdz> nobody is responsible for reading every single thing
[09:18:14] <pitti> it just tends to aggregate votes in a rather useless way -- if some people say "my wifi isn't working", others +1 that, but it doesn't tell us much
[09:18:19] <Keybuk> I'm a bit worried that that kind of approach turns into "Petition the Prime Minister"
[09:18:24] <mdz> but, say, once a quarter or so, a few people spend a few hours going through the *highest voted* items and responding to those
[09:18:40] <Keybuk> where the community rally to get something on brainstorm voted highly, and we respond telling them that it's not a problem, etc.
[09:18:52] <mdz> pitti, it tells us that our users care about wifi, and that they might appreciate us telling them what's going on
[09:18:53] <cjwatson> there are bound to be some we can't respond to in any particularly useful way; IME in the past that has been the case for some of them but by no means all
[09:19:12] <cjwatson> indeed I've often got to say "yes, we think this is a good idea, and furthermore we did it three months ago", which is rather satisfying
[09:19:29] <pitti> so, we could just try that "respond to the top items where appropriate" and see how it goes
[09:19:29] <mdz> cjwatson, yes, there are probably some which fall into that category, and I don't think we should waste time on them if they're noise
[09:19:51] <mdz> I think it's OK to respond to say "I can't make sense of this" if it's noise
[09:20:12] <mdz> Keybuk, I think the quality of our responses will count for a lot
[09:20:16] <Keybuk> *nods* sounds reasonable
[09:20:22] <mdz> which is why I think it's OK to limit it to a fairly small number
[09:20:25] <mdz> but do a good job of responding
[09:20:52] <Keybuk> if we pick the ones we can write the best responses to, we'll get more top suggestions of that kind
[09:20:57] <cjwatson> right, there really is no point to the site if nobody looks at it in a semi-organised way, and I think the site is a useful lightning rod, so ... yes
[09:20:58] <Keybuk> (people will get the idea of what kind of thing gets responses)
[09:21:18] <mdz> taking the wifi example, I think it would be great to have a blog post from somebody very knowledgeable in that area explaining the current state of wifi, why it is the way it is, how we'd like it to be, how it has changed recently, what we're working on to make it better, etc.
[09:22:12] <mdz> and would hope to strike a balance between the amount of time we invest in it, and the perceived benefit to the user community
[09:23:03] <mdz> I think a couple of hours per response, spread out across the team to the people best equipped to respond, every 3 months, shouldn't be too much of a burden
[09:23:14] <mdz> and could be much appreciated
[09:23:27] <pitti> so this could become a routine part of the "prepare UDS" or "prepare specs" part of the cycle, to be done by the team/tech leads
[09:23:31] <Keybuk> I think there's a consensus here that that would be a good thing; do you want to take an action to make it a formal proposal?
[09:23:32] <sabdfl> glitch
[09:23:46] <pitti> with "done" -> review and fan out to the experts
[09:23:50] <mdz> sounds like consensus, great
[09:23:59] <mdz> so at this point in my own thinking, the question became: whose responsibility should this be?
[09:24:05] <mdz> and I thought it appropriate to start with the TB
[09:24:21] <mdz> I think this should definitely be an Ubuntu voice rather than a Canonical voice
[09:24:22] <Keybuk> I was going to suggest the Community team
[09:24:32] <cjwatson> I think it should be a technical task as well
[09:25:18] <cjwatson> perhaps the TB with guidance from the community team on particularly urgent items
[09:25:23] <mdz> I'm not too fussed; I think there are plenty of people and teams who could do a good job at coordinating the process
[09:25:25] <cjwatson> and we can fan things out to individuals as needed
[09:25:29] <Keybuk> I would be worried that the overly technically minded of us would not be good at identifying the hot topics of our users
[09:25:47] <cjwatson> that's why they're voted on by users :-)
[09:25:48] <mdz> the important thing to me is to get consensus that this is useful and worth investing in
[09:25:48] <pitti> that's why I suggested doing it around UDS -- that's when managers and TLs are in the mood for design and writing tech stuff anyway
[09:26:04] <mdz> pitti, so do you suggest a 6 month cadence rather than 3 months?
[09:26:08] <mdz> I thought that might be a bit long
[09:26:16] <pitti> mdz: 3 months works for me as well
[09:26:31] <pitti> mdz: just trying to fit it into existing rhythms
[09:26:43] <dholbach> I think it'd make sense for all teams to have a look at it in their respective areas :)
[09:26:44] <mdz> pitti, yes, I like that idea as well
[09:26:52] <pitti> and around feature freeze there's usually not a lot we can/want to do about changing things
[09:26:59] <sabdfl> does it change that fast?
[09:27:03] <mdz> dholbach, I don't think that brainstorm can be neatly divided up that way, unfortunately
[09:27:08] <cjwatson> dholbach: I think a lot of things would fall through the cracks that way
[09:27:18] <cjwatson> cf. "that's a kernel problem" "no it's not, it's a foundations problem"
[09:27:21] <cjwatson> ad nauseam
[09:27:29] <mdz> pitti, I think it's more about what we say than what we do
[09:27:30] <cjwatson> you need a coordinating group or lots of things will just be ignored
[09:27:47] <dholbach> sure, I just think we'll get better results if more than just the community team has a look at it :)
[09:27:57] <cjwatson> I agree that it should not be just the community team
[09:28:11] <pitti> dholbach: I agree; at best, teh community team could ask some expert to respond to a particular question
[09:28:16] <mdz> dholbach, I don't think the tech board can delegate work to the Canonical community team anyway ;-)
[09:28:37] <mdz> to be perfectly honest we tried that and it didn't work all that well
[09:29:18] <mdz> jono tried to route brainstorm items to people, get responses and publish them, and it was a pain
[09:29:23] <mdz> I'd like to try to keep it simple
[09:29:29] <cjwatson> personally, I think that this fits well into the TB's remit of providing technical direction and guidance
[09:29:33] <mdz> cjwatson, exactly
[09:29:35] <cjwatson> even if we don't personally write all the responses
[09:29:48] <mdz> I think in practice, members of the TB are great candidates for writing responses
[09:29:58] <mdz> and where we aren't, we know who to go to
[09:30:21] <mdz> so I wondered if this should be a TB responsibility
[09:30:55] <Keybuk> it seems there's also a consensus that the TB can be responsible for this
[09:31:24] <pitti> *nod*
[09:31:36] <mdz> great
[09:31:48] <Keybuk> [ACTION] mdz to draft plan/process for brainstorm
[09:31:55] <mdz> thanks for the feedback
[09:32:10] <mdz> why yes, I would be happy to take an action to draft a proposal
[09:32:18] <mdz> no problem Keybuk ;-)
[09:32:39] <Keybuk> :-)
[09:32:42] <mdz> next topic?
[09:32:51] <Keybuk> [TOPIC] Check accuracy of voting procedure on TechnicalBoard wiki page
[09:32:57] <Keybuk> mdz: stop back-seat chairing
[09:32:57] <cjwatson> ok, that was mine
[09:33:00] <Keybuk> cjwatson: you're up
[09:33:20] <cjwatson> this came from a brief conversation I had with Raphaël Hertzog where he was trying to establish how the TB was appointed/elected
[09:33:58] <mdz> interesting, where did this come from?
[09:34:24] <mdz> I'm looking at the part where it describes how the board operates
[09:34:29] <cjwatson> mdz: it turned into that LWN article he wrote, I think, although most of this is not really relevant to that
[09:34:30] <Keybuk> it sounds like it came from the LWN response of Jef Spaleta to Raphael's article?
[09:34:32] <cjwatson> pitti told him that Mark appointed candidates and that the vote was only a "confirmation vote", which is roughly what it says on the wiki
[09:34:40] <cjwatson> Keybuk: it was before the article was published, so no
[09:34:50] <dholbach> https://wiki.ubuntu.com/CommunityCouncil/Restaffing has some bits about it too
[09:34:55] <cjwatson> let me finish?
[09:35:09] <cjwatson> before realising that pitti's comments came from the wiki, I said 'the last one was a vote among several possible candidates, though, so I'm not sure "confirmation vote" is a good way to think about it'
[09:35:19] <cjwatson> so now I wonder whether we ought to clarify the wiki a little bit
[09:35:25] <cjwatson> https://wiki.ubuntu.com/TechnicalBoard, specifically
[09:35:37] <cjwatson> "Appointments to the board are made by Mark Shuttleworth subject to confirmation by a vote amongst Ubuntu developers."
[09:35:54] <Keybuk> has that formally changed?
[09:36:09] <cjwatson> to me a confirmation vote is an up/down vote for a single person, which is not what the last one was
[09:36:15] <mdz> there's also http://www.ubuntu.com/project/about-ubuntu/governance
[09:36:50] <mdz> that page says that sabdfl nominates candidates
[09:36:54] <mdz> and the candidates are then voted upon
[09:36:58] <cjwatson> the text on http://www.ubuntu.com/project/about-ubuntu/governance is much better
[09:37:05] <cjwatson> "In each case, a poll of relevant members of the project is conducted to select, or veto, the final membership of the Community Council and Technical Board."
[09:37:05] <mdz> I think it's also...well, accurate
[09:37:13] <cjwatson> that doesn't tie us down to a particular voting strategy
[09:37:43] <sabdfl> i think i commented on the LWN article, too
[09:38:14] <cjwatson> I didn't really want to drag the whole LWN article into it; it got into rather a lot more detail and from my POV my conversation with buxy was essentially independent of it
[09:38:20] <sabdfl> showing how the same approach applies to broader governance structures - it's top down delegation, with bottom up tests of confidence
[09:38:23] <mdz> I haven't read the LWN article
[09:38:27] <mdz> I'm about 3 issues behind
[09:38:45] <cjwatson> I really just wanted to check whether we could revise the text on TechnicalBoard to avoid (appearing to) conflict with current electoral practice
[09:39:05] <mdz> I think revising the wiki page to match the (authoritative) text on the website is fine
[09:39:14] <cjwatson> ok, I'll take an action to do that then
[09:39:17] <mdz> I think there are other things on that wiki page which are misleading or wrong as well
[09:39:20] <cjwatson> if there are no objections
[09:39:29] <Keybuk> none from me
[09:39:37] <mdz> it also has far too many Capitalized Phrases
[09:39:43] <mdz> we're just not that formal around here
[09:39:44] <Keybuk> [ACTION] cjwatson to review and defraft TB wiki pages to match current governance practice
[09:40:03] <mdz> cjwatson, would you mind fixing up the rest of the page a bit while you're in there?
[09:40:09] * cjwatson nods at Matt Zimmerman, Board Member
[09:40:20] * mdz chuckles
[09:40:31] <Keybuk> [TOPIC] Fate of ia64/sparc in Maverick
[09:40:34] <cjwatson> or perhaps I should salute, given that tone
[09:40:39] <cjwatson> right :)
[09:40:43] <mdz> this is done, I read about it in LWN
[09:40:47] <Keybuk> we've announced and agreed to drop these ports, but I've been unable to find any documentation or buttons for actually doing it
[09:40:52] <cjwatson> mdz: I thought you were behind
[09:40:57] <mdz> cjwatson, just now
[09:40:59] <Keybuk> cjwatson: do you remember when we dropped lpia what we did?
[09:41:03] <mdz> it's still on the front page
[09:41:06] <cjwatson> we made lamont do it
[09:41:17] <Keybuk> haha, right
[09:41:27] <Keybuk> so this is "invoke IS/duckie" ?
[09:41:30] <cjwatson> I suggest getting him to write it up this time :)
[09:41:37] <cjwatson> it involved some rather terrifying Launchpad operations
[09:41:46] <Keybuk> I thought that might be the case
[09:41:49] <Keybuk> I'll continue to action that
[09:41:55] <Keybuk> [ACTION] Keybuk to invoke lamont for ia64/sparc drop
[09:42:13] <cjwatson> I turned off CD image building for those architectures already, in anticipation
[09:42:15] <Keybuk> [TOPIC] Mailing list archive
[09:42:25] <Keybuk> is there anything on there that needs an action?
[09:42:31] <mdz> it's still awfully spammy
[09:42:52] <mdz> didn't somebody take an action to ask IS for help with that?
[09:43:03] <mdz> there's https://lists.ubuntu.com/archives/technical-board/2010-August/000426.html
[09:43:06] <Keybuk> mdz: if someone solves that particular problem, they would stop working for us due to being a billionaire
[09:43:09] <mdz> (bdmurray's drivers proposal)
[09:43:31] <cjwatson> we need to agree on the chromium-browser stuff, but I doubt we can do that in 17 minutes
[09:43:52] <mdz> i.e.https://lists.ubuntu.com/archives/technical-board/2010-August/000459.html
[09:44:09] <mdz> I haven't read the rest of the thread yet
[09:44:23] <mdz> cjwatson, we could make a start on it
[09:44:49] <cjwatson> I don't quite understand what's going on with the spam; the list is moderated and I'm certainly not approving all that stuff
[09:45:09] <cjwatson> oh, hm, generic_nonmember_action is set to Accept
[09:45:26] <sabdfl> Keybuk: why would that stop someone working for us?
[09:45:31] <cjwatson> I've changed that to Hold, will just mean a bit more manual moderation
[09:45:32] <mdz> given chromium is a) in universe, and b) fairly immature upstream (on Linux), I'm inclined to be flexible
[09:45:34] <cjwatson> maybe that will help
[09:45:36] <mdz> until one or both of those things change
[09:45:37] <pitti> cjwatson: ah, thanks
[09:46:00] <pitti> cjwatson: but there's usually tons of spam in the moderation queue as well; I wonder why only some is caught
[09:46:12] <mdz> once my pinned tabs become visible again, for example
[09:46:18] <pitti> mdz: I thought the request was to move it to main
[09:46:27] <cjwatson> do not meddle in the affairs of mailman, for you are tasty and good with custard
[09:46:31] <cjwatson> ... I don't know
[09:46:37] <pitti> (which I'm not at all happy about, FWIW -- chromium is a steaming pile of bugs still :-/
[09:46:39] <mdz> pitti, oh, I see
[09:46:48] <mdz> I think that's a bigger question than how to do security updates
[09:46:56] <mdz> I'm not sure chromium is ready
[09:47:34] <mdz> has the archive team taken a view?
[09:47:58] <pitti> the main problem is that it's (non-)release strategy is fundamantally incompatible with distros
[09:48:29] <mdz> pitti, well, it's incompatible with distros who don't have the same rolling release model
[09:48:42] <pitti> mdz: which is "all but Debian testing?"
[09:48:53] <pitti> well, and gentoo
[09:48:56] <mdz> there are several
[09:48:56] <cjwatson> or Arch
[09:49:07] <mdz> or Chrome OS
[09:49:22] <Keybuk> Fedora
[09:49:32] <pitti> they do 6-monthly releases?
[09:49:42] <Keybuk> they update after release
[09:49:46] <Keybuk> a release is not a static blessed thing
[09:49:51] <pitti> but even 6 months is too long for chromium
[09:51:25] <mdz> the problem at hand seems to be that it takes too long for security updates to reach chromium users
[09:51:49] <mdz> when they use the Ubuntu packaged version anyway
[09:52:27] <mdz> our usual solution to that is backporting them
[09:52:38] <mdz> has that been evaluated with chromium?
[09:53:55] <pitti> mdz: not sure, but given that the code changes a magnitude faster than firefox, I think it's even less practical to do there
[09:54:42] <mdz> it seems worth doing an analysis of actual security fixes and backporting feasibility
[09:55:00] <mdz> what other options do we have other than backporting and ship-bleeding-edge-everywhere?
[09:55:09] <pitti> ship an installer package, like flash
[09:55:14] <pitti> and then use the builtin update
[09:55:20] * mdz gets the feeling that some fellow Board Members are reading their email ;-)
[09:55:21] <sabdfl> do they flag the security fixes particularly? seems that if their view is "everything rolls" they'd be less inclined to do that
[09:55:36] <pitti> sabdfl: there are CVEs for that
[09:56:11] <mdz> they treat security bugs differently, use CVEs, etc.
[09:56:18] * kees gets onto after-security-check airport wifi for the last 5 minutes, whee.
[09:56:44] <kees> they roll bug fixes in with security updates, though.
[09:56:45] <pitti> or, rather, they seem to mark their bugs accordingly
[09:56:54] <pitti> https://edge.launchpad.net/ubuntu/+source/chromium-browser/5.0.375.127~r55887-0ubuntu1
[09:57:07] <mdz> http://www.chromium.org/Home/chromium-security
[09:57:13] <mdz> explains their policies and procedures
[09:58:18] <mdz> Keybuk, time?
[09:58:44] <Keybuk> I think so
[09:58:57] <Keybuk> who should take the action to further review chromium?
[09:58:58] <Keybuk> pitti: ?
[09:59:12] <pitti> Keybuk: I think I gave plenty of feedback in the thread already
[09:59:24] <pitti> I can do some investigations about backporting fixes
[09:59:37] <mdz> delegate to the security team?
[09:59:57] <Keybuk> sure, who gives them the bad news? :p
[10:00:05] <kees> what is the "question" about it?
[10:00:12] <mdz> kees, https://lists.ubuntu.com/archives/technical-board/2010-August/000459.html
[10:00:29] <pitti> kees: whether it's feasible to backport chromium security patches to older releases
[10:00:40] <mdz> pitti, I meant delegate the whole issue
[10:00:41] <kees> we do it already for firefox; it's up to the desktop team.
[10:00:46] <pitti> I just think that even if we do that, people wouldn't be satisfied, though
[10:00:56] <mdz> I'm not sure why the TB should be the ones to decide on such a specialist issue
[10:00:58] <kees> there is no choice about doing it; there is no sensible way to do per-fix backporting of patches
[10:01:02] <pitti> chromium is way too buggy still to ship older releases in something like an LTS
[10:01:08] <chrisccoulson> it won't be feasible to backport security fixes to a stable release
[10:01:13] <kees> sorry "do it" meaning "take full version updates"
[10:01:16] <pitti> ah, there are the experts :)
[10:01:20] <chrisccoulson> that would be a crazy amount of work
[10:01:22] <jdstrand> we don't backport firefox, we do microversion updates
[10:01:32] <mdz> I'm joining a conf call now, goodbye
[10:01:37] <jdstrand> kees: ah, yes, right :)
[10:01:39] <cjwatson> I have to go as well
[10:01:48] <pitti> continue on the list then?
[10:01:53] <kees> okay
[10:02:03] * chrisccoulson goes to read scrollback
[10:02:04] <pitti> I'll ask Chris/Kees to reply there
[10:02:24] <Keybuk> great
[10:02:30] <Keybuk> [ACTION] pitti to follow up with kees on-list
[10:02:38] <Keybuk> [TOPIC] Community bugs
[10:02:43] <Keybuk> the only open bug is the drivers one of mdz
[10:02:53] <Keybuk> bdmurray has a recent follow up, we should make sure that ends up on the bug
[10:03:04] <Keybuk> bdmurray: could you forward it to bug #174375 ?
[10:03:06] <ubottu> Launchpad bug 174375 in Launchpad Registry "Distribution drivers permissions may need redesign" [Low,Triaged] https://launchpad.net/bugs/174375
[10:03:19] <Keybuk> [ACTION] Chair for next meeting
[10:03:26] <Keybuk> I believe it's mdz next alphabetically ;-)
[10:03:56] <mdz> ok
[10:04:01] <Keybuk> [AGREED] mdz to chair
[10:04:03] <Keybuk> #endmeeting
Meeting ended.