=== jjohansen is now known as jj-afk === noy_ is now known as noy === rsalveti` is now known as rsalveti === astralja1a is now known as astraljava === jj-afk is now known as jjohansen === czajkows1i is now known as czajkowski [12:02] hello all [12:03] Afternoon [12:03] https://wiki.ubuntu.com/CommunityCouncilAgenda/ has one item as far as I can see, highvolt1ge around? [12:04] dholbach: are we gathering today? [12:04] sabdfl, we are, sorry - it slipped my mind [12:04] let me try to round up the others [12:07] I pinged everyone - I'd say let's get started - they can read backlog if necessary [12:08] dholbach: the only item I can see is: [12:08] sabdfl veto process [12:08] highvolt1ge is in .ca now, so he might be better suited by one of the 21UTC meetings [12:09] the only other thing I'd like to bring up is: a reminder about https://lists.launchpad.net/ubuntu-council-teams/msg00008.html (oneiric restaffing) [12:09] which is really about separating fact from fiction as to whether there is a firm view expressed by me on a particular issue [12:09] and documenting that view, and discussion around it [12:09] https://wiki.ubuntu.com/CommunityCouncilAgenda/talk [12:09] * dholbach reads up [12:10] i'm entirely open to the idea of keeping track of such decisions publicly, both for transparency and also to avoid some of the misuse of "Mark said..." that occasionally takes place [12:10] sometimes i hear about surprising decisions i apparently took from other people who have a friend that told them... ;-) [12:10] i don't think it's just me, though [12:10] haha :) [12:11] i think it would be useful if team leads and others could express a definitive view and record that in LP [12:11] so, for example, if it's a Foundations issue, then the comment of Colin or Steve L could be recorded as the "definitive project view" till further notice [12:12] Does it need to be LP? Would the wiki work as well? It has attribution as part of the info pages for anything written. [12:12] i often see a bug with a firm view from someone I would consider authoritative, be it cjwatson or mpt or mdke or someone else, but that is just one comment among many and newcomers may not realise it's the binding opinion [12:13] persia: for big heavy things the wiki would be fine, but a lot of this sort of decision making happens in the bug tracker [12:13] Makes sense. [12:13] I'm just not sure in which cases this needs to be "tagged" or "marked" as "definitive project view" [12:13] i.e. "the official reason we are moving to grub2 and will not support XYZ is..." [12:13] sabdfl, mdke, mpt, cjwatson and others make decisions 500 times a day and in 99.9% of cases it's fairly uncontroversial :) [12:14] i agree - this is just for the cases where it *is* controversial and debate will continue, so you want to say to someone new to the bug "btw, this is the person who made this call, and here's their rationale" [12:14] it's never going to *stop* commentary on controversial bugs [12:14] I often find myself saying "but this is just my personal opinion" or something, although it's pretty clunky [12:15] I think it's different when someone makes a decision in day-to-day activity, as opposed to taking a decision to end a controversial discussion. [12:15] but it would make for improved clarity on the decision maker and rationale [12:15] hey cjwatson, didn't mean to draw you into the discussion :-) but glad for your feedback [12:16] heh, that's OK, I have long-running tests in progress [12:16] i think in most cases we are pretty good at knowing, inside the project, who a natural decision-maker is [12:16] sorry I'm late [12:16] definitive project views are often usefully expressed by editing the bug description, I find, although a lot of people forget about that [12:16] but for someone who stumbles into an issue and joins the discussion, that's not clear at all [12:16] if the bug description can be "locked", I think it'd make sense to record the "definitive project view" in there, otherwise maybe on the wiki [12:17] I'm not sure I've ever actually seen a description edit war; I agree it's a theoretical possibility but I wonder if we need to be concerned about it [12:17] one advantage of flagging it on a comment (especially if the flag can be added later by someone else) is that different projects can hold different definitive views [12:17] i.e. this is why nautilus wants spatial, this is why XXX wants something different [12:17] the Debian BTS added a feature a while back where you could note a particular comment index as a summary of the bug [12:17] but that would be unusual [12:17] to some extent this is a workaround for not having an editable description, but it might be an interesting approach here too [12:19] a related issue on transparency might be clearer documentation of the project structure; for example, desktop and server team leadership [12:19] so even if there is no expressed view, it's clearer where one might find it [12:20] hmm [12:21] There is a (perceived) difference between the hundreds of decisions mpt / mdke / cjwatson make a day and the ones sabdfl makes. I suspect people feel that anyone other than sabdfl can be argued with. Whereas sabdfl cannot. [12:21] there was something about this on the platform wishlist for LP ages ago [12:21] I've certainly seen people voice this in a roundabout way in the past [12:21] I think an idea was to have certain project/team emblems show up alongside commenters [12:22] (There is a greasemoneky plugin that does this.) [12:22] cjwatson: that, and perhaps to promote those comments to being visible right after the description [12:22] I don't know whether it's an approachability thing or whether people feel that it's because you're the project owner/sponsor. [12:23] I believe bug 81692 was the bug of record on this [12:23] Launchpad bug 81692 in Launchpad itself "Display team emblem on bugs from project contributors" [Low,Triaged] https://launchpad.net/bugs/81692 [12:23] popey: understandable. i think it's reasonable to expect any agenda/view/constraint to be documented though, and am happy to do that. [12:24] Documenting a position is one thing, being (perceived to be) open to discussion is another of course. [12:25] i think there are two separate issues in that bug report from mdz [12:25] one is just showing affiliation for every commenter, where that can be determined and is relevant [12:25] so telling the difference between a commenter who has ANY official role in Ubuntu and one who does not [12:26] I'm reminded of the GNOME Bugzilla thing where it says (developer) or (translator) or whatever it is next to people's names; simple but effective [12:26] the other, is identifying a specific comment as a "definitive project statement" by an authoritative person [12:26] but yeah, doesn't really address what popey is saying [12:28] how much of this really needs a technical solution? should we just be more careful about how we phrase things when we might come off as authoritative? [12:28] i can live with the controversy ;-) [12:28] (For info, the greasemoneky script adds: http://bootie.daviey.com/~dave/lpfoo.png Karama and teams) [12:28] maybe just 1) update description, 2) tag the bug for documenting the decision and 3) mark as "opinion"? :) [12:28] for someone who wants to debate, a decision is a pain. for everyone else, it's a relief. [12:29] karama! need more of that. sounds like fun :-) [12:29] i blame oneiric :) [12:29] the people who can mark an Ubuntu bug as "opinion" should know the decision makers in the project [12:30] and generally they do [12:30] ok. highvoltage wanted some record of specific decisions or guidance from me, primarily in cases where that's being quoted by third parties [12:30] i'm happy to run with a space on the wiki where folk can ask for such things to be documented officially [12:31] i am not going to start cc'ing everything i think to that space [12:31] but am happy to document positions there, and changes to them, on request [12:31] "can i have that in writing, please" ;-) [12:32] in addition, i think we can ask the LP folk about the ability to signal that a particular comment, by any particular person, is "the view of the Ubuntu project" or other project in LP [12:32] shall we start a broader discussion about "definitive project view" somewhere? or is this just about "Mark decisions"? [12:32] i don't think we should get into having LP try to *guess* which statements are just statements and which are "the view" [12:33] so, I could mark a comment by cjwatson as "the view for Ubuntu", but so could cjwatson do the same on a comment from slangasek, or me, or mpt [12:33] until then "AND THE FINAL DECISION IS: ..." in a bug description should make it quite easy to guess right ;-) [12:34] How would ACLs work marking comments: any Ubuntu Member could so mark a comment? [12:38] I think right now most of the bug decisions can be made by ubuntu-bug-control [12:38] (which ubuntu-dev is a member of) [12:38] I guess that'd make sense here as well [12:40] Preserving ~ubuntu-bug-control as an arbiter of bug status/comment status seems the least-change ACL to me. [12:41] in any case, the general idea makes sense to me and it'd be good to bring it up with Launchpad folks :) [12:42] I'm not sure if there's more to be discussed on this topic for now? Maybe highvolt1ge can follow up on the CC mailing list later on and give us feedback about this discussion? [12:43] "Project bug contracts should be able to mark particular comments as authoritative statements on behalf of the project"? [12:43] persia, that sounds good to me [12:43] * persia files a bug [12:44] thanks persia [12:45] is there any other action items? sabdfl: have you thought about a place on the wiki already? [12:49] Is the wiki he right place for this? [12:50] sabdfl, had mentioned a wiki page before [12:50] popey, Where else would you suggest? Wiki has attribution and editability. [12:50] Who is the target audience of this content? [12:50] Community members, developers, 'outsiders' ? [12:51] ls [12:51] oops [12:52] it'd really be good to get Jonathan's feedback, so we can see if the proposal that we discussed up until now helps with his concern [12:52] Bug #800149 [12:52] Launchpad bug 800149 in Launchpad itself "Project bug contacts should be able to mark particular comments as authoritative statements on behalf of the project" [Undecided,New] https://launchpad.net/bugs/800149 [12:53] thanks persia [12:53] sounds like askubuntu +1 / -1 and *'ing a good answer to me [12:54] Kinda, yeah, except not so crowdsourced: just binary. [12:54] Who guards the guards? ;) [12:55] I mean we already have bugs where someone in the project has rejected out of hand a bug report, and that would probably get a * [12:55] but the rejection was (in the instances I'm thinking of) wrong [12:55] but once it's been "tagged" as "The word of $DEITY" that's it, game over? [12:56] I don't think it's ever "game over". [12:56] the bit is then flipped to "opinion" and nothing gets done to 'fix' the issue, and we end up looking daft [12:57] from a bug reporters perspective it is seen to be game over when the maintainer says "no" [12:57] I think this gives us the ability to say "Yeah, we thought about it, and decided this". [12:57] We have no maintainers in Ubuntu. [12:57] that is not true [12:57] unless I used the wrong word [12:58] "people who maintain the thing the bug was filed against" [12:58] ^ my use of maintainer [12:58] We don't have those. [12:58] persia: that's a mantra, but its truth varies from package to package [12:58] we officially don't in order to discourage maintainer-lock problems [12:58] The way the developer structures work specifically implies that no single person is ever completely responsible for a package. [12:59] Yes, and meanwhilst back on planet earth. [12:59] but there are clearly plenty of cases where there's only one or two people working on something in practice, and from a bug reporter's point of view it's a distinction without a difference [12:59] In practice, we may all agree to delegate the decision for something to someone who knows the most about it, but that's kinda different. [13:00] Knowing most about it doesn't mean they're qualified to tag a bug as 'notabug' [13:00] Indeed. I don't think we ought ever delegate decisions that way, but in practice, we have. [13:02] ok, where do we go from here? [13:02] From a user/bug-reporter perspective if the person who seems to be curating the service/package the bug is filed against rejects the bug, and this is tagged as the right answer I am concerned that this brings the shutters down on further discussion. [13:03] while I do somewhat agree with you, my opposing perspective is often that voting seems to continue until morale improves, if you see what I mean [13:04] I'm not advocating voting [13:04] that wasn't quite what I meant [13:04] ok. [13:05] I dont see what you mean then ☺ [13:05] I meant that there are some things when discussion just goes on and on and on endlessly and it's a drain on everyone's time [13:05] even (or especially) after a developer has responded [13:05] Oh completely. [13:06] one person's rejection out of hand is another person's belief that they've researched the problem more carefully and that the first instinct is seductively wrong [13:06] Mind you, there are a number of cases where the developer responds "I don't have time, won't fix" without much explanation, but that's more a matter of "someone else has to do this: you won't convince me" than "this should not be done" [13:06] and that's what mediation is for [13:06] I'm less concerned about those types of bugs being let to carry on and on, and more concerned about the bugs which start "this is a bug", "no it isn't tag:notabug", end of bug. [13:07] but that's not necessarily different from what we have now, no? [13:07] indeed [13:08] I'm wondering if we can narrow done the discussion somewhat :) [13:09] documenting "special" decisions (or however you might want to call it), especially in the case sabdfl, seems to be what highvolt1ge asked for [13:09] I think the wiki page is the right solution for that. [13:09] everything else seems to involve a lot more people in order to make it a good discussion (ie. closing discussion on bugs, etc.) [13:09] The "Give me that in writing" response. [13:12] ok, I'll take an action to reach out to highvolt1ge to find out if that's a suitable solution to his problem [13:12] does anybody else want to take on any action item regarding this broader discussion? [13:14] ok, I take this as a "no" :) [13:15] it's not a proper agenda item, I just wanted us to have a look at https://lists.launchpad.net/ubuntu-council-teams/msg00008.html again - and it seems like the RMB Americas it the only board/council that is currently looking for nominees [13:15] I know that the Forums Council has announced the new Membership process - did they also start looking for new nominees for the FC? [13:16] is the Asia Pac board now up to full size? [13:16] the CC and TB still have some time until they need to get restaffed [13:16] popey, last thing I heard was that the LoCo Council was in touch with a couple of potential candidates [13:16] I'll follow up on that thread again [13:16] ok [13:17] done [13:18] does anybody know about the Forums and Kubuntu Council? [13:18] are they fully restaffed again? [13:18] i dont [13:18] I think the Kubuntu Council sorted it out during UDS [13:19] yes, Kubuntu is all good [13:19] I'll ping the Forums Council as well [13:19] anybody wants to write the team report this time? [13:19] any other business? [13:19] * popey checks when we expire from the cc [13:20] popey, https://lists.launchpad.net/ubuntu-council-teams/msg00008.html [13:20] ah, oct === highvolt1ge is now known as highvoltage [13:24] any takes for the team report? === jjohansen is now known as jj-afk [13:29] ok, mails sent - let's adjourn - thanks everybody === TheDaniel0108 is now known as Daniel0108 === smoser` is now known as smoser [14:44] ## [14:44] ## Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting [14:44] ## agenda: https://wiki.ubuntu.com/KernelTeam/Meeting [14:44] ## === kenvandine_ is now known as kenvandine === drubin_ is now known as drubin [16:59] heylo [16:59] o/ [17:00] o/ [17:00] o/ all [17:01] anyone else around? [17:01] o/ hallyn [17:02] o/ [17:02] right then - lets get started [17:02] #startmeeting [17:02] Meeting started at 11:02. The chair is jamespage. [17:02] Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE] [17:02] [TOPIC] Review ACTION points from previous meeting [17:02] New Topic: Review ACTION points from previous meeting [17:02] sommer and j1mc to look at doc presentation [17:02] sommer or j1mc around? [17:03] hmm guess not [17:03] jamespage: sorry, i am here. [17:03] [TOPIC] Oneiric Development [17:03] New Topic: Oneiric Development [17:03] Hello! [17:03] just in time - all yours [17:03] http://status.ubuntu.com/ubuntu-oneiric/group/topic-oneiric-server-overview.html [17:03] o/ [17:03] LINK received: http://status.ubuntu.com/ubuntu-oneiric/group/topic-oneiric-server-overview.html [17:03] (/me actions himself to get the trend line reset) [17:03] Firsty, we are doing much better with our merging and syncing; and our new bug count is looking better. However, whilst we are making progress burning work items; we possibly need to switch more focus to the feature development. [17:03] Incidently, we have a metric tonne of MIR's we need to undertake. We really need to distribute these agmonst the team. We should strive to raise the MIR's for at least two each before next week. [17:04] Takeway.. if there isn't a WI for the engineering effort currently being done; ask yourself if you should be doing it. :) [17:04] ... [17:05] Daviey: are most of the MIR's around the dependencies for openstack? [17:05] jamespage: mostly yes [17:05] but TBH, there shouldn't be too much of a requirement to have a deepo knowledge of the package [17:05] rightoh [17:06] so pick 2.. and just get 'em done. [17:06] Remember to mark INPROGRESS [17:06] :) [17:06] oooh...i can stop then :) [17:06] (sorry for brevity, on the phone at the moment) [17:06] zul: no, you need to do 4. [17:06] oooh...i can stop then :) [17:06] any other questions for Daviey or about oneiric development? [17:06] Daviey: briefly, I think the new bug count is actualy getting worse, not better. [17:06] SpamapS: it's better than Friday. [17:07] :) [17:07] SpamapS: But yes, it's something to watch.. However, at the moment, we really do need to put more focus into feature work. [17:07] Daviey: 42 and 62 aren't really that much different. We were at 0 for 2 entire cycles. [17:08] SpamapS: i was cracking at them this morning [17:08] so the q is, is everyond doing their half-day bug triage, and is that not being enough? [17:08] I know that we have had a few more packages added, but we haven't had resources added. [17:08] SpamapS: Hmm.. I have a graph.. but yes, but count is raising. And there is a secret weapon to help address this. [17:08] hallyn: I think we've all fallen behind on the half day triage. [17:09] Daviey: well that's good news bc it means maybe if we are more disciplined abouthat we can address this without being more drastic :) [17:09] [late question: where is the MIR list] [17:09] hallyn: im not i know i been slacking [17:09] smoser: see the WI's [17:09] ah [17:09] smoser: http://status.ubuntu.com/ubuntu-oneiric/group/topic-oneiric-server-overview.html (search for "MIR ") [17:10] OK sounds like we all need to ensure that we are doing the full half day of bug triage that we sign up for each week [17:10] it would be good to get the new bug count down [17:10] Mind you I think the wiki page suggests it shoud only take a few minutes :) [17:10] * smoser is looking forward to a bug triage engineer [17:10] there are major trends in that bug count [17:11] smoser: are you cloning one? (an engineer that is) [17:11] that surely can be identified and easily reduced / removed with some dedicated engineering [17:11] hallyn, i thought i had put you in charge of that. [17:11] anything else on Oneiric development? [17:11] jamespage: no, please move on. [17:11] I also think that we may be writing off some common recurring themes as "a system problem" when the pattern itself suggests we should eliminate the automated bug report. [17:11] smoser: mine will take, oh, 18 years to be ready. [17:11] [TOPIC] Ubuntu Server Team Events [17:11] but she's working on it [17:11] New Topic: Ubuntu Server Team Events [17:11] anyone attending anything interesting? [17:11] SpamapS: good point, maybe we should talk about that sometime [17:12] linuxcon in august [17:12] yeah thats a topic for next week. [17:12] ok [17:12] http://ubuntu-server-new-bugs.notlong.com/ [17:12] LINK received: http://ubuntu-server-new-bugs.notlong.com/ [17:12] Probably worth talking about now that its about a month away.. I'll be a OSCON in Portland [17:12] (juust for the record) [17:13] noted [17:13] [TOPIC] Weekly Updates & Questions for the QA Team (hggdh) [17:13] New Topic: Weekly Updates & Questions for the QA Team (hggdh) [17:13] hggdh: around? [17:13] yes [17:13] all yours [17:15] no news from me, except a SRU verification fot TGT and NBD [17:15] .. [17:15] hggdh: Thanks for that. [17:15] hggdh: We should probably sync up soon to look at what needs testing for A2. [17:16] A2 should have installer differences. [17:16] Daviey: indeed. We will need to revisit all tests [17:16] hggdh: oh joy. :) [17:16] hggdh: and update the automated testing as required as well [17:16] hggdh: How is jenkins deployment going for CI testing? [17:17] we are moving all Jenkins to the new lab facility [17:17] and will be (hopefully) expanding the tests [17:18] Daviey: when are the installer changes due to land? [17:19] jamespage: by end of next week [17:19] right so we need to line up any automated test changes to that timescale otherwise it will all break.... [17:20] ok anything else for hggdh? [17:20] [TOPIC] Weekly Updates & Questions for the Kernel Team (smb) [17:20] New Topic: Weekly Updates & Questions for the Kernel Team (smb) [17:20] Hi [17:20] * SpamapS makes a note not to write his boot testing until after the installer changes [17:20] So a bit more playing with Oneiric dom0. There is one thing I think we need to decide. [17:22] Last time I looked, the xen tools would use the -server kernel installed as the dom0 kernel. Should that be changed to -virtual? With the benefit that -virtual should probably have blkback and netback compiled in. Which is currently a pita when trying to launch domUs [17:23] err [17:23] dom0 is a real server, so -virtual wouldn't have the needed components [17:23] which xen-tools? [17:24] * SpamapS reiterates his long time opinion that this is why kvm > xen :-P [17:24] dom0 is not a real server [17:24] Hm, true. (somehow was looking at hardy which take a xen kernel for both, but probably not a good example then) [17:24] SpamapS: centos fan boy ;) [17:24] but i think -virtual is probably not sufficient [17:24] right it isnt [17:25] do you happen to know why? [17:25] is that directed at me? [17:25] smoser: huh? [17:26] dom0 is not a "real server". [17:26] xen runs on the "real server" [17:26] Dom0, or domain zero to expand the abbreviation, is the first domain started by the Xen hypervisor on boot. It has special privileges, like being able to cause new domains to start, and being able to access the hardware directly. Unless DriverDomains are being used, it is responsible for running all of the device drivers for the hardware. [17:26] dom0 runs under xen [17:26] http://wiki.xensource.com/xenwiki/Dom0 [17:26] LINK received: http://wiki.xensource.com/xenwiki/Dom0 [17:26] smoser: effectively, its a real server [17:26] it is meerley a priviledged domU [17:26] it needs all the drivers and hardware bits to be useful in the general sense. [17:27] Tho I agree it is not *actually* the real kernel. [17:27] Is this OT? [17:27] yes. [17:27] i was mostly wrong. [17:27] Ok accepted- So the question would rather be to make sure blkback and netback are really loaded when xen loads that kernel. (maybe in init?) [17:27] i was kind of thinking that dom0 might nit need drivers in some cases. [17:27] but was wrong [17:28] Not sure we want that built-in into the kernel. [17:28] smb: can you open up a bug against xen in launchpad about it then i can add it init [17:28] zul, ok can do that [17:28] thanks [17:28] So the other thing I wasted most of my last week is bug 705562 [17:28] Launchpad bug 705562 in linux (Ubuntu Hardy) "ami-6836dc01 8.04 32 bit AMI kernel lock bug" [Undecided,In progress] https://launchpad.net/bugs/705562 [17:29] And finally I think I got a solution [17:29] ... and its a bit scary [17:30] It made me wonder whether 32bit was ever really used. Anyway, thats all. [17:30] anyone have any questions for smb? [17:31] smb: On another note, did you have thoughts on what we discussed yesterday; regarding the reserved memory theft? [17:31] How we can add optimisations for low memory systems? [17:31] Daviey, well not more than I was saying. Givem more. That actually is what older versions really did [17:32] There is a price to pay to have pae and a virtual memory management [17:33] smb: Okay, i'm interested if we can make cgroups disable memory hogging more discovrable for small systems [17:33] Daviey, and we need to be careful about what this does. The hint is given in dmesg [17:33] smb, 32 bits are used. [17:33] definitely [17:33] smb: okay, thanks. [17:33] at least on amazon, price makes them a real usable option [17:34] smoser, Right, well the comment was about hardy version [17:34] smb: that is all from me, thanks! [17:34] m1.small is 32-bits, yes? [17:34] And about the fact that what happens breaks things quite badly and wondering how it worked at all (for longer period of time) [17:35] SpamapS, right it is [17:35] Quite a popular instance size :-P === Quintasan_ is now known as Quintasan [17:36] OK; moving on [17:36] [TOPIC] Weekly Updates & Questions regarding Ubuntu ARM Server (NCommander) [17:36] New Topic: Weekly Updates & Questions regarding Ubuntu ARM Server (NCommander) [17:36] NCommander: are you here? [17:36] NCommander: around? [17:37] hmm I would guess not [17:37] anyone else able to give and update on ARM server? [17:38] * SpamapS hopes [17:38] OK guess not [17:38] moving on [17:39] [TOPIC] Weekly Updates & Questions from the Ubuntu Community [17:39] New Topic: Weekly Updates & Questions from the Ubuntu Community [17:39] So any questions or updates from anyone in the ubuntu-server community? [17:40] Nope [17:40] [TOPIC] Open Discussion [17:40] New Topic: Open Discussion [17:41] anyone have anything else they want to discuss/raise/inform us all about? [17:41] Hey everybody write more ensemble formulas! :) [17:41] JAMES PAGE! [17:41] ETHERPAD [17:42] jaaaaaaaaaaameeeeeeeeessssssssss page! [17:43] thanks jamespage [17:43] JAMES PAGE!!!1 [17:43] openstack and its related components can use more testing in oneiric! since ive been using it ive hit two major bugs that could have been discovered by simply trying to run it [17:43] that glance bug is fixed btw [17:43] adam_g: good point [17:43] zul, i saw. thanks! [17:43] JAMES PAGE is an ubuntu developer. Woot! [17:43] +10 adam_g [17:44] I guess his developer contributions and activity were in line with precedence [17:44] lol [17:44] lol === Guest72525 is now known as Omega` [17:44] [TOPIC] Announce next meeting date and time [17:44] New Topic: Announce next meeting date and time [17:44] (only funny if you were in yesterday's ubuntu membership meeting) [17:45] Tuesday, June 28th 2011 16:00 UTC [17:45] see you then [17:45] #endmeeting [17:45] Meeting finished at 11:45. [17:45] o/ === jj-afk is now known as jjohansen [17:59] o/ [17:59] \o [17:59] o/ [17:59] o/ [17:59] #startmeeting [17:59] Meeting started at 11:59. The chair is bjf. [17:59] Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE] [17:59] o/ [18:00] ## [18:00] ## This is the Ubuntu Kernel Team weekly status meeting. [18:00] ## [18:00] [LINK] https://wiki.ubuntu.com/KernelTeam/Meeting [18:00] [LINK] https://wiki.ubuntu.com/KernelTeam/ReleaseStatus/Natty [18:00] LINK received: https://wiki.ubuntu.com/KernelTeam/Meeting [18:00] LINK received: https://wiki.ubuntu.com/KernelTeam/ReleaseStatus/Natty [18:00] # Meeting Etiquette [18:00] # [18:00] # NOTE: '..' indicates that you are finished with your input. [18:00] # 'o/' indicates you have something you'd like to add (wait until you are recognized) [18:00] # [18:00] [TOPIC] ARM Status (ppisati) [18:00] New Topic: ARM Status (ppisati) [18:00] Kernel development: nothing new to report. [18:00] Oneiric/ti-omap4: during the last TI call we got to know that _perhaps_ we will get a 3.0 kernel for the O cycle. Still not 100% sure and no ETA yet. Linaro already has a .39 kernel but it doesn't boot on my panda (while it seems it works ok with a linaro hwpack if device tree is disabled). [18:00]