[06:55] <Unit193> knome: Considering perhaps http://paste.openstack.org/show/cZed8nUINAyyEi0HxMKP/
[12:42] <bluesabre> updated gtk-theme-config (with translations) pushed
[12:42] <bluesabre> updated xubuntu-default-settings with drag-workspaces enabled and classic menu fixes pushed
[12:51] <Unit193> Fancy.
[13:03] <knome> Unit193, looks good to me
[13:08] <elfy> knome - started a pad for later - http://pad.ubuntu.com/trackers
[13:08] <elfy> biab
[13:08] <knome> great
[13:12] <Unit193> Benefit is  make test  will fail if validation fails.
[13:15] <knome> yep
[14:35] <eric_the_idiot> Noskcaj, do you have a deadline for a new xfdesktop release date?
[15:32] <ochosi> bluesabre: wow, awesome MR from andrew
[15:58] <knome> good morning pleia2!
[16:01]  * pleia2 yawns and grumps
[16:01] <knome> heh
[16:01] <knome> back in 2 mins.
[16:04]  * elfy is floating about 
[16:05] <pleia2> shall we make an etherpad to collect a bug list?
[16:05] <elfy> http://pad.ubuntu.com/trackers
[16:05] <elfy> :)
[16:06] <pleia2> \o/
[16:06] <pleia2> reading backscroll ftw
[16:06] <elfy> :D
[16:07] <knome> huh, and sorry
[16:08] <knome> ok, so
[16:08] <knome> i made some comments on the pad already
[16:08] <elfy> yep - I added one 
[16:09] <knome> re: that comment
[16:09] <knome> i think it would be generally a good idea that the "history" page was a blank "search page" when opened
[16:09] <elfy> yep
[16:09] <knome> so *no* default loading from the database
[16:10] <knome> then you could also use non-default filters
[16:10] <knome> example:
[16:10] <knome> i usually filter out everything else then xubuntu, but i might want to search for xubuntu and studio
[16:11] <knome> another question
[16:11] <knome> i guess elfy might be able to answer this...
[16:11] <elfy> indeed - I'd generally be wanting say Xubuntu, this month, arch
[16:11] <knome> what's the difference between the "defect summary" and the bug list(s) in the history?
[16:12] <knome> s/arch/testsuite/
[16:12] <knome> IF ONLY that site was running with some code i understand..
[16:12] <elfy> :)
[16:13] <elfy> defects summary includes everything that is currently testable - precise/trusty/utopic
[16:13] <knome> right
[16:14] <pleia2> ah
[16:14] <knome> so the bug lists in the history is a partial grep of the defects summary?
[16:14] <knome> with the information about which *builds* the bugs are filed against
[16:15] <elfy> hang on - which history are you talking about here ?
[16:15] <knome> lol
[16:15] <knome> defects summary: http://iso.qa.ubuntu.com/qatracker/reports/defects
[16:15] <knome> history: "see removed and superseded builds too"
[16:15] <elfy> right 
[16:15] <elfy> yea - as I said :)
[16:15] <knome> yep
[16:16] <knome> because i'm sure showing the bug lists on that view slows it down by far
[16:16] <elfy> just don't know where you are getting the history bug list 
[16:16] <knome> the history shows the bug lists per build
[16:16] <knome> "lists"...
[16:16] <knome> the bug icons
[16:17] <elfy> ok - I thought there was a list I'd never found 
[16:17] <elfy> :)
[16:17] <knome> nope
[16:17] <elfy> right so - difference is as I said - for sure now :p
[16:17] <knome> do you think we *need* the bug icons for each build in the history?
[16:18] <elfy> well I use them 
[16:18] <knome> right
[16:18] <elfy> not as often as I would if it didn't take a week to load though :p
[16:18] <knome> yep
[16:18] <elfy> I'd refer back to last beta at the next one for instance
[16:18] <knome> i dislike the bug icon lists generally...
[16:19] <knome> i would very happily remove them and even replace with something else
[16:19] <pleia2> same
[16:19] <knome> but on the history page... i don't know what would be a sane choice
[16:19] <elfy> well - it's useful to see the number of critical bugs against a particular bug - and it's quick to scan red icons
[16:20] <elfy> s/particular build
[16:21] <pleia2> well, on pages where you don't actually need to read the bugs I can see value
[16:21] <knome> even then it could be *one* icon that opens a tooltip with a list of bugs
[16:21] <knome> in some tabular form
[16:21] <elfy> the majority of the time mouseover bug is sufficient to trigger memory
[16:22] <elfy> and the majority of issues anyone is likely to have will go if you know you're only seeing things you want to - eg xubuntu for us
[16:22] <knome> mmh.
[16:24] <elfy> actually
[16:24] <knome> yes? :)
[16:24] <elfy> if defects summary could be filtered then you'd not need so much on the history imo
[16:24]  * pleia2 nods
[16:24] <knome> yep.
[16:24] <knome> exactly
[16:24] <knome> i'd rather see a list of all bugs
[16:25] <knome> then a column that tells how many builds it affects
[16:25] <elfy> I go to history preferentially - because of that 
[16:25] <knome> that sounds like changing the db structure or doing expensive queries though
[16:25] <elfy> defect summary is a pain unless you've got some idea of bug desc or package
[16:26] <knome> so
[16:26] <knome> maybe we need to file a bug against the defects summary page instead :)
[16:26] <elfy> I was looking for one the other day - didn't find it until I'd found the thing elsewhere and new the number
[16:26] <elfy> yep
[16:27] <knome> actually, i'd really like all of the bug lists to be like that
[16:27] <knome> even in the testcase pages
[16:27] <knome> that's SO much better than the bug icons
[16:27] <knome> and since all the data is loaded and output ANYWAY, it doesn't really make sense to hide the data
[16:27] <elfy> http://iso.qa.ubuntu.com/qatracker/milestones/315/builds/78216/testcases/1303/results
[16:28] <knome> yep.
[16:28] <elfy> so how would you deal with the bugs listed there on the testcase page 
[16:28] <knome> just list them the same way as in the defects summary
[16:28] <elfy> necessarily if it isn't an icon you're going to need to go elsewhere
[16:28] <elfy> unless
[16:29] <knome> and i would make the columns sortable.
[16:29] <knome> maybe i need to do a PoC
[16:29] <elfy> if there was a way for the tracker to recognise that I was on xubuntu testcase and aren't interested in kylin bugs
[16:29] <pleia2> knome: ++
[16:29] <knome> elfy, though you might
[16:30] <elfy> mmm 
[16:30] <knome> i guess the OPTIMAL situation was
[16:30] <knome> only show bugs that are reported against the current product
[16:30] <knome> and then a link that says "Show all bugs"
[16:30] <elfy> I can just see a page with bugs listed - even if you could sort them - going to be a long list and long page
[16:30] <knome> that asynchronosly loaded the rest
[16:30] <knome> elfy, to me, that's better than the bugs list now
[16:31] <knome> and as i proposed in the pad
[16:31] <knome> there should be a button to add to the critical bugs/bugs list
[16:31] <knome> so you could practically go through the list
[16:31] <pleia2> yeah
[16:31] <knome> and clickety-click
[16:31] <pleia2> right now it's very awkward x_x
[16:31] <elfy> that would work it seems
[16:32]  * knome checks the tracker code
[16:33] <elfy> pleia2: if you don't know the bug numbers and are dipping in and out - which the majority of people do - I would agree
[16:34] <pleia2> even if you know the bug numbers, I don't want to type it :)
[16:35] <elfy> well I don't clear stuff on this browser - so I tend to have groups of bug numbers in there - and I just start typing and bob IS my uncle - there is the group of bugs I need to report again ;)
[16:35] <pleia2> you are a testing machine
[16:36] <elfy> not so much this cycle 
[16:36] <pleia2> anyway, yeah, a newcomer won't have that, and I didn't so much
[16:36] <elfy> yep
[16:36] <elfy> a *list* on the tracker page would work better 
[16:37] <knome> hrr hrr.
[16:37] <pleia2> a list, then you click on the + button to add it to the bugs list
[16:37] <elfy> filtering on defect summary would be awesome - more awesomer than history - but history still needs it
[16:38] <elfy> so a new bug for the defect summary so far 
[16:39] <knome> and we probably need a new bug for the testcase pages as well
[16:40] <knome> to use the bug table instead of the bug icons
[16:41] <elfy> I mean ... 
[16:42] <elfy> defect summary has bugs for Precise Alpha 1 on it ... 
[16:42] <knome> yes
[16:42] <elfy> and one of those goes back to natty lol
[16:43] <knome> :P
[16:45] <pleia2> hah
[16:45] <elfy> defects summary - small issue - but what do the column title mean
[16:47] <elfy> I guess com is comments, sub is subscribed, dup duplicates
[16:47] <knome> yes
[16:47] <elfy> wouldn't bug heat be more useful than knowing who many comments there were 
[16:47] <knome> yes
[16:48] <knome> or simply the status
[16:48] <elfy> and what use is dupes if there's nothing to say which dupes
[16:48] <knome> well, you can go to LP and look
[16:48] <elfy> dupe adds heat anyway
[16:48] <knome> yes
[16:48] <elfy> as does subscribers 
[16:48] <knome> i agree showing heat would be better than showing those columns
[16:49] <knome> same with the bug tooltips
[16:50] <elfy> I'm happy to do the bugs for this - but for defect summary - 1 bug with a list? seperate bugs for each issue?
[16:51] <knome> i'd say just one bug is enough
[16:51] <knome> once you've filed the bugs, i can comment/edit the descriptions :)
[16:51] <elfy> lol
[16:51] <knome> i mean, to fill in details
[16:52] <elfy> ha ha ha 
[16:54] <elfy> does that cover defects summary and testcase report 
[16:56] <pleia2> hopefully
[16:56] <pleia2> what else?
[16:57] <elfy> not thinking of anything else
[16:57] <pleia2> I think the etherpad pretty well describes the issues I've been having
[16:57] <elfy> ok
[16:58] <pleia2> separately, would be nice to add some bug reporting tips to some of our testcases
[16:58] <pleia2> we can do that though :)
[16:59] <pleia2> most new people will have no idea what ubiquity is, for instance
[16:59] <pleia2> so adding some tips around installer instructions with "if you find a bug here, submit bug against ubiquity"
[16:59] <pleia2> I still find the bug reporting to be the hardest part of the process :\
[17:00] <elfy> pleia2: so do I ;)
[17:01]  * pleia2 just comes in here and asks
[17:01] <pleia2> :)
[17:01] <elfy> though tbh my pet hate are people who mark an install testcase as failed because they've got an issue with a package somewhere
[17:01] <pleia2> well, to be fair, there isn't great documentation about what passed/failed means afaik
[17:02] <pleia2> maybe some info about that in the tracker too!
[17:02] <elfy> pleia2: so a bit of expansion on problems encountered ...  list?
[17:02] <pleia2> well, more like an info clicky thing on each of the fields in the tracekr
[17:03] <pleia2> I know there's a bug out there for "Hardware profile"
[17:03] <pleia2> https://bugs.launchpad.net/ubuntu-qa-website/+bug/1017207
[17:03] <pleia2> so pretty much that for all of them
[17:03] <elfy> pleia2: saw that this morning when I was looking at the list - I never ever use that thing
[17:04] <pleia2> exactly
[17:04] <elfy> officially - if something doesn't do EXACTLY as the testcase says it should be a fail
[17:05] <pleia2> sure, *I* know that :)
[17:05] <elfy> any lubuntu/xubuntu/ubuntu test at the moment should be a Fail as they all have the cangraphical-=no issue :)
[17:05] <pleia2> indeed
[17:05] <elfy> if you do it via vbox at least 
[17:06] <pleia2> is there a writeup anywhere about what these fields mean?
[17:06] <elfy> hard to know what to write - people have failed installs because the box with the writing goes full screen width 
[17:06] <pleia2> or should we write them and voluntell knome to make a patch to link to descriptions
[17:06] <bluesabre> ochosi: indeed, we should test it out and see if there are any glaring issues
[17:07] <pleia2> (or if it doesn't seem important, ok, but it can be tricky to know what each field means for new folks and this seems like an easy-ish one to fix)
[17:07] <elfy> pleia2: I'm not even sure how to go about it - I'd pass for things other people would fail critically
[17:07] <pleia2> yeah, that seems like a problem
[17:08] <elfy> and then is the fail because it's a fail, or because the testcase is not quite right
[17:09] <knome> pleia2, aha :)
[17:09] <pleia2> knome: <3
[17:10] <knome> pleia2, any idea what " URL: depends on the underlying entry " means on the LP api?
[17:10] <knome> how do i figure out the URL?
[17:10] <pleia2> lp api lol
[17:10] <pleia2> so no, not so much
[17:10] <pleia2> its error messages always confound me
[17:13] <pleia2> knome: so, think you can draw me some pretty pictures to show balloons this week re: defects/reports
[17:14] <knome> no idea
[17:14] <pleia2> haha
[17:14] <knome> when do you meet him?
[17:15] <pleia2> we're doing a presentation together on Thursday at Ubucon, but I'm sure I'll be seeing him Thurs-Saturday
[17:15] <pleia2> haven't firmed up a time to chat QA yet
[17:15] <knome> oh
[17:15] <knome> then probably
[17:15] <knome> but... no hard promises
[17:15] <pleia2> ok
[17:15] <pleia2> I'll do my best to describe if I have no visual aids :)
[17:19] <pleia2> alright, if we're done here it's time for me to go out for a run
[17:19] <elfy> have fun pleia2 - thanks :)
[17:20] <pleia2> thanks :)
[17:23]  * knome facepalms
[17:23] <elfy> knome: go for your life bug 1366579
[17:24] <knome> lol
[17:29] <elfy> ripped the testcase page stuff from the pad :)
[17:31] <elfy> bug 1366581
[17:31] <elfy> biab 
[17:48] <knome> https://api.launchpad.net/1.0/ubuntu?ws.op=searchTasks&tags=[%22iso-testing%22,%22trusty%22]&tags_combinator=All&importance=Critical
[17:48] <knome> json for all critical bugs filed against trusty and reported in the iso tracker
[17:49] <knome> doesn't take long to grep that list
[17:49] <knome> if we only had tags for products and builds, we could create our own lists
[17:49] <knome> builds would be overkill, granted...
[17:50] <knome> but product would be good
[18:26] <brainwash> bluesabre: you didn't add a comment to bug 1357090 yet, are you maybe confused by the comments like I am? this whole report is just meh
[18:29] <brainwash> black screen on lid close.. black screen on logout.. :D