=== brandon_p is now known as perlluver [04:56] a === a|wen- is now known as a|wen === apw`` is now known as apw === johnc4511 is now known as johnc4510 === johnc4511 is now known as johc4510 === thekorn_ is now known as thekorn === beuno_ is now known as beuno === mvo_ is now known as mvo === thunderstruck is now known as gnomefreak [16:00] good afternoon [16:01] cjwatson: hey [16:01] hello [16:01] hi [16:01] hello [16:02] #startmeeting [16:02] Meeting started at 10:02. The chair is cjwatson. [16:02] Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE] [16:02] doko said he was unlikely to be able to make it [16:03] back and still living =) [16:03] oh good [16:03] TheMuso is probably asleep; we discussed the possiblity of a meeting and came to the conclusion there wouldn't be one [16:03] ah, I was too late, sorry [16:04] so missing evand and vorlon (presumably vorlon is asleep too if he was in that conversation) [16:04] * cjwatson prods Evan elsewhere [16:04] no, just me and TheMuso [16:04] hmm, didn't I see an email from robbiew saying the meeting was cancelled? [16:04] slangasek, I got one from Google Calendar [16:04] Sorry, lost track of time. [16:04] he cancelled it on the calendar, but I sent out a separate mail [16:05] cjwatson > Google Calendar [16:05] it seems as though we ought to have a FF round-up in time to be able to do something about it ... [16:05] hmm, oh [16:05] cjwatson: but you didn't readd it to the calendar, so those people with alarms set wouldn't be alerted ;) [16:05] I blame the lack of telepathic calendars [16:06] ok, so in my mail I asked for people to have a quick summary of what they were doing FF-wise that was potentially in trouble [16:06] how about I start [16:07] most of oem-config-server is done, and the parts that remain should be in time for FF (most significantly, a tasksel component) [16:08] server-pre-installation involves a lot of little bits, some of which have been agreed to be relatively unimportant and probably won't make it; the thing I'm pushing on hardest is support for manual package selection, on which I've made progress but haven't quite managed to get it to work, so at some risk [16:08] I'm working on LVM by default for the server at the moment, which should be in time [16:09] otherwise I may be able to help other folks out a bit [16:09] [end] [16:09] evand: how about you? [16:10] the slideshow work has been deferred as Julian's team does not have the resources for it this cycle, I'm currently in the middle of the oem ID work, and should have that done tonight or tomorrow, and there's some little bits left on the ubiquity work that I'll be able to knock off in the few days we have left [16:12] ok, that was quick :) [16:12] james_w: yours mostly aren't FF-critical, but ...? [16:13] I like to try and have bzr-builddeb contain the code that is doing the lifting on package-import.ubuntu.com, but that is not required [16:13] there probably aren't features needed to be added to get Debian branches available, so that should be safe [16:14] I do want to try and tackle a couple of usability things, but I'm not sure what the solution is, so they may have to wait until next cycle [16:14] usability in bzr-builddeb, or elsewhere? [16:14] the rest of the work is de-synced from FF I believe [16:15] (though I want to get the latest launchpadlib snapshot in, but that's not too much work) [16:15] cjwatson: yes, usability in bzr-builddeb [16:15] for instance making it easy to supply "-v" when building a merge from Debian [16:16] ah, yes [16:16] (isn't that just a bug? ;-) ) [16:17] that's all from me I think [16:17] ok [16:17] liw: [16:18] I need some help from mvo to merge Computer Janitor and update-manager code bases, and someone to sponsor uploads, but that should be it [16:18] I should be able to get all necessary changes in (just) in time for FF, unless I break my back further [16:18] yeah, sorry for that, I was not as helpful as I should be [16:18] (end) [16:18] mvo, you'll get more mail tonight :) [16:19] breaking backs considered a bad idea for making FF ... [16:20] and now I'm reminded that I've been meaning to try out doko's PPA [16:20] doko: [16:21] cjwatson: for python? [16:21] yep [16:22] want to play with 2.6 :) [16:22] me too! [16:22] :) [16:22] well, upload of python2.6 will follow later today. will depreacate 2.4, so that the packages that we will rebuild don't increase in size [16:22] 2.5 still the default, until we rebuilt the extension modules for 2.5 and 2.6. [16:23] then switch to 2.6, before feature freeze [16:23] I assume that people maintaining python applications should start playing with 2.6 ASAP [16:24] yes, but please let's rebuild the extensions first. should be done by the weekend [16:25] ok, weekend sounds fine by me - do you have time for the helper package changes discussed at the sprint before FF? [16:25] I'm a bit worried that we're talking about switching the python default right before feature freeze when AFAICS python2.6 isn't even in the archive yet [16:26] has testing been done in PPA of rebuilding the extensions, to make sure that works, or are we going to have a pile of bugs to sort through right at FF? [16:26] my concern is sort of inverse, that unless we switch in this release we're going to have a harder time getting to python3 [16:27] I had done some rebuilds using 2.6. there are a few uploads needed to cope with new keywords, like 'with'. but it's not as invasive as the switch from 2.4 to 2.5 [16:28] cjwatson: I concede to the bigger picture, then [16:28] but the sooner python2.6 is in, the happier I'll be [16:29] (python3 is still going to be a hugely complex switch of course, but I'd like to be able to go through and lint things with -3) [16:31] ok, we should continue [16:31] mvo: [16:31] partner-repositories> policy draft almost ready and will go out to ubuntu-devel for discussion [16:31] (but should not really be a FF item) [16:31] jaunty-backup> not a lot that I have done, but I will sponsor deja-dup into universe, its quite nice [16:31] apturl-add-repo> done, in the archive [16:32] jaunty-codec-install> done and in the archive, may need a legal warning dialog in the same spirit as the old one (asked amanda about this) [16:32] (and seeded) [16:32] UX team wishes for update-manager, update-notifier> hopefully make it, bits are done, others are not [16:32] (end) [16:32] UX == DX? === dholbach_ is now known as dholbach [16:32] yeah, whatever todays name is ;) [16:32] update-effects ? :) [16:32] I get confused [16:32] they want eg. update-manager to start automatically when updates are available [16:32] and not display notification bubbles/icons [16:33] UX is Julian's team, DX is David Barth's team? [16:33] its not a big amount of work, but still stuff [16:33] mvo, ugh [16:33] hmm, interesting, I'd have to see the implementation of that ... [16:33] I assume if you close it it gets out of the way [16:33] I saw that in the new laptop in our house yesterday. With Windows. It ruined the movie. [16:33] liw: haha [16:33] I'm not convinced about it myself, but it will start unfocused so at least it does not jump in peoples faces [16:35] * liw mumbles something about every interruption, even unfocused ones, costing fifteen minutes of time when in hack mode... [16:35] * liw stops mumbling, this being off-topci [16:35] liw: there will be a gconf key to get back the old behaviour [16:36] I think it's a valid objection, but maybe it would be better if mvo could supply a UX/DX/whatever contact to have the conversation with [16:36] mpt would be the person to talk to [16:38] Keybuk: [16:39] before FF I'd like to get upstream updates for udev, module-init-tools and util-linux-ng in [16:39] obviously these all depend on upstream ;) [16:39] also would like to land the hwclock changes and the console changes (which still need testing) [16:41] happy to help with those if you have prototype work, since my system seems to have stopped crashing upon switching to console [16:42] the fix to make pm-utils not call hwclock is in, thanks to james_w - suspend/resume is a fair tick faster now :) [16:42] it's not a long enough job to need help [16:42] ok [16:42] I confess to the sin of offering help rather than Just Doing It [16:44] slangasek: [16:45] good progress on hotkeys, I think everything that counts as "feature" work will be done on schedule - with a fair number of bug fixes we can follow up on after [16:46] the grub2 spec is well behind where it ought to be; I'm certainly going to try to make up the difference this week and next, but that could probably use some help, particularly on the installer side - though part of the problem is that I don't have the spec itself ready for review, so I need to get that done today/tomorrow :( [16:46] (that's also a low-priority spec, so if it doesn't make it, that's unfortunate but not the end of the world) [16:46] the copyright format spec isn't FF material [16:46] I can offer whatever help is needed on the installer side (of course grub-installer *should* already support grub2, it's just a switch to flip) [16:47] and there's work to be done on the power management cleanup spec as well - hopefully I'll get a chance to dive into that this week too [16:47] I agree that copyright format isn't FF material but would like to see it sooner rather than later, since other parts of Canonical are on our backs about that :-/ [16:47] indeed [16:47] the hotkeys stuff has been looking great, I can almost understand it now ;-) [16:47] * slangasek grins [16:48] I think there'll probably be an update to Samba 3.3 before FF; I need to discuss this with the server team though, but it does look like Debian unstable will move to the new upstream version soon [16:48] that's it for me, I think [16:48] perhaps relevantly, debian-devel-announce suggests that lenny will release on Saturday [16:48] so for a small number of packages that may be useful [16:49] yep - that should restore a bit of balance to unstable :) [16:49] making it live up to its name? :) [16:49] that's all from me, anyway - AOB? [16:52] not from this quarter :) [16:52] guess not, thanks all and I'll let you get back to work :) [16:52] #endmeeting [16:52] Meeting finished at 10:52. [16:52] thanks! [16:52] thanks [16:52] thanks! [16:52] thanks [16:57] Hi all :) [16:58] hey hey hey [16:58] howdy [16:58] * ara waves [16:58] * charlie-tca waves [16:59] hey all! [16:59] hi heno [16:59] hi. [17:00] hey [17:00] hey charlie-tca, jcozens [17:01] #startmeeting [17:01] Meeting started at 11:01. The chair is heno. [17:01] Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE] [17:01] welcome back everyone :) [17:02] agenda as usual: https://wiki.ubuntu.com/QATeam/Meetings [17:02] * UbuntuBugDay resume [17:02] pedro_: ? [17:03] Last week we ran the update-manager hug day -> https://wiki.ubuntu.com/UbuntuBugDay/20090205 [17:03] Martin Mai (MrKanister on IRC) helped us with the organization since we were sprinting at Berlin so if you see him online give him a big hug [17:04] the Hug Day hero was the awesome Michele Mangili (mangili on IRC) if you look to the page you'll see what i'm talking about [17:04] indeed [17:05] next hug day (tomorrow) is going to be based on the bugs without a package https://wiki.ubuntu.com/UbuntuBugDay/20090212 [17:05] there's already people working on them ;-) so feel free to join us at any time [17:06] mangilimic is already out in front :) [17:06] pedro_: I'd like to put the no package bugs w/ attachments in the More Bugs section, alright? [17:06] thanks pedro (and mangilimic!) [17:07] [TOPIC] hugday-tools call for testing [17:07] New Topic: hugday-tools call for testing [17:07] bdmurray: yes that's totally ok, feel free to add them [17:08] that was a topic by thekorn, but he doesn't seem around [17:08] but it is kind of related with ubuntu-qa-tools that I added, I could talk about it [17:08] anyone know the LP URL or so? [17:08] ah hugday-tools right, thekorn rewritten the hugday-tools in order to work with the new wiki format [17:09] he was asking for testing, so tomorrow is the perfect day to test the tool *cof* *cof* [17:09] I've added some documentation at https://wiki.ubuntu.com/UbuntuBugDay/Tools [17:09] great, thanks [17:09] but it needs to be updated since it's now included on the ubuntu-qa-tools [17:10] i'll do that after the meeting [17:10] so let's jump to [17:10] [TOPIC] New ubuntu-qa-tools package [17:10] New Topic: New ubuntu-qa-tools package [17:11] the project in lp ubuntu-qa-tools is now packaged and should be available in Jaunty anytime soon [17:11] \o/ ! [17:11] Yay :) [17:11] it was approved by the sponsors and it is awating in the queue [17:12] sweet! [17:12] it will also include the new hugday tool by thekorn [17:12] tools are in the repository already [17:12] those who are attending other team meetings might mention it and ask if they use tools that might fit in there [17:12] ara: looks to be in with the latest updates :) [17:12] ara: what's the hugday tool? [17:12] er oh that nevermind [17:13] Read-me for hugday tool is /usr/share/doc/hugday-tool [17:13] please, report any bugs in the ubuntu-qa-tools package in launchpad [17:13] thanks ara! [17:14] [TOPIC] GlobalBugJam reminder [17:14] New Topic: GlobalBugJam reminder [17:15] I don't see jorge online [17:15] anyway here is more info: https://wiki.ubuntu.com/GlobalBugJam [17:15] I'll be heading to the London one [17:16] who else is going to an event? [17:16] I might be going to the birmingham one [17:16] I am here sorry, was on a call [17:16] charlie-tca: even after installing, that file doesn't exist, just for the record [17:16] I'll be participating with the guys at Chile and i'll be online as well helping on #ubuntu-bugs [17:16] jcastro: sorry, my bad [17:16] I'll be participating in detroit and online [17:17] Washington, DC, we have one on Saturday [17:17] (the 21st) [17:17] there's a couple of sessions about how to run a bug jam so if you're interested : [17:17] we're up to ~26 teams signed up, if we can hit 30 teams that would be great [17:17] February 13 at 1200 UTC with dholbach as the speaker [17:18] and February 14 at 0000 UTC with jcastro [17:18] yeah, those are the typical training sessions [17:18] the sessions are taking place in #ubuntu-classroom [17:19] Great, looking forward to the GBJ :) [17:19] [TOPIC] New GNOME desktop testing team [17:19] New Topic: New GNOME desktop testing team [17:20] A new GNOME team was created a couple of days ago. It is focused on automated testing for the desktop [17:20] http://live.gnome.org/DesktopTesting [17:20] LINK received: http://live.gnome.org/DesktopTesting [17:21] A new SVN module is set up with the ubuntu-desktop-testing project, but without things specifically for Ubuntu (in this case called gnome-desktop-testing) [17:21] there is also a mailing list: http://mail.gnome.org/mailman/listinfo/desktop-testing-list [17:22] please, join the mailing list if you're interested in making gnome a better desktop for linux (and ubuntu) [17:22] does KDE have a corrolary? [17:22] a nice place to announce LDTP 1.5 :) [17:23] maco: KDE is still a bit lacking in a11y infrastructure [17:23] which is what we use for automated testing [17:23] LDTP? [17:23] maco: I am afraid no, the at-spi layer (the accessiblity layer) will move to dbus any time soon (?) and then it would work [17:24] maco: http://mail.gnome.org/archives/desktop-testing-list/2009-February/msg00002.html [17:24] LDTP is the testing framework that we are using in the ubuntu-desktop-testing project. LDTP 1.5. was released a couple of days ago. [17:25] I packaged it for Ubuntu (to avoid debian version not reaching feature freeze) and it is now fully available in Jaunty [17:25] ara: is there a screecast that explains test automation? [17:25] heno: there isn't [17:25] heno: shall I add that to my todo list? [17:25] I think there are some AI2 and accerciser ones, but not pure LDTP [17:26] er...didnt mean to re-paste that [17:26] ara: for a start you could request one from the screecast team [17:26] oh i didnt. i scrolled. sorry [17:26] (though realistically it might turn out better and sooner if you do it) [17:27] just pick on popey :) [17:28] right, I'll meet him next week [17:28] ara: can you post a request on the screen cast team page? [17:28] sure [17:28] then I'll check with popey [17:29] [TOPIC] Possible issues with menu systems in testcases - davmor2 [17:29] New Topic: Possible issues with menu systems in testcases - davmor2 [17:30] Right so with the wiki migration we've hit an issue involving the differing menu systems in the *buntu family. Because none of them are the same you can't tell people to click on xmenu->ymenu->app to start an app [17:30] er, the XDG stuff is generally the same [17:31] So although OO.o is in Ubuntu, Kubuntu and netbook remix to access it they all use slightly different methods [17:32] mid uses next to no menus at all [17:32] would be includes and meta information enough? [17:32] like #common- #ubuntu- [17:32] in kde i open the kmenu, click applications, click office, and pick one. in gnome i open the applications menu, click office, and pick one [17:33] I'm weary of making the wiki mark-up too complex [17:33] we'll always run into quirks that we need to account for [17:34] can we write a page for each of Kubuntu, UNR etc to explain the differences in that flavour [17:34] and if you use the older gnome menu instead of the gnome menu bar, its exactly the same as using the kmenu [17:34] (but not as pretty) [17:34] one of the early 'test cases' for a Kubuntu could the be 'read this page' [17:35] actually, gnome's old menu is the same as xfce's menu is the same as the old kmenu [17:36] maco: but the differences need to be obvious to the read who is following the instructions so the difference become a pain in the arse [17:36] davmor2: the names of the sections do not change from desktop to desktop [17:36] davmor2: the only difference is whether you need to open the menu before you go to Applications or not [17:37] maco: mid has no menu [17:37] that can be fixed with "go to your main menu and click applications..." [17:37] davmor2: fair enough. but for the other 3 they're the same [17:38] heno: that's possible [17:38] davmor2: ok, let's talk this through on the call tomorrow [17:38] okay :) [17:39] [TOPIC] regression review - sbeattie [17:39] New Topic: regression review - sbeattie [17:39] A few things: [17:39] I updated the page at http://qa.ubuntu.com/reports/regression/regression_tracker.html to use some of the lp css/js goo, so the tables are all sortable now. === calc_ is now known as calc [17:40] nice! [17:40] Oooo, pretty [17:40] the regression-potential bugs need a little bit of love [17:40] very pretty [17:40] neat! [17:41] yeah, the layout's a bit wonky still, but it's an improvement. [17:41] nice :) [17:41] ogasawara: is https://edge.bugs.launchpad.net/ubuntu/+source/linux/+bug/327431 on your radar? Looks like there may have been a regression in the last hardy update re wpa/hidden ssid/iwl3945. [17:41] Ubuntu bug 327431 in linux "iwl3945 cannot connect to hidden ssid WPA enterprise with Hardy 2.6.24-23 - Regression" [Undecided,New] [17:42] oh, I also added the assignee to that page so we could see if a bug's already on someone's radar. [17:43] sbeattie: thanks, hadn't seen it yet [17:43] sbeattie: I raised a couple regression at the kernel team meeting yesterday [17:43] yeah, I read scrollback, but I didn't see that particular issue mentioned. [17:45] IIRC, we'd agreed we'd start assigning regression bugs to the teams to get them on their radar, is that correct? [17:45] sbeattie: right [17:45] the correct link is https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/327431 btw [17:45] Ubuntu bug 327431 in linux "iwl3945 cannot connect to hidden ssid WPA enterprise with Hardy 2.6.24-23 - Regression" [Undecided,New] [17:46] both seem to work for the bot but not FF (?) [17:46] heno: yeah, that was a manual fixup tyop on my part. [17:47] I'll walk through and assign bugs later today, may need some help figuring out which teams to assign to. === asac_ is now known as asac [17:47] (unless someone else would like to take that task) [17:47] sbeattie: ok, please set the importance and state of these too [17:47] okay. [17:47] bugs we touch should have those set [17:48] thanks [17:48] let's do a lightning round table [17:48] * heno starts [17:48] I spent the past 4 days in London at the management sprint. [17:48] Highlight is that the other engineering team leads committed to use the team-assignment lists to track their bugs. [17:49] We will aim to eventually move all Triaged bugs to those lists or to flag them as not a resource priority for Canonical. [17:49] [done] [17:50] let's each prepare a few round table points for these meetings [17:50] we'd esp. like to hear from non-Canonical folks! [17:51] anyone wish to add something at 0-minutes notice? ;) [17:51] heno: a couple of SRU items: [17:51] first, thanks to Rolf Leggewie (r0lf on launchpad) for doing a bunch of verifications, it's very much appreciated! [17:51] second: It'd be great if people with a Samsung NC10 Netbook, Dell Latitude D810 laptop, or the HSUPA modem found in Acer Aspire One could test the hal-info update in hardy-proposed. [17:52] [end] [17:52] rock r0lf! [17:52] davmor2: do you have the Acer Aspire One? [17:52] Yeap [17:53] I want to give a shout out to michele mangili who's done an amazing job helping close out kernel bugs [17:53] sbeattie: can you walk davmor2 thought testing that SRU? [17:53] heh, sure. :-) [17:54] any other topics? [17:54] can i point out that if any of you have authored patches for ubuntu, its a good idea to check with upstream to see if they want them too? [17:55] that's esp. true one bugs with upstream tasks [17:56] jcastro: do we have guidelines on doing that? [17:56] I think we often leave it to the next sync [17:56] which may not be so useful for upstream [17:56] i can say it works much better to send the patch to a -devel mailing list than to set it on a bugtracker [17:57] maco: what upstreams do you have most experience with? [17:57] (preferences often vary) [17:58] heno: gnome and alsa. with gnome i've pinged maintainers on IRC to tell them "there's a patch here" but with alsa i cant find anyone on irc so the mailing list (which requires subscription) is what i used after waiting about 2 months of it being ignored on the bugtracker [17:58] hello [17:58] perhaps we should make it part of the patch sponsorship process? [17:59] i think "new bug with patch" and "new bug" dont register any differently in inboxes, but a "live" notification of a patch from a human (not a bugtracker bot relaying things) helps speed things along [18:00] which is why jcastro wants us to get involved with communicating with upstream, right? [18:01] indeed [18:02] speaking of Gnome upstream :) [18:03] jcastro: can you speak with dhobach about whether we can fit upstreaming into the patch sponsorship process? [18:03] any other topics? [18:03] (briefly) [18:04] it's normally discussed as part of sponsorship [18:05] so it's the non-sponsored patches that are slower to get upstream? [18:05] let's wrap up [18:05] Spread the word about http://qa.ubuntu.com/reports/needs-packaging/needs-packaging-popularity.html [18:06] now with new bug-hotness hotness! [18:06] #endmeeting [18:06] Meeting finished at 12:06. [18:12] bye === thekorn_ is now known as thekorn === paul_ is now known as Elbrus === merriam_ is now known as merriam === _neversfelde is now known as neversfelde === kirkland` is now known as kirkland