[04:47] <pitti> Good morning
[07:29] <jibel> good morning
[07:54] <DanChapman> Good Morning all :-)
[09:03] <pitti> asac: wrt. fixing the mediaplayer bugs> I noticed that the mediaplayer doesn't currently seem to work at all on mako; that might just be what the ap test fails on?
[09:05] <asac> pitti: interesting
[09:06] <asac> pitti: can you reply to the mail i sent?
[09:06] <asac> for ue-leads
[09:06] <asac> ?
[09:06] <pitti> asac: sure
[09:11] <xeranas__> hello, seems ubuntu-docviewer-app autopilot tests wont work.. I wonder if it something todo with my envoroment :/
[10:22] <asac> pitti: so stated the question: what should we do with the proposed dashboard in the context of our "stricly green" mission we run elsewhere?
[10:22] <asac> gema said you might have better idea how to approach this
[10:29] <pitti> asac: TBH I don't understand the question
[10:31] <asac> pitti: https://jenkins.qa.ubuntu.com/view/Saucy/view/AutoPkgTest/
[10:31] <asac> we have lots of reds there
[10:31] <pitti> asac: that's right; we need package uploaders to actually pay attention to failures there
[10:32] <asac> pitti: should we go serious about it if we see that happen? or just keep it FYI?
[10:32] <pitti> plus, we earn quite a number of failures from Debian which we need to keep up with fixing
[10:32] <pitti> I'm doing quite a lot, but doing this single-handedly is too much work
[10:32] <asac> pitti: are the tests maintained by upstream that we run?
[10:32] <asac> or do we always have to fix tests first?
[10:32] <pitti> asac: most of the ones that you see there are nontrivial to fix, so it's not something you'd do on a Friday
[10:32] <pitti> asac: no, these come from debian/ubuntu
[10:33] <asac> pitti: can you give me an example of a test that is nontrivial to fix?
[10:33] <pitti> asac: if a package has failing tests, it won't move out of -proposed into saucy
[10:33] <asac> what about firefox?
[10:33] <asac> pitti: ok we do that?
[10:33] <pitti> asac: unless the release team overrides it
[10:33] <asac> i assume we have a whitelist?
[10:33] <asac> e.g. stuff we let through anyway?
[10:34] <pitti> yes
[10:34] <pitti> asac: firefox has worked for a while, but chrisccoulson stopped maintaining it AFAIK; saucy-adt-unity-firefox-extension has never been fixed to actually work as nobody bothers
[10:35] <asac> pitti: but who added a not working pkg test in first place?
[10:35] <asac> for extension
[10:35] <pitti> asac: people who don't ensure that they actually work? ..
[10:35] <chrisccoulson> pitti, the last time i looked, it was not even getting to the stage of running any of the firefox tests (ie, failing much earlier)
[10:35] <asac> so let me rephrase:
[10:35] <asac> 1. once we had an initiative in ubuntu/canonical to write autopkg tests
[10:36] <asac> 2. those are the ones that we have now
[10:36] <asac> 3. unfortunately a bunch were landed brokenly
[10:36] <pitti> asac: we are still getting new ones
[10:36] <asac> 4. and we didn't calibrate our resources/priorities to ensure taht we could fix the ones that broke
[10:36] <pitti> the server team recently added like 20
[10:36] <chrisccoulson> pitti, https://jenkins.qa.ubuntu.com/job/saucy-adt-firefox/lastCompletedBuild/ARCH=amd64,label=adt/artifact/results/summary.log
[10:36] <asac> 5. since then we have people adding tests, but its an optional, nice to have thing?
[10:36] <chrisccoulson> i think i need someone like jibel to look at that really
[10:37] <pitti> chrisccoulson: well, this just says that running xpcshell-tests was killed after 4 hours
[10:37] <asac> e.g. a service that folks can or can not use ... and where releaase team has to process bunch of stuff that nobody cared about?
[10:37] <asac> i think i get the picture
[10:37] <asac> :-P
[10:37] <chrisccoulson> pitti, but the same tests run fine on raring :/
[10:38] <chrisccoulson> pitti, https://jenkins.qa.ubuntu.com/job/raring-ppa-adt-mozillateam_firefox_next-firefox/ (that's identical)
[10:38] <gema> chrisccoulson: so there is some compatibility break in saucy?
[10:38] <pitti> chrisccoulson: so, looks like a problem with a newer library?
[10:38] <asac> chrisccoulson: it doesnt matter that they run there
[10:38] <asac> chrisccoulson: today is today :)
[10:39] <pitti> asac: these days it's optional, yes (e. g. we don't yet require it as part of MIR)
[10:39] <chrisccoulson> gema, i guess there must be, as the 2 examples there are using the same firefox package
[10:39] <asac> chrisccoulson: the test owner needs to debug and drive it and keep it working ... folks cannot assume that QA will always maintain everything you ever did :)
[10:39] <asac> that doesnt scale
[10:39] <pitti> asac: but it's a nice way to keep your package working and avoid new dependencies breaking it
[10:39] <jibel> gema, we don't know exactly what until someone (me?) have a look at what's happening in the testing environment
[10:39] <pitti> asac: so they are quite popular
[10:39] <chrisccoulson> asac, the problem is, there is no firefox maintainer anymore ;)
[10:39] <gema> jibel: I know, and that doesn't quite escale
[10:39] <asac> pitti: but release team has to deal with broken shit and exceptions and manual poking etc. all the time I hear?
[10:40] <asac> let's really try to get those sorted imo
[10:40] <pitti> asac: only if people ask them to do an override because they want to land a package even if it breaks some test
[10:40] <asac> what we first need is to figure who owns which tests
[10:40] <asac> e.g. who was the author
[10:40] <pitti> asac: I agree, it would be nice to clean this up; we once were down to 4 failures or so
[10:40] <asac> lets do it
[10:40] <asac> and lets go for always green
[10:40] <pitti> asac: we also get a lot of broken ones from debian
[10:41] <pitti> asac: an autopkgtest fixing hackfest with 3 people (server/desktop/qa) fulltime could do nicely
[10:41] <asac> we need to do that forever
[10:41] <asac> we can make a priority effort to start off
[10:41] <asac> yes
[10:41] <pitti> asac: e. g. they mysql one has a single test failure, all others succeed; these should be able to get fixed, if nothing else by disabling that one test
[10:41] <asac> but people are currently under constant fire :) so all i am doing right now is start talking and thinking
[10:42] <asac> pitti: yeah. there are stories for every failyure. I think we just need to clearly identify who owns each of those
[10:42] <asac> so we can get them fixed
[10:42] <asac> if debian owns them, lets think
[10:42] <asac> at least those that we own we can clear out
[10:42] <pitti> asac: yes, but we also need to allocate some serious time to actually work on them
[10:43] <pitti> asac: and clean up tests which nobody cares about and which have always been broken (oneconf, unity-firefox-extension, etc.)
[10:43] <asac> pitti: lets really have a list, each test gets one owner, we socialize that list and then everybody fixes one. with quality team helping folks to be productive rather than doing all the work
[10:44] <asac> i think during that process we will find apps that nobody cares about
[10:44] <pitti> asac: we need domain knowledge for a lot of the tests, but many can presumably be fixed by any (core?) dev given some time
[10:44] <asac> some we can clean
[10:44] <asac> some we have to ensure are cared for
[10:44] <pitti> asac: right; we had two hackfests for that, and in both we got some nice cleanup/fixes
[10:45] <asac> pitti: yeah. that doesnt really work though. its far easier just to have a clear owner who is on the hook. otherwise, its always ending up on the shoulder of a few folks that work overly hard anyway
[10:45] <asac> like you :)
[10:45] <pitti> asac: that, too
[10:45] <pitti> asac: but given the current number we are going to need some extra time anyway to get back to a good situation
[10:45] <pitti> asac: from then on it'll be continued maintenance which should be done by the actual uploaders/teams
[10:46] <asac> pitti: is there a way we can find reasonable owners? if yo ucould help me with that, I will do some talking and see what other managers think :)
[10:46] <asac> finding == checking who did the test .. if that was someone from qa, who is the package uploader?
[10:46] <asac> chrisccoulson: we have the policy that stuff sticks to whoever did it last
[10:46] <asac> :)
[10:47] <asac> chrisccoulson: thats not a policy, but a general attitude of ubuntu
[10:47] <asac> :)
[10:47] <asac> so in that theory you are still the firefox maintainer no matter what you signed up for :)
[10:47] <pitti> asac: we can certainly go through the list and sort them into "desktop/server/foundations/QA" buckets (QA being the fallback for broken tests from Debian, or problems with infrastructure)
[10:47] <pitti> asac: want to do that now?
[10:48] <chrisccoulson> asac, yeah, i see how this works now, there's no escape for me ;)
[10:51] <pitti> asac: I'm going through them and bucket them
[10:52] <asac> pitti: yeah. just keep zero stuff assigned to the QA team for now
[10:52] <asac> i would like to have a bit more discussion about the debian ones
[10:52] <asac> the ones that are essential we need to find an owner in a real engineering team i think
[11:20] <pitti> asac: ok, review done (http://paste.ubuntu.com/5910831/)
[11:20] <pitti> asac: I should perhaps send that to u-devel@?
[11:21] <asac> let me see
[11:21] <pitti> gema: ^ FYI
[11:21] <asac> pitti: in those teams, do we know who did the test/work last time (e.g. the name?)
[11:21] <asac> or if you didnt put a name you say: these should be owned by someone from their team
[11:21] <asac> but so far tehre was no owner?
[11:22] <pitti> asac: we can check in changelogs, but for now I only bucketed it to a particular developer where it's clear
[11:22] <pitti> asac: for the regresssions that are broken by a dependency it's not immediately clear who the owner is
[11:22] <asac> pitti: ok. so you say it would be clear who would own "saucy-adt-apt-clone" for instance?
[11:22] <pitti> asac: e. g. ubuntu-release-upgrader didn't change, but update-manager did which broke the release-upgrader
[11:23] <pitti> asac: again, no; apt-clone itself didn't change, but saucy underneath changed
[11:23] <asac> sure, but whoever owns apt-clone has to be the owner
[11:23] <asac> in the sense that he has to drive it
[11:23] <asac> his app got broken
[11:23] <pitti> asac: I think these either need to be fixed at regular "test fix days", or the teams' tech lead should own them and distribute
[11:23] <asac> so he is the only sane choice if it comes to "who must care" :)
[11:23] <asac> maybe the techlead
[11:24] <asac> or manager
[11:24] <pitti> asac: teams' TL is a good default IMHO if there is no clear individual owner
[11:24] <asac> yeah. i will get individual owners anyway ... or a pai
[11:24] <asac> r
[11:24] <asac> but techlead/manager should say
[11:25] <pitti> asac: I'll send the current list to u-devel@ to raise some awareness
[11:25] <asac> cool!
[11:25] <asac> :)
[11:25] <asac> i cant participate there though :)
[11:25] <asac> but didnt plan to anyway
[11:28] <pitti> asac: err, why can't you post to u-devel@?
[11:29] <asac> pitti: i got booted from everything
[11:29] <asac> because i didnt see the renew mail :)
[11:29] <asac> i think ubuntu-devel is restricted to devs
[11:30] <asac> anyway. this is for me more of an internal management team task anyway
[11:30] <asac> needs some socializing that we want to green at all :)
[11:30] <pitti> asac: I can forward it to the internal ML afterwards if you want
[11:31] <asac> no its fine. let me start to raise it and then we can bring results from u-devel into that discussion
[11:31] <asac> will do it verbosely for today :)
[11:31] <asac> (if we get to it)
[11:35] <pitti> asac: sent, with you in CC
[11:35] <asac> cool
[11:36] <pitti> asac: and fwded to ue leads
[11:36] <knome> balloons, there's a bug in the auto-resize testcase...
[11:36] <asac> pitti: gratias
[11:36] <pitti> de nada
[11:37] <knome> balloons, it implies that the "select drive list" with the movable bar always appears, but i didn't get that since i had some free space on the drive.
[12:52] <knome> balloons, also, i really think live session and persistence should be two different tests
[13:02] <DanChapman> xnox, hey :-) SO i have re-written the autopilot tests, and they now exit if an error dialog of some kind appears. I also changed how it handles the wait between each page loading and the test should no longer get stuck there. in general they are all running really well on jibel's test runner.
[13:05] <knome> people testing alpha 2 images, wondering if bug 1185396 is xubuntu-specific or if it affects everybody
[13:59] <slickymaster> hello all
[14:00] <OE4SKW> Hello, how are u?
[14:01] <OE4SKW> how to join and get started testing?
[14:02] <DanChapman> OE4SKW, i would suggest starting here https://wiki.ubuntu.com/QATeam
[14:03] <DanChapman> OE4SKW, all the info on how you can help testing can be accessed from there
[14:03] <OE4SKW> ok, thank u very much fer info
[14:34] <jodh> pitti: the dep8 failure for abi-compliance-checker is documented on debian bug 717806. Problem seems to be gcc 4.8. This used to work in Debian sid but never worked in Ubuntu as we were already using gcc4.8.
[14:34] <pitti> jodh: ah, thanks for the info
[14:35] <jodh> pitti: I'm keen we get this fixed as we're having to manual disable abi-c-c from being called in the upstart build atm.
[14:37] <jodh> pitti: btw - do you have a feel yet for how long it might take to implement the nested kvm feature in autopkgtest?
[14:37] <pitti> jodh: I started on making the master VM available, but that triggered a mysterious hang in the script
[14:37] <jodh> pitti: the lxc dep8 test failure looks like it might be an stderr output issue as the test *does* pass.
[14:38] <pitti> jodh: I need to debug this more, I planned this for tomorrow afternoon
[14:38] <jodh> pitti: does stderr output get dumped to $ADTRESULTSDIR by default?
[14:38] <pitti> jodh: yes, if a test outputs stderr, it will become an artifact
[14:39] <pitti> jodh: https://jenkins.qa.ubuntu.com/view/Saucy/view/AutoPkgTest/job/saucy-adt-lxc/25/ARCH=i386,label=adt/ does have a stderr attachment
[14:40] <pitti> E: Couldn't create temporary file to work with /var/lib/apt/lists/partial/security.ubuntu.com_ubuntu_dists_saucy-security_Release - mkstemp (2: No such file or directory)
[14:41] <jodh> pitti: looks like that error is coming from apt.
[14:42] <pitti> yeah, I guess lxc-create calls that
[14:43] <jodh> pitti: I think it might be /usr/share/lxc/templates/lxc-ubuntu.
[14:43] <jodh> pitti: hmm - the lxc bzr branch is out-of-date.
[14:44] <pitti> jodh: https://jenkins.qa.ubuntu.com/view/Saucy/view/AutoPkgTest/job/saucy-adt-lxc/ shows that the very same version succeeded before, so it could certainly be a behaviour change in apt or some other underlying tool
[14:44] <pitti> jodh: I can just try and re-run it if it could help
[14:45] <pitti> but in between the runs there are 16 days; a lot has happened in that time
[14:45] <pitti> jodh: so it's quite plausible that something in https://launchpad.net/ubuntu/+source/apt/0.9.9.1~ubuntu1 broke lxc-create
[14:46] <pitti> lxc doesn't directly depend on apt, otherwise apt would have been held back for this
[14:57] <jibel> pitti, it is surprising how tests are dropped easily during package syncs, it happened twice already. I'm wondering if it is the case for other distro patches
[14:57] <pitti> jibel: yeah, that's why I'm rather insistant of letting exit status 8 count as failure
[15:05] <pitti> jibel: hm, the "mount: unknown filesystem type 'iso9660'" error in gvfs' autopkgtest is stunning -- isofs.ko is not even in linux-extras, and we should have that; it doesn't happen on my desktop, trying in run-adt-test now
[15:10] <jibel> pitti, isn't it caused by the crash of kmod?
[15:10] <pitti> oh yeah, that would be it
[15:11] <jibel> pitti, previous runs fail for different reasons
[15:11] <pitti> jibel: yes, that was due to "modprobe scsi_debug" not resolving symbols
[15:11] <pitti> jibel: I also couldn't reproduce this
[15:11] <pitti> it's still odd, "log" shows in my local test run that all the tests succeeded
[15:11] <pitti> and "run-adt-test -s gvfs" succeeds
[15:12] <pitti> jibel: I'll re-try this in the actual QA machines
[15:12] <jibel> ok
[15:17] <pitti> jibel: hm, it succeeds on albali, too; WTH
[15:17]  * pitti runs it again, perhaps this only happens on one of the other hosts
[15:24] <pitti> jibel: hm, it happened again, crazy
[15:29] <pitti> jibel: so it works on aldebaran and falls over on wazn..
[15:29] <pitti> jibel: do you know whether anything is wrong with wazn?
[15:29] <pitti> ah, wazn is raring, aldebaran is precise
[15:30] <pitti> jibel: so this doesn't look like a saucy bug, but something with qemu/kernel which regressed in raring and was fixed in saucy
[15:31] <pitti> jibel: just to verify, could I temporarily disable wazn as a slave (how do I do that?) and re-run the test?
[15:35] <jibel> pitti, bring it offline
[16:16] <slickymaster> knome: quick question
[16:17] <knome> slickymaster, yes?
[16:19] <slickymaster> knome, I want to start on the translation of Xubuntu-docs, Saucy series. Do you think it's preferable to do it in LP (translations in Rosetta) or should I download the tarball and the upload the translation?
[16:19] <knome> slickymaster, they both should give the same results.
[16:20] <slickymaster> knome: yeah, I know :) just asking what you think should be the best approach to do it?
[16:20] <knome> slickymaster, just a note that i'm not sure if we can get the translations set up for saucy (or T), but we'll certainly hope to get to use them (as soon as possible)
[16:21] <slickymaster> knome: yes, it's quite big, but I'll try to do as much as I'll manage to
[16:21] <knome> slickymaster, as long as you're the only one working on the translation for that specific language, i think it might be slightly better to work on it offline
[16:22] <knome> slickymaster, not about having complete translations, more related to the technical side of being able to enable them to those who use non-english languages
[16:23] <slickymaster> knome, I see what you mean. Anyway as I'm a member of the portuguese translators team I'll mail them alerting them I'm working on it
[16:24] <knome> slickymaster, sure :)
[16:24] <slickymaster> knome, thanks :)
[16:24] <knome> np
[16:42] <elopio> ping balloons. I have some questions about the test case.
[16:43] <balloons> elopio, hey, I was going to see how it was going :-)
[16:43] <elopio> balloons: I tried to extract the common things, and just got some questions, no real code :)
[16:43] <elopio> balloons: what's the --desktop_file_hint for?
[16:43] <knome> balloons, check your awaylog :P
[16:45] <balloons> knome, :-) xchat lied to me, sorry
[16:50] <balloons> elopio, where are you seeing that?
[16:51] <phillw> balloons: do we have any resources (e.g. wiki page) for smoke testing? No rush for an answer, I'll be doing some wiki editing on https://wiki.ubuntu.com/Testing/Activities a bit later.
[16:51] <balloons> phillw, smoke testing, smoke testing.. hm hmm hmm
[16:52] <phillw> also is there a page for hackfests?
[16:52] <balloons> so knome if I get what your saying, because you had enough free space already the installer just used it and didn't prompt you to resize, yes? that makes sense, and we should update :-)
[16:52] <balloons> phillw, https://wiki.ubuntu.com/QATeam/Hackfest
[16:53] <phillw> thanks, I'll get that added to Activities
[16:53] <balloons> ty :-)
[16:53] <elopio> balloons: on launch_test_installed. For exampe ubuntu_filemanager_app/tests/__init__.py
[16:53] <knome> balloons, yup.
[16:57] <balloons> elopio, ahh, ok, gotcha :--) That I believe is intended for the desktop to utilize the proper icon etc, but I make very well be wrong
[16:57] <balloons> knome, ok, well we should update it then. Would you like to file a bug for it, or shall I?
[16:58] <balloons> on the live / persistence tests, well, they are always a subject of debate, so I don't mind having a discussion on them
[16:59] <elopio> balloons: I'm just wondering why do we launch the app with qmlscene instead of just calling the binary. That would make things clearer, but would require the apps to change the binary to receive arguments.
[16:59] <balloons> elopio, good question ;-) I don't know tbh.. and actually we should test the binary or the included source.. really is silly to test the installed bits of the binary
[17:00] <balloons> testing that makes no sense at all..
[17:00] <elopio> I think it's good to be able to run the tests against the installed package, but I don't like the way we do it.
[17:01] <elopio> I'm not sure how to improve that, though. Maybe we can start just refactoring it to take the binary from a method that can be overwritten or changed easily.
[17:01] <balloons> elopio, yes, but we should invoke the binary as you say.. the hardcoded location is fragile and will break
[17:04] <knome> balloons, i can do later... or if you have the time, go ahead
[17:06] <knome> balloons, my argument for separating them is that the live session is a low-hanging fruit for anybody, or those who are doing other installation tests
[17:06] <knome> balloons, however, reporting a result without the persistence part is kind of useless..
[17:06] <knome> balloons, and otoh, the persistence part is a big enough chunk to warrant its own test anyway
[17:06] <balloons> https://bugs.launchpad.net/ubuntu-manual-tests/+bug/1205009
[17:07] <balloons> knome, filing a bug for that idea is probably sane as well.. I can file one now :-)
[17:08] <knome> balloons, bug 1198466 :P
[17:08] <knome> balloons, please do :)
[17:11] <balloons> https://bugs.launchpad.net/ubuntu-manual-tests/+bug/1205013
[17:11] <balloons> also commented on elfy's bug accordingly
[17:12] <elfy> thanks
[17:13] <elfy> balloons: is there anyway to make an alpha run last longer - in the end we got about 3 days :)
[17:13] <elfy> OR is there a way to run a particular snapshot for longer than a day?
[17:13] <knome> the persistence test will always require usb-creator-gtk if we want to allow the "easy" way - and tbh, that's more like a prerequisite for the testcase rather than part of the test (eg. if there's a bug in usb-creator-gtk it's not really a bug in the testcase)
[17:13] <knome> elfy, we are able to control that ourselves afaik
[17:14] <balloons> knome, agreed on the usb-creator-gtk
[17:15] <balloons> elfy, yes, I agree with knome, you should be able to fully control how long it runs, when it starts, etc
[17:15] <knome> i haven't looked deeply enough into the issue to know how though
[17:15] <knome> stgraber would know O:)
[17:15] <balloons> well, this is still a learning exercise.. so yea, :-)
[17:15] <DanChapman> balloons, howdy!
[17:15] <balloons> DanChapman, hello!
[17:16] <knome> fwiw, it's not obvious from the tracker
[17:16] <balloons> fyi http://www.reddit.com/r/IAmA/comments/1j166z/hi_im_mark_shuttleworth_founder_of_ubuntu/
[17:21] <elfy> knome: oh ok - didn't know that - much like the rest of the tools ;)
[17:21] <knome> :)
[17:22] <elfy> as I said I looked for the manual :p
[17:22] <knome> manual for the qa tracker...
[17:22] <elfy> I'll try and catch stgraber and have a chat about it
[17:22] <elfy> just manual would be an excellent start :p
[17:23] <balloons> elfy, knome sadly the manual got wiped on the wiki somehow..
[17:23]  * balloons is still grieving
[17:24] <elfy> balloons: I'm not sure I believe there even was one :p
[17:24] <balloons> there was even a section for admins, but again, it's been lost
[17:24] <knome> ask the IS if they have backups?
[17:24] <elfy> 'it got broke' is a likely excuse lol
[17:24] <knome> you might even get an answer in less than a month :P
[17:25] <elfy> leave IS alone please - elfy more worried bout the forum :)
[17:25] <balloons> haha you 2
[17:25] <knome> finally no forums so elfy has more time for other things!
[17:25] <elfy> well - I wish :)
[17:25] <knome> we should keep the forums closed;)
[17:26] <elfy> putting knome on ignore ...
[17:26] <knome> i thought i already was
[17:26] <elfy> ha ha ha
[17:27] <knome> i'm sure several community members secretly wish they could ignore me
[17:27] <knome> and some already do ;)
[17:31] <elfy> :p
[17:31] <elfy> there is a team - they asked - I declined :)
[17:31] <knome> declined what?
[17:32] <knome> launchpad team we-have-knome-on-ignore?
[17:32] <slickymaster> elfy, hi. I've finished gThumb testscase and it's more than 200 lines long. Do you think that it could problematic?
[17:32] <knome> and you were declined to join?
[17:32] <slickymaster> could be
[17:33] <knome> slickymaster, you could split it in several tests if there is a sensible way to split...
[17:33] <slickymaster> elfy, truth is gThumb has a lot of features, menu options and toolbar buttons
[17:34] <slickymaster> elfy: kind of a small gmb one
[17:35] <slickymaster> knome, honestly I don't see how, without loosing consistency
[17:37] <elfy> then don't - push it let someone else have a look :)
[17:37] <elfy> knome: I was good enough to say I quite liked talking to you
[17:37] <slickymaster> elfy, ok, I'll do it tonight, after dinner
[17:37] <phillw> balloons: re: the lost wiki pages, can you not find them on google archive? Whilst a bit of a pain to re-format, it's better than nothing.
[17:38] <slickymaster> 'bye all. until later
[17:39] <phillw> balloons: re: smoke testing, the only thing I can find is dated 2008 :( https://wiki.ubuntu.com/Testing/ISO/Smoke
[17:40] <balloons> phillw, the basic idea for us nowadays is smoke testing the development release.. that is, installing and running the daily release.. better described as dogfooding I'd suppose :-)
[17:40] <balloons> all the testers who run saucy fulltime are doing this
[17:41] <phillw> do we have a dogfood guide? :;)
[17:41] <elfy> winalot do phillw
[17:41] <balloons> phillw, no it's something I've been lamenting for a little bit
[17:41] <DanChapman> pedegree chum is a fav in this house
[17:42] <phillw> I run lubuntu 13.10 as my 'production' machine ever since a fight between vBox and KVM killed my 13.04 :D
[17:43] <phillw> So, the page title would be "dogfooding" or "smoke testing" ?
[17:45] <balloons> hmm, elfy knome, maybe we can expand on this page: https://wiki.ubuntu.com/Testing/TestCaseAdmins/ManagementOverview
[17:45] <elfy> that page is a start - I saw that - it answered none of my questions :D
[17:46] <balloons> elfy, it was never intended to :-) But we could use it as a start
[17:46] <balloons> anyways, phillw , efly, knome.. I looked again, no avail.. consider it gone.. which is well enough. We can redo it
[17:47] <elfy> balloons: probably we need to look at making a few linked pages - I'm obviously an ideal candidate to work through what's missing lol
[17:47] <balloons> documenting the qatracker.. from and admin side and a testers side
[17:47] <elfy> I'll add it to my piece of paper that gets longer
[17:47] <balloons> i'll note to some extent it should be selfdocumenting
[17:47] <elfy> :)
[17:48] <balloons> I don't want a giant manual.. no one will read it or maintain it if so
[17:58] <xeranas> good evening
[17:59] <elfy> it is here :) hope it is there too
[18:02] <xeranas> I have trouble to run ubuntu-docviewer-app autopilot tests, seems it fail to run (_StringException) did I miss something?
[18:21] <balloons> xeranas, evening to you!
[18:21] <balloons> xeranas, so, what's the lp branch, I'll grab it and take a look with you
[18:22] <xeranas> balloons:  bzr branch lp:ubuntu-docviewer-app
[18:22] <xeranas> balloons: I have problem run existing tests
[18:23] <balloons> xeranas, ohh, gotcha
[18:24] <balloons> xeranas, hmmmph.. I get CalledProcessError: Command '['which', '../../ubuntu-docviewer-app']' returned non-zero exit status 1
[18:24] <xeranas> balloons: same
[18:24] <knome> balloons, what was the wiki page name?
[18:24] <balloons> well, it's not just you then :-)
[18:24] <balloons> knome, https://wiki.ubuntu.com/Testing/TestCaseAdmins/ManagementOverview
[18:24] <balloons> ?
[18:25] <balloons> xeranas, so let's look and see what's up
[18:25] <knome> balloons, no, the lost manual
[18:25] <balloons> knome, that's the trouble.. I can't remember
[18:25] <balloons> we could try asking xdatap1 if he knows where it's at
[18:25] <balloons> knome, you know Paolo? he might have an idea
[18:26] <knome> heh, i've even met him in person!
[18:27] <balloons> he helped create the admin side pages.. the tester side stuff was on wiki.ubuntu.com/Testing/QATracker
[18:30] <xeranas> balloons: local_location on __init__.py defined as "../../ubuntu-docviewer-app" other test cases targeting *.qml file. and on launch_test_local there no "qmlscene" atribute. However when I tried change those it seems like they fall in infinite-loop. So not sure how it should be
[18:32] <knome> http://web.archive.org/web/20130603050554/https://wiki.ubuntu.com/Testing/QATracker
[18:32] <knome> balloons, does that look old enough? `
[18:33] <knome> https://wiki.ubuntu.com/Testing/CallforTesting/ and subpages what you looking for?
[18:35] <phillw> balloons: http://webcache.googleusercontent.com/search?q=cache:wiki.ubuntu.com/Testing/QATracker exists?
[18:36] <balloons> knome, phillw has already rezzed the qatracker page from google cache
[18:36] <balloons> the admin stuff though, I've no idea of the url so...
[18:36] <knome> balloons, did you look at the link i gave you?
[18:36] <balloons> xeranas, yes, the launch code needs tweaked, I agree
[18:37] <knome> or was it something even more
[18:37] <balloons> knome, yes, your archive link is more or less the page, minus the pics :-)
[18:37] <balloons> it's there again on wiki.ubuntu.com/Testing/QATracker
[18:38] <balloons> xeranas, so the issue with docviewer was/is it has to be launched differently because it needs command line arguments
[18:40] <phillw> I thought I recognised it :)
[18:41] <balloons> xeranas, so I
[18:43] <balloons> xeranas, so I'm playing with how it's launching and it doesn't complain anymore, but it doesn't launch the app :-) I'll keep tryuing
[18:46] <xeranas> balloons: yea, here it is tricky part of autopilot
[18:48] <balloons> elopio and I were  just talking about this actually
[18:50] <phillw> balloons: hackfest has been added to activities, just awaiting your decision on the title of the dogfooding / smoke testing page :)
[18:51] <balloons> hehe.. dogfooding works fine actually.. perhaps using it will be better since it won't be confusing anything with the other term
[18:51] <balloons> smoke testing is high level see if it blows up style testing.. it can be applied to anything
[19:02] <balloons> xeranas, so, for the moment, might be best to look at something else. We should file a bug stating the tests are broken though
[19:05] <balloons> xeranas, would you like to file it? https://bugs.launchpad.net/ubuntu-docviewer-app/+filebug
[19:09] <xeranas> balloons: I'm bad on summary and descriptions writing, sometimes ppl have hard time to understand me
[19:11] <balloons> xeranas, ok, I'll file :-)
[19:11] <balloons> no worries!
[19:11] <balloons> evening dkessel, Letozaf_
[19:12] <xeranas> balloons: ok, thanks
[19:13] <Letozaf_> balloons, evening :)
[19:21] <dkessel> good evening balloons :)
[19:22] <balloons> hopefully the netsplit has finished :-)
[19:22] <dkessel> pitti, asac, interesting discussion you had about the autopkgtests. i'd be willing to help with getting tests to work again, if that is needed.
[19:23] <dkessel> although i too believe the developer teams should get a first chance of fixing the tests ;)
[19:24] <dkessel> oh-oh.... bad net split
[19:27] <balloons> Letozaf_, what are you up to this evening?
[19:28] <Letozaf_> balloons, I was running the music app tests so I can write more
[19:30] <balloons> Letozaf_, did you see: https://lists.launchpad.net/ubuntu-touch-coreapps/msg00516.html
[19:31] <balloons> there's been an on-going thread today about the music app
[19:34] <Letozaf_> balloons, yes I saw something pass by, but could not read it, too much e-mails, so I didn't know about it :(   I'm reading now
[19:34] <balloons> Letozaf_, :-)
[19:35] <Letozaf_> balloons, victor told me that by email that there is a  known issue and is documented in bug #1204711.
[19:36] <Letozaf_> balloons, and that was what was happening to me :)
[19:36] <Letozaf_> balloons, oh well! I will have to pick something else meanwhile :p
[19:37] <balloons> Letozaf_, did you have questions on the rss reader?
[19:37] <balloons> the dev is online right now :-)
[19:37] <Letozaf_> balloons, could not branch it , it was not on the rss reader branch
[19:38] <Letozaf_> balloons, if you tell me were to fetch the updated tests I will look at  them now
[19:38] <balloons> xeranas, if your still about, hop in #ubuntu-touch-meeting
[19:38] <Letozaf_> balloons, unless the last updates are in the branch now
[19:38] <balloons> Letozaf_, ohh yes the branching thing.. no we resolved that
[19:38] <balloons> for the tests, we'll grab from your last branch
[19:39] <balloons> they don't exist in the upstream bracnh anymore
[19:39] <balloons> they apologized for the massive commit, and it shouldn't be an issue in the future I trust
[19:41] <balloons> but yea I figured we'd just start from your old branch and copy the files over, then modify them so they work again :-)
[19:42] <Letozaf_> balloons, ok so I will bzr branch my old branch, just to be sure I have the right tests
[19:43] <balloons> yes
[19:47] <Letozaf_> balloons, I got it and ran the tests
[19:47] <balloons> Letozaf_, excellent
[19:47] <Letozaf_> balloons, they work fine on my box
[19:48] <Letozaf_> balloons, but there were problems in Jenkins
[19:48] <balloons> Letozaf_, really? awesome.. I was expecting re-work
[19:48] <balloons> Letozaf_, well yes, but that doesn't have to be an issue for you :-)
[19:48] <balloons> you can finish writing the tests needed for it without worry :-)
[19:48] <balloons> I get to worry about jenkins, hah
[19:49] <Letozaf_> balloons, fine so I will carry on with other tests
[19:49] <Letozaf_> balloons, I will first look at the code to see what you guys did
[19:49] <balloons> Awesome.. yea, do you like the new theming?
[19:49] <balloons> i like the ui much better now
[19:49] <Letozaf_> balloons, thats weired I have not new theming ...
[19:50] <Letozaf_> balloons, :?
[19:50] <Letozaf_> balloons, have I got the wrong branch ?
[19:50] <Letozaf_> balloons, bzr branch lp:~carla-sella/ubuntu-rssreader-app/ubuntu-rssreader-test-add-view-feeds
[19:53] <Letozaf_> balloons, maybe I missed something, like the copying the files over to my branch
[19:55] <balloons> Letozaf_, ohh, ok lol
[19:56] <balloons> Letozaf_,  so you bzr branch lp:ubuntu-rssreader-app
[19:56] <balloons> it will pull everything down from the new stable trunk.. Then grab your autopilot folder from your lp:~carla-sella/ubuntu-rssreader-app/ubuntu-rssreader-test-add-view-feeds branch and paste it into the directory
[19:57] <balloons> then, let's see what happens when you run the tests.. they might need tweaked a little
[19:57] <balloons> make sense?
[19:57] <Letozaf_> balloons, sure ok let me do it now
[19:59] <Letozaf_> balloons, cool, the new theming... but got errors, let me see
[20:01] <balloons> right.. let me know if I can help work through the changes.. I don't think it will be too bad :-)
[20:03] <thomi> morning
[20:04] <balloons> morning thomi
[20:06] <Letozaf_> balloons, yes I am looking at the changes made, now... doesn't look too bad :P
[20:06] <balloons> hehe :-)
[20:08] <balloons> elopio, did you get anywhere on the example? I'd like us to polish it off today if possible
[20:10] <elopio> balloons: no, I got distracted with the base test case.
[20:10] <elopio> I had done some work with the filemanager app. I can updated it in ~1 hour. Does that sound good?
[20:10] <balloons> elopio, fair enough.. I was just hopping back in to look at it, but I can polish off the post instead :-)
[20:12] <elopio> balloons: I've just pulled the file manager app from trunk, and now it is showing the toolbar always.
[20:12] <elopio> do you know if that's intended?
[20:15] <balloons> elopio, no, but I can ask
[20:15] <balloons> they're meeting right now actually in #ubuntu-touch-meeting :-p
[20:25] <balloons> elopio, https://bugs.launchpad.net/ubuntu-filemanager-app/+bug/1198861
[20:26] <elopio> good :) thanks balloons.
[20:50] <balloons> elopio, do you think we can direct bugs here: https://bugs.launchpad.net/ubuntu-ui-toolkit/+filebug?
[20:50] <balloons> or here: https://bugs.launchpad.net/ubuntu/+source/ubuntu-ui-toolkit/+filebug?
[20:50] <elopio> balloons: the first one.
[20:51] <elopio> I'll subscribe there to triage.
[20:52] <elopio> balloons: the rename branch has just merged. So, we just have to wait for the nightly packaging.
[20:53] <balloons> elopio, so I've just mentioned to look at usr/lib/python2.7/dist-packages/UbuntuUiToolkit/emulators.py if you want to know what the emulator can do.. no docs  otherwise
[20:54] <elopio> balloons: I've documented all the public methods. I'm not sure what we need to do to publish those docs to the api page.
[20:54] <balloons> hmm hmm
[20:56] <elopio> a section here with the methods from the autopilot emulators would be great:
[20:56] <elopio> http://developer.ubuntu.com/api/devel/ubuntu-13.10/qml/ui-toolkit/overview-ubuntu-sdk.html
[21:01] <balloons> elopio, let me make that piece happen then
[21:04] <balloons> elopio, where is the documentation at?
[21:05] <elopio> balloons: as docstrings of each class member. Formated with sphinx syntax.
[21:06] <balloons> I'm only slightly familiar with sphinx, but I saw that.. The question is, can I build the docs, or is it going to be a manual extraction thing?
[21:07] <elopio> balloons: you can use sphinx to extract that. But I'm not sure how, cgolberg is the one that takes care of our docs.
[21:07] <balloons> elopio, ok, I'll pull the source and try
[21:09] <elopio> balloons: take a look at lp:selenium-simple-tests. The docs directory.
[21:09] <elopio> but maybe it would be better to ask the sdk team how do they extract the qml docs.
[21:10] <balloons> well, it's something I can do.. So I'll work on that piece :-)
[21:10] <balloons> the post should otherwise be ready, just need an example, and the docs
[21:10] <elopio> balloons: and the package.
[21:11] <balloons> well.. yes, but the bots will have that ready :-)
[21:11] <elopio> balloons: I've been updating the filemanager app for the past hour and I still have like one more our to go. They added many tests.
[21:11] <elopio> you mentioned another app that was without tests, right?
[21:12] <balloons> elopio, yes filemanager has quite a few.. probably the most :-)
[21:12] <balloons> elopio, I was working on dropping letters.. it has no tests
[21:12] <balloons> I thought it would be good to show the basic infrastructure
[21:12] <elopio> ok, that would make a clearer example.
[21:12] <balloons> right right
[21:12] <elopio> balloons: do you have a branch in progress, or should I get trunk?
[21:13] <balloons> elopio, I could push something, but it doesn't do much if you'll remember.. let me push it regardless
[21:14]  * balloons facepalms
[21:14] <balloons> I just did a bzr revert and wiped my changes
[21:14] <balloons> wow...
[21:15] <knome> balloons, stupid.
[21:15]  * balloons is stunned
[21:16] <phillw> ouch :(
[21:16] <knome> balloons, time to drop all the legacy testcases from iso.qa.?
[21:20] <balloons> elopio, grab trunk... in short, I'm an idiot and wiped my work
[21:20] <knome> balloons, can't you rerevert?
[21:20] <elopio> balloons: happens to me all the time :)
[21:20] <balloons> knome, what happened was I hadn't yet committed my changes. But before I committed I wanted to see if I needed to pull anything, so I did the pull
[21:21] <balloons> there was a conflict, so I just reverted without thinking
[21:21] <knome> aha
[21:21] <knome> :<
[21:21] <balloons> I'll note in git I would have simply stashed my changes
[21:22] <balloons> afaik, bzr doesn't have such a thing, but it very well might
[21:22] <knome> mh
[21:22] <balloons> http://doc.bazaar.canonical.com/beta/en/user-guide/shelving_changes.html
[21:22] <balloons> ty google... well kids we've learned something
[21:33]  * Noskcaj wants to help with alpha 2 but his internet is too slow
[21:41] <knome> Noskcaj, alpha 2 is released
[21:41] <knome> balloons, teaser: i'm doing something you'll love.
[21:41] <Noskcaj> knome, My internet is that slow i didn't know. Dial-up is faster
[21:42] <phillw> Noskcaj: I moved your testdrive hackfest from having been run, to coming up on https://wiki.ubuntu.com/QATeam/Hackfest
[21:43] <phillw> I guessed you were having what we call a 'blonde moment' :)
[21:44] <Noskcaj> i blame the lack of other hackfests
[21:44] <knome> Noskcaj, no problem to be sorry, just letting you know
[21:44] <Noskcaj> ok, thanks
[21:45] <Noskcaj> i can't acually open the page to check that's what you are doing. IRC + apt-get update as flooded my connection
[21:45] <phillw> balloons: can you edit the topic to reflect this fact please :)
[21:45]  * Noskcaj stop complaining
[22:01]  * balloons was making dinner
[22:01] <balloons> knome, what are you doing?
[22:01] <knome> balloons, it's a teaser - i'm not telling you :P
[22:01] <balloons> Noskcaj, I didn't have the heart to tell you, I was going to silently update the topic
[22:01] <balloons> knome, nice!
[22:06] <phillw> the 3.10.0.5 kernel is looking good! (we'll gloss over the -4 version)
[22:31] <knome> balloons, ready?
[22:31] <balloons> ohh teaser already?
[22:31] <knome> nope.. the real thing!
[22:31] <knome> temp.knome.fi/qa/product_chart.png
[22:32] <knome> do you think something like that could help people understand the administration for the trackers?
[22:33] <balloons> knome, a data flow..
[22:33] <balloons> nice
[22:33] <balloons> I do like :-)
[22:33] <knome> actually, the owner should be blue background
[22:33] <knome> updated
[22:34] <balloons> btw, serie is interesting.. I think most would still say series
[22:34] <knome> balloons, ah, sure.
[22:34] <knome> updated
[22:36] <balloons> indeed, I believe english is series, with the plural of series...
[22:36] <balloons> <3
[22:36] <knome> yes, english is weird
[22:36] <balloons> otherwise, let's see.. is the testcase on the left colors reversed?
[22:36] <balloons> shouldn't hte core testcase be specific, while the other be shared potentially
[22:36] <balloons> testcase (core application) be blue
[22:36] <knome> well, no
[22:36] <balloons> and testcase be yellow?
[22:36] <knome> core application could be xfce terminal
[22:36] <knome> which is both in ubuntu studio and xubuntu
[22:37] <balloons> right.. so what's the blue one? just showing there is potential for specifics?
[22:37] <knome> i'm saying *core* application, because package tests generally do not belong to the ISO tracker
[22:37] <balloons> Also the download information is specific to a product
[22:38] <knome> yes... but it's generated from a template that is the same for all products
[22:38] <balloons> everything else makes sense
[22:38] <balloons> fair enough I suppose ;-)
[22:39] <knome> i would imagine this chart being shown with some text... which can explain things
[22:42] <knome> i can also share the svg sources to that file, if you want to modify it
[22:43] <knome> balloons, http://temp.knome.fi/qa/product_chart.svg
[22:43] <balloons> knome, yes a little text would help
[22:43] <balloons> I like dataflow diagrams and I think this handles that nicely
[22:44] <knome> imo, if you can't explain something by such, the thing is too complicated or has too many exceptions
[22:45] <knome> we even explain the whole development cycle by one..
[22:46] <knome> https://pbs.twimg.com/media/AsQOIw1CQAAIKQF.png
[22:47] <phillw> balloons: I know you're busy, but https://wiki.ubuntu.com/QATeam/Drinking%20our%20own%20champagne is ready for perusal when you get time (I know the link to the forum isn't working, as the forum is still down).
[22:47] <balloons> phillw, :-)
[22:47] <knome> what a silly page name
[22:48] <phillw> knome: http://en.wikipedia.org/wiki/Eating_your_own_dog_food#Criticism_and_alternative_terms :D
[22:49] <knome> sure sure
[22:49] <phillw> uubntu produces a champagne of O/S... I see no problem, but the page name can be changed :)
[22:50] <knome> i'm not the one to critisize that, but i'd imagine there are more meaningful page names (with no spaces too)
[22:51] <phillw> knome: it will be a link from https://wiki.ubuntu.com/Testing/Activities so the fact it has an untidy looking link when pasted up, will not matter :D
[22:53] <knome> it does, if you point to it from outside the wiki
[22:53] <balloons> true
[22:53] <phillw> knome: I'm open to ideas :)
[22:53] <balloons> we could be more specific
[22:54] <balloons> running the development release
[22:54] <phillw> do you prefer icecreaming?
[22:54] <knome> phillw, i prefer anything non-analogous
[22:54] <phillw> okies, I'm quite happy with what people are happy with.
[22:54] <knome> RunDevelopmentVersionYourself or sth.
[22:55] <knome> that's long, but way easier to understand than something about champagne
[22:56] <phillw> RuuningTheDevelopmentRelease ?
[22:56] <phillw> *RunningTheDevelopmentRelease*
[22:56] <knome> to me, that implies instructions on *how* to run the devel ver...
[22:56] <knome> and it's not a release, it isn't out yet, it's a version
[22:57] <phillw> RunningTheDevelopmentVersion
[22:57] <knome> RunThe... would be better
[22:57] <knome> if it's about why you should run, not how you run
[22:59] <phillw> RunTheDevelopmentVersion
[22:59] <knome> that sounds good to me
[22:59] <phillw> it covers both why and some instructions on how to update, use of PPA's
[23:00] <knome> mhm
[23:00] <phillw> knome: have a read of the page, it is an alpha release of 'smoke testing' 'dogfooding' etc.
[23:00] <balloons> I agree, we can use the term, but let's keep the page name specific to what it is
[23:00] <balloons> and yes, even dogfooding can confused
[23:01] <balloons> but I'm ok with using the term on the page phillw :-)
[23:01] <knome> i would say RunThe... can cover both why and how
[23:01] <balloons> and drinking champange is fine
[23:01] <phillw> I'd never heard of that term, balloons I had to look it up with google!
[23:02] <knome> lol
[23:02] <phillw> So, does it stay champagne themed for what we produce (with spaces) or does it go RunTheDevelopmentVersion ?
[23:03] <knome> 02:00  balloons: I agree, we can use the term, but let's keep the page name specific to what it is
[23:03] <phillw> or, s
[23:03] <knome> phillw, pay attention!
[23:04] <phillw> as a mid point DrinkingOurChampagne ?
[23:04] <phillw> *DrinkingOurOwnChampagne*
[23:04] <knome> that still doesn't explain the page to somebody who is unfamiliar with the term
[23:05] <knome> if i had a contact page for the qa team, i'd call it QA/Contact, not QA/WillyNillys even if we called each other willynillys
[23:05] <phillw> knome: that will be done on https://wiki.ubuntu.com/Testing/Activities where I will also mention that it is referred to as smoke testing, dogfooding etc!
[23:05] <knome> phillw, page content != URLs
[23:06] <knome> urls can appear out of context
[23:07] <balloons> phillw, right, I think it best to go with what knome is suggesting and keeping the URL sane
[23:09] <phillw> knome: indeed they can, but from a media side, the phrase 'drinking our own champagne' has a much better feel than, for example. dogfooding. If we are confident enough in our own system to use it to test our own system and produce a champagne quality release each cycle. But... I only help write the content... I'll cancel the request for a nice icon for the page.
[23:10] <knome> phillw, neither me or balloons is saying we can't use the term in the page itself
[23:10] <knome> phillw, we're just saying it's better keep the page names sensible so that they are self-explanatory for anybody seeing the URL
[23:11] <balloons> right exactly.. nothing has to change on the page, just make the url a little saner
[23:11] <phillw> okies :D
[23:11] <balloons> dogwalking time
[23:11] <balloons> ttyl!
[23:11] <phillw> rename to RunTheDevelopmentVersion
[23:12] <phillw> ??
[23:12] <balloons> +1 from me
[23:12] <knome> phillw, that sounds like a plan
[23:12] <knome> balloons, have fun :)
[23:13] <phillw> https://wiki.ubuntu.com/QATeam/RunTheDevelopmentVersion
[23:14] <phillw> I'll edit the top bit to explain the various terms that we know about such a system :)
[23:19] <knome> :)
[23:21] <phillw> knome: balloons https://wiki.ubuntu.com/QATeam/RunTheDevelopmentVersion and you can remove the spiel if you want, but I think that letting people know that we ARE a good O/S does not get mentioned enough :)
[23:27] <knome> phillw, i'm completely fine with analogies in the page content
[23:28] <phillw> i also did go in change the mention of dev release to dev version, after I posted the revised link up.... I'm about wiki'd out now.. been quite a day with the last minute respins of lubuntu alternate, release notes etc :D
[23:29] <knome> yeah.
[23:29] <knome> been a long but productive day for me too
[23:33] <phillw> I,m still kicking myself for not realising the -5 kernel didn't get into the lubuntu alternates and it caused grief for our testers as they sought (and found) a way round it. But, these things happen and it will not happen again :)
[23:34] <knome> it was just an alpha...
[23:34] <knome> we have a few nasty bugs as well, but at least we now know they exist
[23:35] <phillw> having testers spend their time working a way around a problem that shouldn't have been there is annoying to me.
[23:35] <knome> sure
[23:35] <knome> doesn't that description fit to any bug? :)
[23:36] <phillw> as lubuntu looks pretty stable now (famous last words), I'll ask if any of the testers can also help out on xubuntu and ubuntu-gnome come beta 1.
[23:37] <knome> thanks!
[23:37] <phillw> we're all family, and here to help each other.
[23:37] <knome> sure
[23:37] <knome> we're much stronger now than a few releases ago regarding testing, which is good
[23:40] <phillw> the saying is "bums on seats", it is a never ending cycle of recruiting new testers. for this reason whilst some may think I have vanished from the radar, I and Nicholas have spent some considerable man hours on getting https://wiki.ubuntu.com/Testing/Activities into something that  a new commer would not run away from :P
[23:40] <knome> yup
[23:41] <knome> though by "we" i was referring to xubuntu separately this time ;)
[23:41] <knome> but yeah, the whole QA community has grown as wel
[23:41] <knome> well
[23:42] <phillw> yup, we have 109 members on https://www.facebook.com/groups/UbuntuQA/ who may, or may not be active. But social media is another way to reach out to people.
[23:42] <knome> from my experience, social media is fine for things that aren't too serious
[23:42] <phillw> +1
[23:43] <knome> i won't count on anybody coming from social media to deliver any even partly critical features
[23:43] <knome> not saying people can't grow to be part of the team, but that's my initial level of expectations
[23:43] <phillw> it is, however a good way for people to 'dip their toe in the water'...
[23:43] <knome> definitely
[23:44] <knome> but then you must also feed them fruit that are low-hanging enough
[23:44] <knome> (to continue with the analogies)
[23:46] <phillw> absolutely! I saw on ubuntu-bugs today such an event. A guy had proposed a bug fox for a typo. His 1st ever proposed fix. The attitude of the person dealing with him was critical. As it was TLoT on #ubuntu-bugs , the guy has gone away very happy and more confident.... little things like that make a massive difference.
[23:47] <knome> yup
[23:47]  * TheLordOfTime was pinged
[23:47] <TheLordOfTime> phillw:  he didn't propose the fix, it was already accepted :P
[23:47] <TheLordOfTime> he wanted the fix upstreamed is all.
[23:47] <phillw> TheLordOfTime: no, we were talking about you, not TO you :D
[23:48] <TheLordOfTime> ah
[23:48] <TheLordOfTime> still, YOU PINGED ME :p
[23:48]  * TheLordOfTime goes back to ignoring IRC and spending time on the beach with a drink
[23:48] <phillw> TLoT pings you?
[23:48] <TheLordOfTime> yep
[23:48] <TheLordOfTime> it's in my highlights list
[23:48] <phillw> not my fault :D
[23:48] <TheLordOfTime> no... but you pinged me.
[23:48] <TheLordOfTime> xD
[23:48] <TheLordOfTime> this is going to end up a cyclic conversation so... ;P
[23:49]  * TheLordOfTime goes back to enjoying the beach.
[23:51] <phillw> knome: like you, he is so technical in his descriptions etc... IDK, I see areas of grey on releases, not pure black and white.
[23:51] <knome> ;)
[23:51] <knome> the more to-the-point and self-explanatory you can be, the better
[23:52] <phillw> I'm not quite sure what kate would have said if I did a respin a couple of hours before release and not have time to fully test :D
[23:54] <phillw> The thing there was that I knew (with as much certainty as any one can) that doing amounts to an SRU onto the ISO would be fine.
[23:56] <knome> heh
[23:56] <knome> i did do this "i know it's after UI freeze, but can we change our logo" for the 12.04 LTS...