[08:11] jibel_, sorry man, but https://jenkins.qa.ubuntu.com/view/Precise/\ [08:16] rickspencer3, morning. I'm on it. it's new problem [08:16] thanks jibel_ [08:16] jibel_, is it bugs in the ISOs or a problem in the lab? [08:17] rickspencer3, something with openoffice: "Error: update-openoffice-dicts not present or executable. Missing dependency on dictionaries-common?" [08:17] I'll file a bug [08:17] wait [08:17] jibel_, so you are telling me that an automated test found a serious bug and it is getting fixed before anyone gets broken? [08:17] :) [08:17] that's great news [08:17] great job! [08:19] thanks :) [08:23] rickspencer3, the kernel bug is fixed and server jobs are back to normal. We'll have the confirmation with desktop images once they'll get respin. [08:23] thanks jibel_ [08:25] jibel_, sorry to bug you, when you get a moment, can you paste me the bug # for that kernel bug? [08:26] rickspencer3, bug 894768 [08:26] Launchpad bug 894768 in linux (Ubuntu Precise) (and 1 other project) "Installation randomly fails with: File "/usr/lib/ubiquity/ubiquity/install_misc.py", line 621, in copy_file targetfh.write(buf) IOError: [Errno 22] Invalid argument (affects: 31) (dups: 30) (heat: 276)" [High,Fix released] https://launchpad.net/bugs/894768 [08:26] thank you jibel_ === jibel_ is now known as jibel [08:46] jamespage, do you know a way with jenkins to trigger a post-build job inconditionally i.e even if the main job fails or is there any plugin you'd know that would do that ? [08:52] good morning [09:01] jibel: there should be a config option 'Build other projects - Trigger even if the build fails' - see http://blog.akquinet.de/2011/11/09/building-pipelines-by-linking-jenkins-jobs/ [09:04] roignac, not in the version I'm using apparently. I only have 'Trigger even if the build is unstable ' [09:05] roignac, I'm using jenkins 1.396. I'll look if it was introduced in a newer version. Thanks [09:15] jibel, you may also try https://wiki.jenkins-ci.org/display/JENKINS/Downstream-Ext+Plugin - this should provide the same functionality without updating jenkins [09:20] roignac, I'll try that plugin. thanks again :) [09:20] np [09:21] jibel, btw - are there any tasks open for automated smoke tests? I', really eager to help [09:44] gema, ^ where is this wiki page you set up with QA tasks ? [09:44] gema, is there anything for automated smoke testing ? [09:44] jibel: indeed, just a sec [09:45] roignac: https://wiki.ubuntu.com/QATeam/TasksPrecise [09:46] roignac: the smoke tests task is the first one [09:46] thanks, guys! [09:46] thank you! [09:47] roignac: are you on the list? yesterday's logs of the meeting have the latest news from Aaron, who is working a lot on that task, you may want to talk to him whenver he comes online [09:47] roignac: yesterday's meeting log: https://wiki.ubuntu.com/QATeam/Meetings/QA/20111207 [09:48] oh, thanks, had to miss it due to timezones =/ [09:48] roignac: no probs, where are you based? [09:48] Belarus [09:48] roignac: so your best bet is probably coordinating by email [09:49] or let me know what you want to do and I will let him know [09:49] I am based in the uk [09:49] yeah, I've been silently lurking the ubuntu-testing mailing list for a while and triaging bugs [09:49] roignac: cool! [09:49] so mailing list seems like the best way to coordinate the team [09:52] there is also one thing not really clear to me - why daily build testing generates no reports? [09:52] is there any way to find out why the build has failed? [10:09] jibel: is there any way to find out why precise autotest has failed? Maybe a test report should be generated? [10:10] roignac, not yet. It's one of the task of this blueprint https://blueprints.launchpad.net/ubuntu/+spec/other-p-builds-smoke-testing [10:10] ok, thanks [10:52] roignac: you can read the instructions on how to interpret jenkins results here: https://wiki.ubuntu.com/QATeam/AutomatedTesting [10:52] roignac: they are not fully finished but it is a good starting point [10:54] btw, alourie good morning! [10:54] hi gema [10:54] gema, thanks, console output now makes a bit sense to me [10:54] how are you doing? [10:55] roignac: good, I am in the same boat, trying to get used to it [10:55] alourie: good, busy day (it's Friday for me) and you? [10:55] gema: wow, details about jenkins!! I think it should be more "findable" [10:55] gema: Friday? [10:55] gema, jibel, I've started re-writing cases - could you please review first case for nautilus in the wiki? http://testcases.qa.ubuntu.com/Applications/Nautilus [10:55] alourie: we are still working on it [10:55] alourie: we'll make them public as soon as they are "finished" [10:56] gema: Friday, as in "day off" ? [10:56] alourie: yep [10:56] ah [10:56] so you're not really here, working :-0 [10:56] alourie: I am working, what do you mean? :D [10:57] gema: what does Friday mean then ? [10:57] alourie: that I am taking tomorrow off, so today is my friday :D [10:57] ah [10:57] ok [10:57] for me Thursday is always like that :-) [10:57] we don't work Fridays [10:57] alourie: lucky you :D [10:58] nah [10:58] you don't work Sundays though :-) [10:58] roignac: there are no expected results for actions 1, 2 and 3 in that test case [10:58] so it's balanced [10:58] gema, good point! [10:59] roignac: we were aiming at collecting test cases on a spreadsheet that we can later move to the new test case management system, so if you prefer to fix the wiki, please keep a list of test cases ids and pages so that we don't miss that work [10:59] roignac: the idea of the template is having an expected result per action, even if it seems obvious [11:00] gema: I started working on wiki updates [11:00] roignac: for instance for action 1, expected result would be 1. The Home Folder opens and shows the files contained in that directory [11:00] gema, ok, fixed. Maybe, wiki testcases should be moved to some specific category, like TestCasesRewritten? [11:02] roignac, can you make a copy of the ones you fix in a spreadsheet with your name so that we can have everyone's work in one place and easy to manage? [11:02] gema: maybe we can have an online spreadsheet for that? [11:02] such as google? [11:02] roignac: I am going to update the spreadsheet with "link to original test case or similar" [11:02] or etherpad? [11:02] alourie: google doc sounds good [11:02] lemme put it in place [11:02] yeah, +1 for google docs for spreadsheet [11:02] great [11:03] so we see the work going on [11:03] and don't duplicate efforts [11:03] sounds good, I will do, hold on [11:03] another though - maybe we should use Gherkin format for testcase? See http://en.wikipedia.org/wiki/Behavior_Driven_Development#Application_examples_in_the_Gherkin_language [11:04] In this case the same cases could be used for automation - without any translating? [11:04] roignac: I wouldn't be so sure about that [11:04] most cases that we have are complex sets of actions [11:05] but yes, I'd like them to be automated... [11:05] OK, I guess, I'll post this to ubuntu-testing mailing list with some real-world examples [11:05] * alourie hopes someone remembers Mago here... [11:05] roignac: sure thing [11:06] gema: wanna peak into the new wiki? :-) [11:06] alourie, yep, i've already tried integrating Mago with Freshen and this worked pretty fine [11:06] roignac: Freshen? [11:06] roignac: feel free to add columns if you think we are missing something [11:07] alourie, check out https://github.com/rlisagor/freshen [11:08] roignac: see if you can access: https://docs.google.com/a/canonical.com/spreadsheet/ccc?key=0AgtV30nnv18edFQzNVB4S2duOWNOT05zaHo3S0pNekE&authkey=CMTAtuoI&hl=en_US#gid=0 [11:09] perfect [11:10] yep, works [11:10] cool, although I only see one action [11:10] can you add all the actions in one cell? [11:11] great [11:11] it seems to work for me too [11:11] gema, ok, staright copy-paste didn't work [11:11] ok, so I will send the link to the list [11:11] yep, roignac , sorry, we'll need to figure that out [11:12] roignac: I think right-click and paste should [11:12] excellent, that works [11:13] gema: take a look at this: https://wiki.ubuntu.com/AlexLourie/QAWikiNew [11:13] alourie: reading [11:14] very good, alourie , we were thinking of relaxing the rules to join the ubuntu-qa team [11:15] alourie: something like being involved in current testing activities and explaining why you are interested on them, or similar [11:15] gema: sure, that's just a cleaned-up page [11:15] and new icons :-) [11:16] and, I fixed the "roadmap" link, need to fix Contacts page too [11:16] alourie: I am so bad with icons x) [11:16] gema: it's a stock stuff from design.u.com [11:16] alourie: very good, we need to link the tasks and the important bits on the wiki [11:16] do you like it? [11:16] yes, I think tasks should have their own section [11:16] yep, I like the design indeed [11:17] great. Do you think they are appropriate? [11:17] alourie: and a link to the spreadsheet, well, all that's going on [11:17] of course [11:17] yep, you haven't found one for the schedule , have you? [11:17] no :-) [11:17] I tried to create one, but I'm not a graphics wiz [11:17] maybe we'll ask someone [11:18] alourie: cool, we can use the old one if you want [11:18] alourie: a calendar seems appropriate [11:18] but it is not orange [11:18] Nah, it's too '90...I'll cleanup a bit more and post it to the list, so others could give us feedback [11:18] alourie: the roadmap and contacts ones come up mixed up with the links [11:18] like, from Gnome1 era :-) [11:18] alourie: ok! [11:21] gema, I'm reading https://wiki.ubuntu.com/QATeam/AutomatedTesting/TestingTypeAndBugTracking [11:21] what's the tag for bugs found during normal use of a system (i.e not a specific testing activity) ? [11:24] gema: I've updated the task list, so we're INPROGRESS with couple more itemas === _salem is now known as salem_ [11:24] jibel: I am thinking [11:25] jibel: we could add a tag for that qa-normal-usage ? [11:38] gema - do you mean you will remove the one i added? [11:39] brendand: sorry, my english was ultracomplicated [11:39] I am trying to send a second email now [11:40] I don't think we should do that because there may be many reviewers [11:40] gema - i think the author should be able to follow up with whoever reviewed the test case, don't you? [11:40] gema - that could be the case, yes. [11:40] brendand: indeed, which is why I think the mailing list is better, many people can review and the autor can decide which comments to address and move them to the spreadsheet [11:41] but I don't think adding all the comments to the spreadsheet works, since there may be many people commenting [11:41] some comments may be relevant some others may not [11:41] it is up to the author to decide, in my opinion [11:41] gema - maybe we should use gdocs comment feature? [11:41] but they should be sent to the list so that we can keep track of the process [11:42] brendand: I thought that only worked with text docs [11:43] brendand: we could use google docs comments, yes [11:43] gema - nope, see the spreadsheet now. in which case we don't need the review comments field either actually [11:43] gema - i think emailing comments to the mailing list may generate a large volume of traffic [11:43] brendand: that comment feature works good [11:44] brendand: I didn't realise [11:44] brendand: let's use it [11:44] brendand: so we can remove the review comments column one or rename it to Author's answers [11:44] gema - i'm sending a mini user guide to the list [11:45] brendand: sounds good [11:46] btw, thanks roignac for working tirelessly through our rumbling [11:47] roignac - the help is very much appreciated [11:47] gema - can you add a comment somewhere so i can check the best way to respond? [11:47] my pleasure, guys [11:47] brendand: row 8 [11:50] brendand: you got it, in your test case [11:53] brendan, if you had clicked in "insert comment" your comment would be stacked on top of mine and it makes it more readable [11:53] gema - ah. let me try that [11:53] brendand: and it has a timestamp too [11:53] gema - yeah, better [11:54] brendand: ok, we got it, I think [12:01] gema - hmm, one issue is that usernames are only shown for logged in users [12:04] brendand: let's make sure they put their launchpad ids if they are not authenticated, then [12:04] gema - i'll send that mail [12:05] thanks brendand [12:09] if only it was possible to make people login to edit this document... [12:09] but we don't want to complicate this too much... [12:13] alourie - some people may be coincidentally logged in (a lot of people use gmail!) [12:14] any other method we might use runs just as much risk of having people comment without providing a way to respond [12:14] (except a test case management tool of course ;) ) [12:15] alourie - and it is *possible* to force people to log in, but i don't believe that's something we'd like to do. gema? [12:16] alourie: I didn't want to exclude from this people that do not have a google account [12:16] anyways, got to go have lunch. see you guys! [12:16] bye brendand [12:18] yea, sure [12:18] that's what I said, no overcomplication [12:56] gema: I got temporary better schedule pictogram :-) [12:56] gema: https://wiki.ubuntu.com/AlexLourie/QAWikiNew [12:57] also, I've been asking around in -design, and there's someone has an idea for schedule that doesn't point to 19th :-) [13:25] alourie: nothing wrong with 19th, but we could put a 32nd just for fun === yofel_ is now known as yofel [14:20] gema: :-D [14:54] alourie: add the category field to the spreadsheet [14:54] alourie: sounds like a good idea [14:55] jibel, skaet: I'll be pushing daily upgrade testing for the flavours to the tracker starting tonight/tomorrow, what should we do on the tracker side for that? [14:55] alourie: if you could add the category to the test cases that are already there, that'd be good, so that people learn how to use the field [14:55] jibel, skaet: Should we have a cron pushing a new version of all the upgrade products everyday to the daily milestone or have it based on some packages version or ... ? [14:57] stgraber, I think jenkins for dailies is enough since there is no "build" for upgrades and its constantly changing over the day [14:59] gema: ok, but what categories there are? How would we like them to be? [14:59] alourie: that's something that needs figuring out [14:59] jibel: not sure what you mean by "jenkins for dailies is enough". [15:00] ok, so let's brainstorm a little on the list, see what's important and what's not [15:00] jibel: if you mean not having upgrade results on the tracker for dailies, then I disagree as jenkins doesn't work for tests ran outside of QA and doesn't quite support manual upgrade testing [15:00] gema: get some feedback, etc [15:01] jibel: I think having them on the tracker makes sense as we can concentrate the results there (automated, manual, ...), the only question is how often we want to flush the results [15:01] stgraber, we probably want to flush the results with each set of images published. [15:02] the /history will be able to let us look over time at what the results are. [15:02] stgraber, you're right [15:02] skaet, do you mean every day ? [15:03] or every milestone ? [15:03] jibel, every day, so that the flavors can see if something's gone wrong. [15:04] the only problem I see with flushing once a day is the risk of flushing just a few minutes after the automatic upgrader posts the results [15:05] hmm, what else do you suggest? [15:05] on the other hand, once per milestone would show way too many results, maybe flushing once a week? [15:05] stgraber, ok, lets try that and evolve from there? [15:06] the thing is that upgrades are a moving target and there's no point in time when one can say "it's a stable build" excepted when the archive is frozen [15:06] stgraber, skaet : what results do you want to flush, the ones from daily iso testing ? from the smoke testing? [15:06] gema, daily upgrade testing [15:06] gema, flavor upgrade testing results [15:07] ahh, ok, I don't know anything about those, I will keep listening :D [15:07] stgraber, skaet flushing once a week is fine for me. [15:09] ok, I'll setup a cron pushing a new version of the upgrade products in the daily milestone once a week, we'll see how it goes. I think it'll be for the automated testing, might be a bit confusing for these doing manual testing. [15:09] skaet: what's the usual UTC time for the deadline on the Thursdays? 21:00? [15:10] skaet: I guess it'd make sense to flush at the same time our freezes usually start [15:10] stgraber, our freezes usually start on monday at 21:00 for milestones. [15:11] however, might make sense to do it on friday afternoon? so its results are visible for the weekend? [15:12] probably a good idea indeed, so people have a todo list of things to fix on Monday before the freeze [15:12] friday afternoon tends to be a bit of a quiet time - asia/australia and europe are off line, north america is winding down. [15:12] I'll make that 21:00 UTC on Friday [15:12] sounds good. we can adjust from there. [15:12] if needed. [15:13] jibel: should I have my script also push a new build for the non-flavour upgrade testing or do you want to handle that from your scripts? :) [15:20] stgraber, do what you think your script should do [15:22] jibel: ok :) [15:28] jibel: for the default installation tests , which file system do we use? ext3? [15:29] jibel: found it, partition #1 of Virtual disk 1 (vda) as ext4 === salem_ is now known as _salem === bladernr_ is now known as bladernr_afk