[08:11] <rickspencer3> jibel_, sorry man, but https://jenkins.qa.ubuntu.com/view/Precise/\
[08:16] <jibel_> rickspencer3, morning. I'm on it. it's new problem
[08:16] <rickspencer3> thanks jibel_
[08:16] <rickspencer3> jibel_, is it bugs in the ISOs or a problem in the lab?
[08:17] <jibel_> rickspencer3, something with openoffice: "Error: update-openoffice-dicts not present or executable. Missing dependency on dictionaries-common?"
[08:17] <jibel_> I'll file a bug
[08:17] <rickspencer3> wait
[08:17] <rickspencer3> 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] <rickspencer3> :)
[08:17] <rickspencer3> that's great news
[08:17] <rickspencer3> great job!
[08:19] <jibel_> thanks :)
[08:23] <jibel_> 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] <rickspencer3> thanks jibel_
[08:25] <rickspencer3> jibel_, sorry to bug you, when you get a moment, can you paste me the bug # for that kernel bug?
[08:26] <jibel_> rickspencer3, bug 894768
[08:26] <ubot4> 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] <rickspencer3> thank you jibel_
[08:46] <jibel> 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] <alourie> good morning
[09:01] <roignac> 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] <jibel> roignac, not in the version I'm using apparently. I only have 'Trigger even if the build is unstable '
[09:05] <jibel> roignac, I'm using jenkins 1.396. I'll look if it was introduced in a newer version. Thanks
[09:15] <roignac> 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] <jibel> roignac, I'll try that plugin. thanks again :)
[09:20] <roignac> np
[09:21] <roignac> jibel, btw - are there any tasks open for automated smoke tests? I', really eager to help
[09:44] <jibel> gema, ^ where is this wiki page you set up with QA tasks ?
[09:44] <jibel> gema, is there anything for automated smoke testing ?
[09:44] <gema> jibel: indeed, just a sec
[09:45] <gema> roignac: https://wiki.ubuntu.com/QATeam/TasksPrecise
[09:46] <gema> roignac: the smoke tests task is the first one
[09:46] <roignac> thanks, guys!
[09:46] <gema> thank you!
[09:47] <gema> 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] <gema> roignac: yesterday's meeting log: https://wiki.ubuntu.com/QATeam/Meetings/QA/20111207
[09:48] <roignac> oh, thanks, had to miss it due to timezones =/
[09:48] <gema> roignac: no probs, where are you based?
[09:48] <roignac> Belarus
[09:48] <gema> roignac: so your best bet is probably coordinating by email
[09:49] <gema> or let me know what you want to do and I will let him know
[09:49] <gema> I am based in the uk
[09:49] <roignac> yeah, I've been silently lurking the ubuntu-testing mailing list for a while and triaging bugs
[09:49] <gema> roignac: cool!
[09:49] <roignac> so mailing list seems like the best way to coordinate the team
[09:52] <roignac> there is also one thing not really clear to me - why daily build testing generates no reports?
[09:52] <roignac> is there any way to find out why the build has failed?
[10:09] <roignac> jibel: is there any way to find out why precise autotest has failed? Maybe a test report should be generated?
[10:10] <jibel> 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] <roignac> ok, thanks
[10:52] <gema> roignac: you can read the instructions on how to interpret jenkins results here: https://wiki.ubuntu.com/QATeam/AutomatedTesting
[10:52] <gema> roignac: they are not fully finished but it is a good starting point
[10:54] <gema> btw, alourie good morning!
[10:54] <alourie> hi gema
[10:54] <roignac> gema, thanks, console output now makes a bit sense to me
[10:54] <alourie> how are you doing?
[10:55] <gema> roignac: good, I am in the same boat, trying to get used to it
[10:55] <gema> alourie: good, busy day (it's Friday for me) and you?
[10:55] <alourie> gema: wow, details about jenkins!! I think it should be more "findable"
[10:55] <alourie> gema: Friday?
[10:55] <roignac> 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] <gema> alourie: we are still working on it
[10:55] <gema> alourie: we'll make them public as soon as they are "finished"
[10:56] <alourie> gema: Friday, as in "day off" ?
[10:56] <gema> alourie: yep
[10:56] <alourie> ah
[10:56] <alourie> so you're not really here, working :-0
[10:56] <gema> alourie: I am working, what do you mean? :D
[10:57] <alourie> gema: what does Friday mean then ?
[10:57] <gema> alourie: that I am taking tomorrow off, so today is my friday :D
[10:57] <alourie> ah
[10:57] <alourie> ok
[10:57] <alourie> for me Thursday is always like that :-)
[10:57] <alourie> we don't work Fridays
[10:57] <gema> alourie: lucky you :D
[10:58] <alourie> nah
[10:58] <alourie> you don't work Sundays though :-)
[10:58] <gema> roignac: there are no expected results for actions 1, 2 and 3 in that test case
[10:58] <alourie> so it's balanced
[10:58] <roignac> gema, good point!
[10:59] <gema> 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] <gema> roignac: the idea of the template is having an expected result per action, even if it seems obvious
[11:00] <alourie> gema: I started working on wiki updates
[11:00] <gema> 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] <roignac> gema, ok, fixed. Maybe, wiki testcases should be moved to some specific category, like TestCasesRewritten?
[11:02] <gema> 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] <alourie> gema: maybe we can have an online spreadsheet for that?
[11:02] <alourie> such as google?
[11:02] <gema> roignac: I am going to update the spreadsheet with "link to original test case or similar"
[11:02] <alourie> or etherpad?
[11:02] <gema> alourie: google doc sounds good
[11:02] <gema> lemme put it in place
[11:02] <roignac> yeah, +1 for google docs for spreadsheet
[11:02] <alourie> great
[11:03] <alourie> so we see the work going on
[11:03] <alourie> and don't duplicate efforts
[11:03] <gema> sounds good, I will do, hold on
[11:03] <roignac> 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] <roignac> In this case the same cases could be used for automation - without any translating?
[11:04] <alourie> roignac: I wouldn't be so sure about that
[11:04] <alourie> most cases that we have are complex sets of actions
[11:05] <alourie> but yes, I'd like them to be automated...
[11:05] <roignac> 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] <alourie> roignac: sure thing
[11:06] <alourie> gema: wanna peak into the new wiki? :-)
[11:06] <roignac> alourie, yep, i've already tried integrating Mago with Freshen and this worked pretty fine
[11:06] <alourie> roignac: Freshen?
[11:06] <gema> roignac: feel free to add columns if you think we are missing something
[11:07] <roignac> alourie, check out https://github.com/rlisagor/freshen
[11:08] <gema> 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] <gema> perfect
[11:10] <roignac> yep, works
[11:10] <gema> cool, although I only see one action
[11:10] <gema> can you add all the actions in one cell?
[11:11] <alourie> great
[11:11] <alourie> it seems to work for me too
[11:11] <roignac> gema, ok, staright copy-paste didn't work
[11:11] <gema> ok, so I will send the link to the list
[11:11] <gema> yep, roignac , sorry, we'll need to figure that out
[11:12] <alourie> roignac: I think right-click and paste should
[11:12] <gema> excellent, that works
[11:13] <alourie> gema: take a look at this: https://wiki.ubuntu.com/AlexLourie/QAWikiNew
[11:13] <gema> alourie: reading
[11:14] <gema> very good, alourie , we were thinking of relaxing the rules to join the ubuntu-qa team
[11:15] <gema> alourie: something like being involved in current testing activities and explaining why you are interested on them, or similar
[11:15] <alourie> gema: sure, that's just a cleaned-up page
[11:15] <alourie> and new icons :-)
[11:16] <alourie> and, I fixed the "roadmap" link, need to fix Contacts page too
[11:16] <gema> alourie: I am so bad with icons x)
[11:16] <alourie> gema: it's a stock stuff from design.u.com
[11:16] <gema> alourie: very good, we need to link the tasks and the important bits on the wiki
[11:16] <alourie> do you like it?
[11:16] <alourie> yes, I think tasks should have their own section
[11:16] <gema> yep, I like the design indeed
[11:17] <alourie> great. Do you think they are appropriate?
[11:17] <gema> alourie: and a link to the spreadsheet, well, all that's going on
[11:17] <alourie> of course
[11:17] <gema> yep, you haven't found one for the schedule , have you?
[11:17] <alourie> no :-)
[11:17] <alourie> I tried to create one, but I'm not a graphics wiz
[11:17] <alourie> maybe we'll ask someone
[11:18] <gema> alourie: cool, we can use the old one if you want
[11:18] <gema> alourie: a calendar seems appropriate
[11:18] <gema> but it is not orange
[11:18] <alourie> 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] <gema> alourie: the roadmap and contacts ones come up mixed up with the links
[11:18] <alourie> like, from Gnome1 era :-)
[11:18] <gema> alourie: ok!
[11:21] <jibel> gema, I'm reading https://wiki.ubuntu.com/QATeam/AutomatedTesting/TestingTypeAndBugTracking
[11:21] <jibel> what's the tag for bugs found during normal use of a system (i.e not a specific testing activity) ?
[11:24] <alourie> gema: I've updated the task list, so we're INPROGRESS with couple more itemas
[11:24] <gema> jibel: I am thinking
[11:25] <gema> jibel: we could add a tag for that qa-normal-usage ?
[11:38] <brendand> gema - do you mean you will remove the one i added?
[11:39] <gema> brendand: sorry, my english was ultracomplicated
[11:39] <gema> I am trying to send a second email now
[11:40] <gema> I don't think we should do that because there may be many reviewers
[11:40] <brendand> gema - i think the author should be able to follow up with whoever reviewed the test case, don't you?
[11:40] <brendand> gema - that could be the case, yes.
[11:40] <gema> 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] <gema> but I don't think adding all the comments to the spreadsheet works, since there may be many people commenting
[11:41] <gema> some comments may be relevant some others may not
[11:41] <gema> it is up to the author to decide, in my opinion
[11:41] <brendand> gema - maybe we should use gdocs comment feature?
[11:41] <gema> but they should be sent to the list so that we can keep track of the process
[11:42] <gema> brendand: I thought that only worked with text docs
[11:43] <gema> brendand: we could use google docs comments, yes
[11:43] <brendand> gema - nope, see the spreadsheet now. in which case we don't need the review comments field either actually
[11:43] <brendand> gema - i think emailing comments to the mailing list may generate a large volume of traffic
[11:43] <gema> brendand: that comment feature works good
[11:44] <gema> brendand: I didn't realise
[11:44] <gema> brendand: let's use it
[11:44] <gema> brendand: so we can remove the review comments column one or rename it to Author's answers
[11:44] <brendand> gema - i'm sending a mini user guide to the list
[11:45] <gema> brendand: sounds good
[11:46] <gema> btw, thanks roignac for working tirelessly through our rumbling
[11:47] <brendand> roignac - the help is very much appreciated
[11:47] <brendand> gema - can you add a comment somewhere so i can check the best way to respond?
[11:47] <roignac> my pleasure, guys
[11:47] <gema> brendand: row 8
[11:50] <gema> brendand: you got it, in your test case
[11:53] <gema> 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] <brendand> gema - ah. let me try that
[11:53] <gema> brendand: and it has a timestamp too
[11:53] <brendand> gema - yeah, better
[11:54] <gema> brendand: ok, we got it, I think
[12:01] <brendand> gema - hmm, one issue is that usernames are only shown for logged in users
[12:04] <gema> brendand: let's make sure they put their launchpad ids if they are not authenticated, then
[12:04] <brendand> gema - i'll send that mail
[12:05] <gema> thanks brendand
[12:09] <alourie> if only it was possible to make people login to edit this document...
[12:09] <alourie> but we don't want to complicate this too much...
[12:13] <brendand> alourie - some people may be coincidentally logged in (a lot of people use gmail!)
[12:14] <brendand> any other method we might use runs just as much risk of having people comment without providing a way to respond
[12:14] <brendand> (except a test case management tool of course ;) )
[12:15] <brendand> 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] <gema> alourie: I didn't want to exclude from this people that do not have a google account
[12:16] <brendand> anyways, got to go have lunch. see you guys!
[12:16] <gema> bye brendand
[12:18] <alourie> yea, sure
[12:18] <alourie> that's what I said, no overcomplication
[12:56] <alourie> gema: I got temporary better schedule pictogram :-)
[12:56] <alourie> gema: https://wiki.ubuntu.com/AlexLourie/QAWikiNew
[12:57] <alourie> 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] <gema> alourie: nothing wrong with 19th, but we could put a 32nd just for fun
[14:20] <alourie> gema: :-D
[14:54] <gema> alourie: add the category field to the spreadsheet
[14:54] <gema> alourie: sounds like a good idea
[14:55] <stgraber> 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] <gema> 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] <stgraber> 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] <jibel> stgraber, I think jenkins for dailies is enough since there is no "build" for upgrades and its constantly changing over the day
[14:59] <alourie> gema: ok, but what categories there are? How would we like them to be?
[14:59] <gema> alourie: that's something that needs figuring out
[14:59] <stgraber> jibel: not sure what you mean by "jenkins for dailies is enough".
[15:00] <alourie> ok, so let's brainstorm a little on the list, see what's important and what's not
[15:00] <stgraber> 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] <alourie> gema: get some feedback, etc
[15:01] <stgraber> 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] <skaet> stgraber, we probably want to flush the results with each set of images published.
[15:02] <skaet> the /history will be able to let us look over time at what the results are.
[15:02] <jibel> stgraber, you're right
[15:02] <jibel> skaet, do you mean every day ?
[15:03] <jibel> or every milestone ?
[15:03] <skaet> jibel, every day, so that the flavors can see if something's gone wrong.
[15:04] <stgraber> 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] <skaet> hmm,  what else do you suggest?
[15:05] <stgraber> on the other hand, once per milestone would show way too many results, maybe flushing once a week?
[15:05] <skaet> stgraber,  ok,  lets try that and evolve from there?
[15:06] <jibel> 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] <gema> stgraber, skaet : what results do you want to flush, the ones from daily iso testing ? from the smoke testing?
[15:06] <jibel> gema, daily upgrade testing
[15:06] <skaet> gema,  flavor upgrade testing results
[15:07] <gema> ahh, ok, I don't know anything about those, I will keep listening :D
[15:07] <jibel> stgraber, skaet flushing once a week is fine for me.
[15:09] <stgraber> 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] <stgraber> skaet: what's the usual UTC time for the deadline on the Thursdays? 21:00?
[15:10] <stgraber> skaet: I guess it'd make sense to flush at the same time our freezes usually start
[15:10] <skaet> stgraber,  our freezes usually start on monday at 21:00 for milestones.
[15:11] <skaet> however,  might make sense to do it on friday afternoon?  so its results are visible for the weekend?
[15:12] <stgraber> probably a good idea indeed, so people have a todo list of things to fix on Monday before the freeze
[15:12] <skaet> 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] <stgraber> I'll make that 21:00 UTC on Friday
[15:12] <skaet> sounds good.   we can adjust from there.
[15:12] <skaet> if needed.
[15:13] <stgraber> 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] <jibel> stgraber, do what you think your script should do
[15:22] <stgraber> jibel: ok :)
[15:28] <gema> jibel: for the default installation tests , which file system do we use? ext3?
[15:29] <gema> jibel: found it, partition #1 of Virtual disk 1 (vda) as ext4