[00:03] _ === Javi is now known as Alejandro-_- [00:03] hello === McPeter_ is now known as McPeter [08:22] good morning all! [08:23] ara: good morning! :-) [08:24] morning primes2h [08:26] ara: I see that now there are LoCo team testing added to HOF. [08:27] primes2h, yes, I will announce it today with a blog post :) [08:28] But last week end I found out that we (Italian Testing Team) weren't added to ubuntu-it yet (an omission), so we did it 8 of October. [08:29] ara: all tests done before that date are not present (e.g. earlier builds) [08:29] primes2h, so, from now on you will be there in the top chart! :) [08:31] ara: I hope to ;-) Is it possible to retrieve those tests about the Final Release? here they are http://wiki.ubuntu-it.org/GruppoTest/Casi/Svolti [08:31] primes2h, I am afraid not, it is an automated script [08:37] ara: pity, it took just 43 out of 74 tests. === yofel_ is now known as yofel === Claudinux_ is now known as Claudinux [09:51] Greetings [09:51] Can i help with something [10:08] anything to work on ?? [11:19] greetings again [11:27] hey Sulumar [11:27] Hi ara [11:28] morning all [11:28] Sulumar, right now things are going to go a bit slower, as we just released Ubuntu 10.10 [11:28] noticed that [11:28] Sulumar, but if you have a laptop, you could work on the Laptop testing program [11:28] Sulumar, or SRU testing [11:28] out of luck laptop is broken [11:28] http://wiki.ubuntu.com/StableReleaseUpdates [11:29] SRU is a great way to help [11:29] you can ask jibel if you have any questions [11:30] Ill fill the optional testing case for vmware first and than take a look at sru [11:30] Hi Sulamar [11:30] Greetings jibel [11:31] We just opened maverick-proposed and Stable Releases updates is a great way to help. [11:31] let me read that wiki page first [11:32] If you can help with stable releases testing you should read https://wiki.ubuntu.com/QATeam/PerformingSRUVerification [11:33] The list of packages to test is available at http://people.canonical.com/~ubuntu-archive/pending-sru.html [11:34] ok, just give me the time to check [11:39] Sulumar, some tests requires a specific hardware or setup but other are more easy to test in a standard desktop environment. [11:39] for example, bug 654981 simply needs to use empathy and ensure that there is no regression [11:39] Launchpad bug 654981 in empathy (Ubuntu Maverick) (and 1 other project) "SRU empathy to 2.32.0.1 in maverick (affects: 2) (heat: 16)" [Low,Fix committed] https://launchpad.net/bugs/654981 [11:40] or bug 657371 for netbook users, that you can use the guest session. [11:40] Launchpad bug 657371 in netbook-meta (Ubuntu Maverick) (and 4 other projects) "Ubuntu Netbook Edition maverick doesn't have a guest session (affects: 1) (heat: 10)" [Medium,Triaged] https://launchpad.net/bugs/657371 [11:41] The most important thing is to be sure that no regression is introduced and having a look at the patch can give some guidance. [11:41] Um, no. [11:41] The most important thing is verifying that one can reproduce the bug before, and can't after. no regressions is #2. [11:42] * persia has seen a few -proposed uploads that didn't actually solve the problem, and very much hopes people are checking that. [11:46] ok but for now i only have a vmware as platforme to test on [11:46] persia, I kindly disagree. Users expect a reliable system, and any fix introducing a regression will be rejected. I agree that the patch proposed in a SRU must fix the original issue though :-) [11:47] Sulumar, most of the testing can be done in a VM. [11:47] good [11:47] count me in [11:48] ill start as soon as i can confirm the automated install for 10.10 in vmware [11:48] Sulumar, thanks for your help, that's much appreciated. [11:48] jibel, I agree with your intent. My priority comes because it's easier to prove a positive than prove a negative, so one can fail insufficient fixes faster than one can verify lack of regressions. I'm more than happy to disagree about implementation if you prefer, as I'm confident there's no harm in multiple approaches towards the same goal. [11:53] persia, right, we also often reject insufficient fixes too. but because it's /easier/ to prove a positive, we - as sru testers - must be paranoid about regressions. [11:54] Oh, I'm all in favour of paranoia :) I just tend to execute the TEST CASE as a first step when beginning the verification. [11:55] persia, or prior to that, write the test case :-) [11:55] Hmm. I tend to do that wearing a developer hat, rather than a tester hat. Maybe I'm creating a false distinction. [11:56] ara, Woohoo: 100% image and mandatory test case coverage \o/ [11:56] jibel, of course! :) [12:00] persia, because you're conscientious, but not every dev do that. just go through http://people.canonical.com/~ubuntu-archive/pending-sru.html and count real the test cases. That usually don't pass the sru sponsonship process though [12:02] Few members of ~ubuntu-dev need sponsorship, so that filter doesn't help as much as we'd like. [12:02] indeed [12:03] Maybe it's worth petitioning the SRU team to not accept anything into -proposed until it has a TEST CASE? I think it's unsafe to expect the testing team to both write and execute the tests for a bug understood by the developer: we may end up testing the wrong thing. [12:07] I completely agree. If such SRU reach the testing stage, I usually reject them when the test is non obvious. [12:09] * jibel -> lunch [12:12] the advantages of a vm i can work on a clean system without touching my production [13:07] Sulumar, I use 1 VM per stable release, with one clean snapshot. This way you can test on a clean system, and when you're done with testing, you restore the snapshot. [13:11] * persia uses schroot for most testing (only works for stuff that doesn't require X/kernel/udev/etc. concerns) [13:28] I made a Template from witch i make linked clones [13:28] 1 per testing case if needed [13:29] so i can trash them if they get stuck === rararimaro is now known as mevolu [13:53] ara, do you think we could have 2 set of test cases for iso testing, one for LTS and one for the dev release ? [13:54] jibel, yes, I think that's possible, we need to have a special install of the iso tracker as well [13:54] like lts.qa.ubuntu.com [13:56] ara, could we do that before the next point release of lucid and work on the test cases for natty separately ? [13:57] jibel, when is 10.04.2 due to? [13:57] ara, 2011-01-27 [13:57] jibel, of course, that's possible. We can work on it together during UDS, is that OK? [13:58] ara, okay. thanks. [13:58] jibel, added to my UDS TODO list ;-) [13:59] jibel, what plans do you have for UDS? [13:59] jibel, or, what plans do you have for Natty? [14:00] ara, For Natty ? nothing I'm working on stable releases :-P [14:00] jibel, hehehe, for the Natty cycle, I mean/meant [14:01] ara, related to the test cases above or from a more general point of view ? [14:01] generally speaking [14:03] ara, my main concern are regressions, we had a few during maverick cycle, and like to be able to design a tool to match the incoming reports with events like a new package published to -update or unusual flow of incoming reports. [14:03] ara, I'm working on a prototype. [14:03] jibel, that sounds great :) [14:04] ara, the second thing would be to have a common overview of what's happening in the stable releases. [14:04] ara, currently the dev teams have there own lists, then we have the pending srus and the regression tracker [14:05] ara, I think it would be an improvement to have one common tool. [14:05] jibel, indeed, it is always confusing to have several places you have to look to [14:06] ara, for instance you sent a link to the tool used by the server team, but the desktop team use something different. [14:07] ara, you don't even known if both team use the same selection criteria to identify the packages to work on. [14:19] do you know how to integrate Thunderbird with Maveriks messaging menu [14:19] ?? [14:25] Sulumar, I haven't tried it yet, but: http://www.omgubuntu.co.uk/2010/05/how-to-add-thunderbird-to-the-ubuntu-messaging-menu/ === mevolu_ is now known as mevolu [14:26] allready got that but it doesent seem to work === pace_t_zulu_ is now known as pace_t_zulu === xfaf is now known as zul === Claudinux_ is now known as Claudinux