=== czajkows1i is now known as czajkowski
=== manjo` is now known as manjo
cr3fader_: hey dude, might you have a moment to pick your brains again about reporting test results?14:56
fader_cr3: Not right this second... can I ping you this afternoon?14:57
cr3fader_: sure14:57
cr3fader_: wait, you're actually busy or just pretending? :)14:57
fader_cr3: Cool, ping me if I forget :)14:57
fader_cr3: Lots of meetings today :/14:57
cr3fader_: I feel for you man, may the force be with you14:57
* fader_ hugs cr3.14:57
fader_cr3: I have a couple of minutes now... what's up?15:41
cr3fader_: ok, so yesterday, we talked about targetting test results to the finnest grain: project series and distro arch series, for example15:44
cr3I incremenent a sequent sequence number within each target, so that you can easily refer to each test run15:44
cr3for example, you might have /ubuntu/lucid/i386/testrun/1 and /ubuntu/lucid/amd64/testrun/1, which would refer to different test runs because the targets are different15:45
cr3make sense so far?15:45
fader_Yep, with you so far15:45
davmor2cr3: he isn't his eyes are all glazed over honest15:46
cr3fader_: so, my concern is related to usability when generating coarser grained reports where /ubuntu/lucid/testruns would have duplicate sequence numbers, albeit for different architectures15:47
fader_cr3: How exposed to the end user are these URLs (or whatever) going to be?  If there is a reasonable UI for navigating results I think it won't be as big a deal15:48
fader_i.e. anyone who is at the level of hacking on the URL to get the data they want will likely understand what's going on15:48
cr3fader_: I want the urls to be meaningful and paste friendly, I'm usually quite picky about that15:49
fader_If there's a UI that lets me as a user say "I want to see the test results for all architectures on this test run" and not manually build a URL, I won't be confused15:49
fader_cr3: My gut feeling is that you're still okay with this, even with duplicate sequence numbers15:49
cr3fader_: however, even outside the urls, I can see myself exposing the sequence number just like launchpad does for bug numbers15:49
cr3fader_: have a look here for example: http://ec2-50-18-75-140.us-west-1.compute.amazonaws.com/checkbox15:49
fader_You could always go with some sort of GUID or alplanumeric that's obviously not a sequence number, which solves this conceptually but breaks predictability for other tools15:50
cr3fader_: this is for a project target, but you could imagine there might be duplicate sequence numbers in the future when I target to project series and same would apply to distroarchseries of course15:50
cr3fader_: I made special effort to make that sequence number context specific to be meaningful, it's not just a straightforward database primary key15:51
fader_cr3: Have you considered the launchpad approach of never repeating sequence numbers at all?  There's only one bug 12345, not a bug 12345 in checkbox and a different bug 12345 in gwibber15:51
ubot4Launchpad bug 12345 in isdnutils (Ubuntu) "isdn does not work, fritz avm (pnp?) (heat: 4)" [Medium,Fix released] https://launchpad.net/bugs/1234515:51
fader_Or isdnutils in this case ;)15:51
infinityfader_: Actually, the LP bug approach is the have subtasks on a single bug, to be fair.15:51
fader_infinity: Indeed, but those aren't given numbers that are exposed to the user, at least that I can see15:52
infinityfader_: Which gives you /ubuntu/lucid/testrun/1/amd64 and /ubuntu/lucid/testrun/1/i386, conceptually.15:52
cr3fader_: I see test runs as flyweight bugs, much lighter and therefore likely to be far more numerous15:53
infinityfader_: (ie: sequence re-use is still there, but you're making the arch/task a child of the sequence instead of a parent, eliminating the illusion of duplicates)15:53
fader_infinity: I suspect that breaks cr3's model, but I'll let him fight you or not as he chooses :)15:53
infinitycr3: You're probably seeing them less as bugs at all, and more like build records (again, looking at it from LP's external UI's POV)15:54
fader_cr3: Let me think about it for a bit.  I suspect I'll still come back and say that I don't think it's really a problem, but maybe I'll change my mind.15:54
cr3infinity: unfortunately, I'm not familiar with build records, I've mostly been inspiring myself from lp.(registry|bugs|answers)15:54
cr3infinity: how can I get a quick idea of how build records work?15:55
infinitycr3: Well, you have one source record, representing the actual source upload (or, perhaps from your POV, one testrun)15:56
infinitycr3: Then multiple build records, one per DAS.15:56
infinityFor example.15:56
infinityThe URIs are horribly undiscoverable, and that's (I'd argue) a design flaw.15:57
infinityBut it would be easy enough to solve, to just not expose the PK in the URI design by default.15:57
cr3infinity: that bigass number at the end is just the same postgres SERIAL used across all builds, right?15:57
infinitycr3: Yeah.15:57
cr3infinity: I like my urls to have some level of predictability and, looking at how people work, it seems that lots of people like to play with them15:58
fader_Ugh, on reflection I do start to see how this could be confusing if you don't actually care about the arch... I'd have two (or more) testrun/1 results in the same report and that is just weird15:58
fader_But I think you're in a rock and a hard place here... predictable URLs or sensible sequential numbering15:58
infinityAnyhow, I would never suggest anyone duplicate soyuz UI design, cause it had none. ;)15:58
cr3infinity: so, since I'm trying to represent test runs in a launchpad'ish way, I think it would be nice for someone to see /checkbox/testruns/1 and just change the number if they want15:58
infinityMore just implying that your one-to-many and many-to-one can be swapped to perhaps make things more intuitive, if that makes sense.15:59
cr3s/in a launchpad'ish way/in a launchpad'ish way for those things that were actually designed/15:59
fader_infinity: But I think you'd have to keep popping back farther and farther... what if you don't care about the distro series either?16:00
fader_Or even worse, testrun/1/ubuntu/lucid/i38616:00
fader_If there were only one way you'd care to slice and dice the data it'd be pretty trivial, but I'm not sure that's the case16:01
cr3fader_: launchpad pillars dictate that the beginning of the url must refer to one of: product, product group, distro, ~person, ~team, +action16:02
cr3fader_: I've yet to come across anything useful being trivial to come up with, even pie was probably not easy as pie (that sucked) to come up with16:03
fader_cr3: But LP uses unique IDs down those pillars, which you're looking to avoid, right?16:04
cr3fader_: just because I'm dealing with a different scale, like those builders pointed out by infinity, showing a number like 2581141 for the first testrun of a projectseries or a distroseries seems weird16:05
cr3fader_: I'm also dealing with a different target audience, people don't really look at builders whereas I'm hoping people will care enough about the quality of ubuntu to look at test results. that still remains to be seen though, I might find out people only care about what doesn't work rather than what also works16:07
fader_cr3: I don't know that it looks any weirder than showing a number like 2581141 as the first bug of a project16:07
* cr3 still needs to think about actionable outcomes from testing, like this area of ubuntu has been demonstrated to be in dire need of testing...16:08
cr3fader_: bugs are a bit different though because of the relationship between bugs and bug tasks: bugs can be retargetted whereas testruns cannot, they are a snapshot in time16:08
fader_cr3: Hmm, so in your URL examples above, is the "1" the testrun ID and then would have result IDs beneath it?  e.g. /ubuntu/lucid/i386/testruns/1/results/116:11
cr3fader_: I'm not sure yet but I'm thinking of using a sequence number on a target basis for test runs but the test case name for test results16:15
cr3fader_: ie, something users have the most chance of understanding some meaning16:15
fader_cr3: Yeah, I'm going back to "let me think about it".  I don't immediately see a way of solving this for the general case in a way that satisfies your deep need for pretty URLs16:16
cr3fader_: at the risk of overthinking this, I could also get some implementation out the door and we could then try kicking the tires a bit16:17
fader_cr3: True, it may not really be that big a deal16:18
fader_Get Charline to do some user testing :)16:18
cr3I like what Jamu once said: designing is expensive, refactoring is cheap. unfortunately, that takes most of the fun out of my work16:18
cr3fader_: I'm not a big fan of the usability testing done in millbank, it's all very ivory tower. we should be able to do usability testing ourselves with the help of the community, it might not be as perfect as done by experts but we'll certainly find a few low hanging fruits16:19
cr3fader_: I actually did some usability testing during the rally in dublin and it turned out very well16:20
cr3fader_: next time, I'll try remote usability testing... can't wait!16:20
fader_Okay, lunchtime for me16:24
=== pace_t_zulu_ is now known as pace_t_zulu
=== yofel_ is now known as yofel
=== skaet is now known as skaet_afk
=== skaet_afk is now known as skaet
=== cking is now known as cking-afk
hakimsheriffHello everybody22:36

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!