=== |Aryn| is now known as aRyn === beuno_ is now known as beuno === fdd is now known as mem === mem is now known as core0 === core0 is now known as fdd [11:21] @schedule [11:21] bazhang: Schedule for Etc/UTC: 23 Jul 17:00: QA Team | 23 Jul 22:00: Platform Team | 24 Jul 13:00: Desktop Team | 24 Jul 14:00: Java Team | 24 Jul 16:00: Ubuntu Mobile | 25 Jul 20:00: MOTU === RainCT is now known as RainCT_ [16:44] @now [16:44] boredandblogging: An error has occurred and has been logged. Please contact this bot's administrator for more information. [16:45] @schedule [16:45] boredandblogging: An error has occurred and has been logged. Please contact this bot's administrator for more information. [16:46] hrghgh === bazhang is now known as jokey === jokey is now known as bazhang === ubottu changed the topic of #ubuntu-meeting to: Calendar: http://fridge.ubuntu.com/event | Logs: https://wiki.ubuntu.com/MeetingLogs/ | [17:53] @now San Francisco [17:53] greg-g: Error: Unknown timezone: San Francisco - Full list: http://tinyurl.com/4vyvp8 [17:53] @now Los Angeles [17:53] greg-g: Current time in America/Los_Angeles: July 23 2008, 09:53:38 - Next meeting: Community Council in 13 days [17:53] @now [17:53] greg-g: Current time in Etc/UTC: July 23 2008, 16:53:53 - Next meeting: Community Council in 13 days === ubottu changed the topic of #ubuntu-meeting to: Calendar: http://fridge.ubuntu.com/event | Logs: https://wiki.ubuntu.com/MeetingLogs/ | 05 Aug 22:00 UTC: Community Council | 28 Aug 00:00 UTC: Rebuild test | 14 Aug 00:00 UTC: Intrepid Alpha 4 | 24 Jul 00:00 UTC: Intrepid Alpha 3 | 11 Sep 00:00 UTC: UserInterfaceFreeze | 28 Aug 00:00 UTC: Upgrade testing begins [17:59] bah, Portland should be a valid time [18:00] :) [18:00] bdmurray: who lives there? ;-) [18:00] like everybody! [18:00] * jpds waves. [18:01] * stgraber waves [18:01] * ogasawara waves [18:01] hey all! [18:01] hey! [18:01] * cgregan waves [18:01] hello [18:01] o/ [18:01] hey everyone [18:01] #startmeeting [18:01] Meeting started at 12:04. The chair is heno. [18:01] Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE] [18:02] Agenda: https://wiki.ubuntu.com/QATeam/Meetings [18:02] hello [18:02] hey [18:02] hi [18:02] hi [18:02] lot of people tonight [18:02] I've moved the technical items to the top of the list to make sure we get to them [18:03] great to see lots of new people! [18:03] [TOPIC]: Alpha 3 testing status [18:03] New Topic: : Alpha 3 testing status [18:03] sbeattie, davmor2, stgraber ^ your views? [18:04] I understand ubiquity is a bit broken still [18:04] Server looks good except a weird conflict between LAMP and Mail server, I pinged #ubuntu-server about it [18:04] ubiquity is a bit broken and we have a kernel/usplash bug making usplash to display a black screen [18:04] there aren't that many things to test till the ubiquity issues get fixed and kubuntu has a number of post install issues [18:04] thank god it's an alpha [18:04] fixed ubiquity is being uploaded now [18:05] davmor2: post install issues? [18:05] after Alpha2 I wonder if we need like an ISO testing twitter feed :-) [18:05] kdesudo, printing, adept, etc [18:05] ah well, details details :) [18:05] testing in kvm is still more or less broken for Desktop so I won't be able to help much there. I'll work on Edubuntu and Server images testing for today. [18:06] As I say post install the install on alternative is fine [18:06] have anyone tried virtualbox? is still broken as well? [18:06] cr3 will be piloting some more automated install testing for this alpha - Ubuntu/Kubuntu i386/amd64 [18:06] heno: can we get details of that sent to ubuntu-qa? [18:06] ara: I tried to install virtualbox and it's still not using dkms on Intrepid so I can't get it to build the kernel module [18:07] vbox worked for me about two weeks ago but was broken yesterday [18:07] I test on hw mostly so pass :) [18:07] LaserJock: yes, we'll post the test results and an overview of what we are doing === ubottu changed the topic of #ubuntu-meeting to: Current meeting: Test Event | Calendar: http://fridge.ubuntu.com/event | Logs: https://wiki.ubuntu.com/MeetingLogs/ | 07 Dec 19:00 UTC: Mozilla Team | 02 Nov 19:00 UTC: Mozilla Team | 14 Sep 18:00 UTC: Mozilla Team | 03 Aug 18:00 UTC: Mozilla Team | 23 Aug 13:00 UTC: Xubuntu Community [18:08] heno: awesome, thanks [18:08] basically we are opening up the Canonical certification infrastructure to also be useful to the wider Ubuntu project [18:08] stgraber, cr3 and schwuk are working on that [18:09] good news [18:09] so it looks like testing will continue most of tomorrow [18:09] [TOPIC]: Searching for upstream Debian bugs (bdmurray) [18:09] New Topic: : Searching for upstream Debian bugs (bdmurray) [18:10] I found out that the debian bug tracking system has a SOAP interface somewhat recently and I've written a script for searching package bugs for a string with it. [18:10] It's called debian-bug-search and I've added it to the ubuntu-qa-tools project [18:11] useful, thanks [18:11] I've had some success using it and thought it might be handy for the Hug Day tomorrow with apt [18:11] that will be excellent! [18:12] is there any documentation available? [18:12] bdmurray: do you have some other tools that would be helpful for Hug Days or triaging in general? [18:12] bdmurray: so is the idea behind it to help confirm upstream issues or to tag the ubuntu bug with the upstream bug? [18:12] seems like you do [18:12] The idea is to link upstream bugs to Ubuntu bugs [18:13] especially with a package like apt it's very helpful information [18:13] Sounds like a plan [18:13] heno: I put a wee bit of documentation in the README for the project but its really straight forward [18:13] perhaps we need a tools page under the hug day pages - we could move the 5-a-day and editmoin text there [18:14] they currently take up a fair bit of space on each hug day page [18:14] heno: I was actually thinking about having a Hug Day .deb [18:14] LaserJock: or at least a bugsquad .deb [18:14] or more generally a bugsquader .deb [18:14] lol [18:14] one question, if we find an upstream bug, let's say, for gedit, that it is already filed in debian bug tracking system, which one should we link? [18:14] :) [18:15] the gnome bug tracker or the debian? [18:15] both? [18:15] LaserJock/ heno: ++ [18:15] ara: both seems reasonable to me [18:15] So: Try the new debian bugs tool! [18:15] I'd definitely link the Launchpad bug to the debian bug [18:15] ok, thanks bdmurray [18:15] [TOPIC]: Ubuntu testing teams (StéphaneGraber) [18:15] New Topic: : Ubuntu testing teams (StéphaneGraber) [18:16] The other way might be less useful and you have to use an e-mail interface to work with debian bugs [18:16] ok, so we currently have basically one team of testers for each derivatives [18:16] cody-somerville: ping? [18:16] LaserJock, pong [18:16] ah, there you are [18:16] that's over 400 members counting for all testing teams we have [18:17] unfortunately we only see a very small part of those participating in ISO testing [18:17] I don't know if that's better with SRU testing but those team doesn't seem very useful to me as they currently are [18:18] because people join them and forget about them some weeks later, we don't have a way to contact those testers and don't have (AFAIK) any kind of structure in place at the moment [18:18] if we take ISO testing as an example, I'd say that for Hardy final testing we had only like 15-20 testers most of them testing distributions they don't use usually [18:18] not being able to contact people is particularly difficult [18:18] so you're suggesting a restricted testing team like bug-control? [18:19] that would let us track it better and might instil more commitment [18:19] no, I don't think having a restricted team is a good idea but we clearly need to document what the team is for and maybe setup a team mailinglist on LP so we can send call for testing a week before an Alpha [18:20] Given the nature of testing, and the desire for more testers, it may be best to have clearly inviting language for any such restricted team "Anyone can join, just ask. Renewals every three months. Members are expected to participate in x% of testing targets for the team". [18:20] * persia retracts the comment, seeing that it won't be a restricted team [18:20] stgraber: are there expirations on memebrship? [18:20] is there a reason not to encourage subscription to the ubuntu-qa@ list and announce testing there? [18:20] sbeattie: yeah :-) [18:21] or we could have two levels, modelled on bugsquad/bug-control [18:21] there is 6 months expiry IIRC [18:21] well, what if a LP team list is created [18:21] and that were to be used extensively for testing announcments [18:22] not just "heah, Alpha3 is coming up" but "2008XXXX is invalidated, standby" === ubottu changed the topic of #ubuntu-meeting to: Calendar: http://fridge.ubuntu.com/event | Logs: https://wiki.ubuntu.com/MeetingLogs/ | 07 Dec 19:00 UTC: Mozilla Team | 02 Nov 19:00 UTC: Mozilla Team | 14 Sep 18:00 UTC: Mozilla Team | 03 Aug 18:00 UTC: Mozilla Team | 23 Aug 13:00 UTC: Xubuntu Community | 31 Jul 16:00 UTC: Ubuntu Mobile [18:22] I'm not particularly eager to see all that on ubuntu-qa, but on a testing team list it'd maybe make sense [18:23] I'm wondering how well the current email notification is working [18:23] what I'd propose as a start is: reduce expiry to 3 months, create a mailing-list [18:23] I thought having LP lists for Ubuntu teams was discouraged. [18:23] heno: not well as it's opt-in and people don't generally enable it [18:23] persia: it is, but in this case it might be a good idea [18:23] it's not very good at differentiating between alphas and major milestones where we need more testing [18:24] stgraber: sounds good [18:24] persia: in the sense of using it specifically to contact members of the team [18:24] not for general discussion [18:25] we should then look at posting tracker updates automatically to that list [18:25] we currently have 81 users with e-mail notification turned on [18:25] and make sure it's easy for people to filter [18:25] by having rich header info [18:25] stgraber: you can get email notification from iso.qa.ubuntu.com? [18:25] heno: we just have to create an account on the tracker and subscribe it to all the testcases [18:25] LaserJock: yep [18:25] LaserJock: yes [18:26] I'm guessing half of them or more ignore mails for alphas [18:26] stgraber: didn't know that, interesting :-) [18:26] I'm happy for stgraber to reduce expiry to 3 months, create a mailing-list - any objections? [18:27] go for it :) [18:27] I would just add that I think we could also clarify some of the pages [18:27] heno: btw, can you also make me a team administrator ? pochu wanted to when he left the team but only the owner can do that :) [18:27] LaserJock: +1 [18:27] like the team page and perhaps the wiki page [18:27] stgraber: will do === ubottu changed the topic of #ubuntu-meeting to: Calendar: http://fridge.ubuntu.com/event | Logs: https://wiki.ubuntu.com/MeetingLogs/ | 24 Jul 14:00 UTC: Java Team | 24 Jul 16:00 UTC: Ubuntu Mobile | 25 Jul 20:00 UTC: MOTU | 31 Jul 16:00 UTC: Ubuntu Mobile | 02 Aug 13:00 UTC: Xubuntu Community | 03 Aug 18:00 UTC: Mozilla Team [18:27] ok, next [18:28] [TOPIC]: QA liaison to Launchpad (LaserJock) [18:28] New Topic: : QA liaison to Launchpad (LaserJock) [18:28] heno: are we talking about a @lists.ubuntu.com mailing list? [18:28] LaserJock: an LP one I think [18:28] heno: we may need to discuss that later, lets move on for now [18:29] ok, so in #ubuntu-quality the other day we were discussing some possible improvements to Launchpad that would help in QA efforts [18:29] ok, I don't have strong feelings about where the list sits [18:29] and thekorn, greg-g and some others were talking about having a QA Liaison to Launchpad [18:29] similar to what the MOTU have [18:30] can anyone give a some background on this, please? [18:30] there was also some discussion about possibly teaming the liaisons together to form a "Launchpad Advisory board" or some such [18:30] Would a Canonical employee be okay in this role? We meet with them fairly regularly [18:30] bdmurray: I'd really rather not [18:31] I think that makes sense - several Canonical folks already have good connections with the LP team, but a community voice would be valuable as well [18:31] nothing personal about Canonical employees, but part of the issues that come up is that Launchpad developers communicate with other Canonical employees more often then they do with community people [18:32] I thought this was a liason role though [18:32] so I think it'd probably be better to get an "outside" person [18:32] it is [18:32] but it's not a Canonical-Canonical liaison role, if you know what I mean [18:32] Canonical-CommunityMemeber-Community, Canonical-Canonical-Community [18:33] but a "not" between those two [18:33] s/but/put [18:33] * greg-g grrs [18:33] * persia suspects that some Canonical people may be able to balance the difference, but that a non-Canonical person may be more approachable [18:33] ara: the background is that it's difficult for Launchpad developers to prioritize or even figure out what needs to be done when there are hundreds of voices in their ear [18:34] ara: so having a person appointed as a go-between helps Launchpad developers and our team get things we need done [18:35] I'm wondering what form the liasing would take - maintaing a wiki page of QA team wishlist items would be good [18:35] persia: agreed, very much so [18:35] LaserJock: and I think there is a fair bit of overlap between what I want and what the rest of the team wants - subsequently some points may become redudant [18:35] heno: we kinda have a starting of that now: https://wiki.ubuntu.com/QATeam/IdeaPool [18:35] and be in contact with the LP team on IRC and at UDSes [18:36] heno: for instance, the MOTU liaison uses a "motu" tag, which is a recognized Launchpad tag to prioritize bugs [18:36] LaserJock: there already is an ubuntu-qa tag [18:36] heno: they also work with LP people on upcoming specs that are relevant to MOTU [18:36] greg-g: thanks, we could tighten that and ask the LP team to look at it [18:36] bdmurray: yes, I'm aware of that [18:37] heno: it is most certainly a work in progress, fyi :) [18:37] anyway, this is really part of a larger effort to create a team of people who LP dev/management can go to [18:38] and the community can work through [18:38] If the LP team is open to an additional contact point, I'd be happy to see someone like thekorn in this role [18:39] need to go I'll catch up on the rest :) [18:39] heno: they are indeed [18:40] the person should know LP from a few angles and should ideally have met LP bugs members already at a UDS or so === mdz_ is now known as mdz [18:40] sure [18:41] I was just going to throw out a "who all wants to do it" email to ubuntu-qa and go from there [18:41] perhaps we should post a request for applications ... [18:41] Somebody already checked with the launchpad team then? [18:42] bdmurray: yes, I did [18:42] The LP team have some say in the selection of the MOTU liason, is that right? [18:42] heno: well, yes, and no [18:43] they don't technically but it'd be odd to have somebody do it that the LP people don't want to work with [18:43] so generally you want somebody who has a good working relationship with them [18:44] I can work up a job description, etc. and post it with my email to ubuntu-qa [18:44] I don't remember what the selection process was like [18:45] I was the MOTU liaison for a long time (it's now siretart) [18:45] For MOTU, we've always accepted volunteers. If someone was unsuitable (which has yet to happen), MOTU would likely call for replacement. [18:45] We should work out how this person collaborates with the Canonical QA team members who already have close connections with the LP team though [18:45] heno: well, there is that [18:46] I really think there is a risk of a lot of duplication of effort [18:46] to a fairly large extent what Canonical QA wants to do is up to them :-) [18:46] duplication or overlapping [18:46] In reality our requirements are generally the same [18:46] communication between this person and Canonical QA is also important [18:46] overlapping can be good, if supportive and collaborative [18:47] It doesn't seem efficient to me though [18:47] the Canonical Ubuntu QA team works in the open, apart from a few support cases [18:47] also keep in mind, this is hopefully a part of a larger liaison team [18:47] where we have to preserve customer privacy [18:47] I would like to see QA representation there [18:48] we are building a lot of teams here ;) [18:48] heno: hopefully only good and useful ones ;-) [18:49] I definatelly see where bdmurray is coming from [18:49] We discussed some feature additions to LP bugs at the sprint in London last week - I suggest we flesh out the notes in the ubuntu wiki and discuss it at next weeks meeting [18:50] but my guess is that duplication shouldn't be an issue [18:50] we can then add requests from this group and see whether there is a need for a new team to represent that list [18:51] I think we would be able to agree on the whole list in this meeting format and present that to the LP team as a common list [18:51] then we need to follow that up as LP makes their releases [18:52] with the items in the open wiki we can all follow along [18:52] well, there is a lot more than wiki pages [18:52] such as? [18:52] filing bugs, following up, getting information on upcoming changes in LP [18:53] talking with the LP devs to see what things can be done, etc. [18:53] it's not mearly just presenting them with a wishlist [18:53] as that will almost certainly be largly ignored [18:54] not if we present it as our common feature request list [18:54] lol [18:54] alright, we can try that then, if you think it will work [18:55] let's see how that looks next week, and then reconsider posting the role [18:55] ok [18:55] [TOPIC]: Intrepid Roadmap (LaserJock) [18:56] ok [18:56] so there's the great spec list at QATeam/Specs [18:57] but as we're building the Ubuntu QA team mid-release I wondered if it would be useful to combine Intrepid specs with community efforts into an Intrepid roadmap page [18:58] for Intrepid+1 it should flow much more naturally, but currently there's not a Roadmap for non-spec tasks [18:58] so the question is, does that seem like a fruitful thing to do? [18:59] Roadmaps are good - should some of these things be written up as specs though? [18:59] heno: some yeah [18:59] I just didn't want to interfer with the existing material [19:00] LaserJock: what are the non-spec items you have in mind? [19:01] well, more like bitesized tasks, people can get kind of turned off by "specs" as to large of a process to go through [19:01] I'm more interested in track what people in the team are doing [19:01] LaserJock: can we get some examples? [19:01] ara: simple tools [19:02] we already have todo lists for the bugs team [19:02] like the ones at ubuntu-qa-tools ?? [19:02] (and for testing?) [19:02] or community projects, or things that are just not "big" enough to warrant a full on spec [19:03] https://wiki.ubuntu.com/BugSquad/TODO [19:03] heno: yeah, so I'd like to have an roadmap that indicates what we as a group want to accomplish for Intrepid [19:03] LaserJock: fine with me - feel free to start a page [19:03] heno: yeah, that's good stuff [19:04] let's review it next week [19:04] It may also be good to use un-spec'd Roadmap items as "future" when completing them within the current release cycle is likely infeasible. [19:04] I just don't want people to *not* do work because they think they need a full-on spec to do it [19:04] right [19:04] if it needs a spec go for it [19:04] but I'm more interested in tracking work [19:05] we should in fact review such a list every 4 weeks or so [19:05] we've collected a pretty significant team in Ubuntu QA, more than I had hoped for [19:05] but it needs to be doing stuff ;-) [19:06] right, we should wrap up this meeting and do some ISO testing! [19:06] +1 [19:06] any further topics? [19:06] yes, a short one [19:06] has anyone taken note last week ? [19:06] not me unfortunately [19:07] #endmeeting [19:07] Meeting finished at 13:09. [19:07] thanks everyone! good meeting :) [19:07] thanks heno [19:07] thanks [19:07] sorry, I didn't take notes last week, either. [19:08] if someone did, please update the meeting page on the wiki. It currently only contains the agenda. [19:08] well, thanks everybody [19:08] bye, [19:44] @now [19:44] boredandblogging: Current time in Etc/UTC: July 23 2008, 18:44:48 - Next meeting: Java Team in 19 hours 15 minutes === Moot2 is now known as MootBot === Moot2 is now known as MootBot === RainCT_ is now known as RainCT === RainCT is now known as RainCT_ [23:02] hi [23:02] * slangasek waves [23:02] yo [23:03] evan won't make it today; he called to let me know his ISP is experiencing a massive outage and they can't tell him when they'll be back up [23:03] * ArneGoetje yawns [23:03] yo [23:04] good morning [23:04] hi [23:04] Hey folks./ [23:04] Jp[e all your trips home were uneventful. [23:04] gah cold fingers. [23:05] so who should be here? slangasek, liw, asac, TheMuso, calc, bryce, ArneGoetje, ogra (away), ... [23:06] wow netsplit [23:06] james_w i guess [23:08] * slangasek opens the floor: intrepid alpha-3 tomorrow [23:08] doko, from Colin's mail: asac, ArneGoetje, bryce, calc, evand, james_w, liw, TheMuso, doko, ogra, slangasek [23:08] grab your test cases here: http://iso.qa.ubuntu.com/qatracker/build/all [23:08] anyone has anything on agenda? [23:08] ohh, james_w as well [23:09] slangasek, the ISOs are ready for testing now? [23:09] rsyncing... [23:09] no, just lets go through the list of people about the specs targeted for hardy [23:09] s/hardy/intrepid/ [23:09] * doko upgrades quickly [23:10] lol [23:10] liw: everything except desktop should be viable; the desktop images are rsyncable but not yet worth testing [23:10] slangasek, ook, I'll see about helping with that tomorrow (it's past midnight already...) [23:10] ArneGoetje: could you start the specs state? [23:11] liw: worth starting an rsync though, to save time later [23:11] slangasek, sure [23:12] doko: well, I'm basically working on language-selector to finish the language-support package split we have started in Hardy and make it selectable in the UI. [23:13] doko: good progress in this case [23:14] looks like "not delayed" [23:14] doko: I expect it to be ready for FF [23:15] asac: continue? [23:15] no :) [23:15] j.k [23:15] well. for firefox and such the biggest building blocks are flash experience and safe upgrading [23:16] flash experience is partly done. the tricky bits still missing though [23:16] safe upgrading is probably on track as we have some improvements in bzr [23:17] the other thing is NM 0.7, which should enter intrepid after alpha3 [23:18] is there something workable for armel? [23:18] (flash) [23:18] doko: how would i know ;) ... i guess gnash builds in debian. [23:20] asac: is 3g-networking-intrepid covered under "NM 0.7"? [23:20] yes [23:20] asac: do you think these are on track for ff? [23:21] thats basically it. feedback is good so far. [23:21] some cards appear to be not recognized as "modem" by hal. the others work out of the box. [23:22] doko: hard to say. NM 0.7 certainly wont be much tested until we reach beta [23:23] bryce: continue? [23:23] hmm: --- [bryce] idle 291:31:02, signon: Sun Jul 6 17:36:01 [23:24] I haven't seen bryce speak up yet; maybe skip him for now and come back if he shows up? [23:24] calc, continue? [23:24] ok [23:25] OOo upload is slightly delayed [23:25] Its now scheduled for 3.0rc1 to be uploaded week of Aug 21 after Alpha 4 [23:25] which one, 2.4.x, or 3.0something? [23:25] i made a 2.4.1 upload last week to take care of the a3 oversized cd [23:25] could you target just a milestone? [23:25] (is that related to a spec? I don't see anything on https://blueprints.launchpad.net/ubuntu/intrepid) [23:25] this should be as good as rc-something [23:26] slangasek: yea, let me see [23:26] https://blueprints.launchpad.net/ubuntu/+spec/ooo-intrepid-upload-schedule [23:27] i might still be able to get 3.0rc1 in before alpha4 its scheduled for aug 8 [23:27] calc: what about an earlier snapshot? [23:27] but we were wanting to give it a week before, i should be free that weekend due to my wife having a large photoshoot so i can probably get it in on saturday [23:28] doko: i am planning on getting earlier snapshot into a PPA, hopefully by the end of this week, i was going to get it in last week but the 2.4.1 upload delayed it a bit [23:28] we didn't want to put 3.0 into intrepid directly until rc due to they may slip the schedule too much.. [23:28] calc: please could you use the group ppa? [23:28] ok will do [23:29] thanks [23:29] ok, that's me then [23:29] so assuming no more slippage by OOo we will have 3.0rc in around aug 8 for FF [23:29] calc: do you mean that we don't want to *count* on putting 3.0 into intrepid directly until RC? [23:29] slangasek: yes, it could be that they slip the release past our release [23:29] 'cause if it's available sooner, surely it's better to have it in [23:29] right [23:30] unless we plan on just shipping a 3.0rc [23:30] well unless we are ok with doing that in case they slip i mean [23:30] calc: ususally the critical patches are in ooo-build, so I wouldn't bother that much if it's 3.0rc- [23:30] ok [23:31] not sure if we should get into a full discussion about that here, but I would note that hardy's support cycle is well past intrepid's, so security support isn't a concern for sticking with 2.4 [23:31] +1 [23:32] calc: please go ahead of debian. we'll have to have it releasable, not them [23:32] * calc isn't planning on waiting on debian for this, as they are already frozen (aiui) [23:33] calc, Debian freezes next weekend, I think, but that's close enough [23:33] ok [23:34] * doko doesn't have any specs, but "java in main". getting in shape, although we'll have to use three different jvms together with openjdk. next thing is to default default-jre/-sdk to openjdk. this will be done before ff. [23:34] I'm not sure if I will get a working python3 (not just the core package) in intrepid in ff. [23:35] doko: will the java applet situation on !i386 improve this cycle? [23:37] no, probably not. there is work done by fedora on the icedtea plugin, but it's currently not my focus (and still labeled as experimental) [23:37] doko: is openjdk-6 ready enough for me to attempt to switch OOo building to it? [23:38] calc: yes, there was never anything wrong with it (except being located in universe) [23:38] and you told me you did test it ;) [23:38] ok, great :) [23:38] yes it worked last year when i tested it [23:39] evend is not here; james_w, continue? [23:40] ahh, isp problems; liw, continue? [23:40] james_w is also having isp problems? [23:40] cleanup-cruft: progressing nicely (cleaning up prototype code from the sprint) [23:41] python-memory-profiling-tool: stalled [23:41] get-rid-of-python-central-and-support: slow progress this week, need to finish the doc/spec [23:41] gobby-server-persistent-state: code works, waiting for reactions from IS and upstream [23:41] fast-lsb-release: not started yet [23:41] super-piuparts, lintian-harness-improvements: post feature freeze [23:41] no-fsck-at-boot: to be reassigned, but have concluded that it's not doable without new magic [23:41] [23:42] happy to look at the get-rid-of spec ... (we have to few get-rid-of specs overall ;) [23:42] get-rid-of-computers [23:43] liw: all specs in time? [23:44] I'm not critically late on anything, yet, if that's what you're asking :) [23:44] ok [23:44] ogra not here; slangasek, continue? [23:46] no approved specs assigned; I have the pam configuration magic which I'm working on and believe I can deliver in time for intrepid, but this isn't actually on the schedule anywhere officially at this point [23:46] (that's https://wiki.ubuntu.com/PAMConfigFrameworkSpec) [23:47] 'sall for me, unless someone has questions [23:47] ok, TheMuso to close the list ... [23:47] Desktop Accessibility Review spec: Still reading and understanding code and documentation for python-dbus/policykit interaction and reading docs for python-xlib/python-gtk, but am almost ready to port some code from gnome-session to python, that is used for checking that at-spi-registryd started correctly. This will be used in ubiquity-dm when accessibility is enabled for speech/magnification. [23:48] I will certainly have the ubiquity stuff fixed up for FF, but will have to take things one at a time to get software sources/hardware testing ported to policykit/getting the UI accessible to the user. [23:48] So certainly some of the spec will be completed by FF. [23:49] Dmraid: Spent time with Colin at the sprint getting to understand partman internals, and now reading libparted code to educate it about dmraid/mapper devices for use with dmraid. Need to read vol_id code to link against dmraid shared library for use with providing better integration for vol_id/udev for use at boot. [23:49] Confident that this will be complted by FF. [23:50] slangasek: did you see any specs not mentioned (besides from people not in the meeting)? [23:50] nope [23:50] TheMuso: how is sound going? [23:51] asac: Since Debian is freezing soon, I am not sure whether they will hav e alsa 1.0.17. Once I know for sure, I'll either merge, or upload new upstream versions of the alsa bits. I also intend asking the kernel guys about getting alsa driver 1.0.17 into the kernel, so everything matches. [23:51] I am still aware of the pc-speaker issue, and intend debugging that today. With luck, 1.0.17 will help solve it. [23:52]