[14:56] <cr3> fader_: hey dude, might you have a moment to pick your brains again about reporting test results?
[14:57] <fader_> cr3: Not right this second... can I ping you this afternoon?
[14:57] <cr3> fader_: sure
[14:57] <cr3> fader_: 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] <cr3> fader_: I feel for you man, may the force be with you
[14:57]  * fader_ hugs cr3.
[15:41] <fader_> cr3: I have a couple of minutes now... what's up?
[15:44] <cr3> fader_: ok, so yesterday, we talked about targetting test results to the finnest grain: project series and distro arch series, for example
[15:44] <fader_> Right
[15:44] <cr3> I incremenent a sequent sequence number within each target, so that you can easily refer to each test run
[15:45] <cr3> for 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 different
[15:45] <cr3> make sense so far?
[15:45] <fader_> Yep, with you so far
[15:46] <davmor2> cr3: he isn't his eyes are all glazed over honest
[15:47] <cr3> fader_: so, my concern is related to usability when generating coarser grained reports where /ubuntu/lucid/testruns would have duplicate sequence numbers, albeit for different architectures
[15:48] <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 deal
[15: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 on
[15:49] <cr3> fader_: I want the urls to be meaningful and paste friendly, I'm usually quite picky about that
[15: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 confused
[15:49] <fader_> cr3: My gut feeling is that you're still okay with this, even with duplicate sequence numbers
[15:49] <cr3> fader_: however, even outside the urls, I can see myself exposing the sequence number just like launchpad does for bug numbers
[15:49] <cr3> fader_: have a look here for example: http://ec2-50-18-75-140.us-west-1.compute.amazonaws.com/checkbox
[15:50] <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 tools
[15:50] <cr3> fader_: 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 course
[15:51] <cr3> fader_: I made special effort to make that sequence number context specific to be meaningful, it's not just a straightforward database primary key
[15: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 gwibber
[15:51] <ubot4> Launchpad bug 12345 in isdnutils (Ubuntu) "isdn does not work, fritz avm (pnp?) (heat: 4)" [Medium,Fix released] https://launchpad.net/bugs/12345
[15:51] <fader_> Or isdnutils in this case ;)
[15:51] <infinity> fader_: Actually, the LP bug approach is the have subtasks on a single bug, to be fair.
[15:52] <fader_> infinity: Indeed, but those aren't given numbers that are exposed to the user, at least that I can see
[15:52] <infinity> fader_: Which gives you /ubuntu/lucid/testrun/1/amd64 and /ubuntu/lucid/testrun/1/i386, conceptually.
[15:53] <cr3> fader_: I see test runs as flyweight bugs, much lighter and therefore likely to be far more numerous
[15:53] <infinity> fader_: (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:54] <infinity> cr3: 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] <cr3> infinity: unfortunately, I'm not familiar with build records, I've mostly been inspiring myself from lp.(registry|bugs|answers)
[15:55] <cr3> infinity: how can I get a quick idea of how build records work?
[15:56] <infinity> cr3: Well, you have one source record, representing the actual source upload (or, perhaps from your POV, one testrun)
[15:56] <infinity> cr3: Then multiple build records, one per DAS.
[15:56] <infinity> https://launchpad.net/ubuntu/+source/pidgin/1:2.8.0-1ubuntu1
[15:56] <infinity> https://launchpad.net/ubuntu/+source/pidgin/1:2.8.0-1ubuntu1/+build/2581140
[15:56] <infinity> https://launchpad.net/ubuntu/+source/pidgin/1:2.8.0-1ubuntu1/+build/2581141
[15:56] <infinity> For example.
[15:57] <infinity> The URIs are horribly undiscoverable, and that's (I'd argue) a design flaw.
[15:57] <infinity> But it would be easy enough to solve, to just not expose the PK in the URI design by default.
[15:57] <cr3> infinity: that bigass number at the end is just the same postgres SERIAL used across all builds, right?
[15:57] <infinity> cr3: Yeah.
[15:58] <cr3> infinity: 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 them
[15: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 weird
[15:58] <fader_> But I think you're in a rock and a hard place here... predictable URLs or sensible sequential numbering
[15:58] <infinity> Anyhow, I would never suggest anyone duplicate soyuz UI design, cause it had none. ;)
[15:58] <fader_> Hehe
[15:58] <cr3> infinity: 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 want
[15:59] <infinity> More 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] <cr3> s/in a launchpad'ish way/in a launchpad'ish way for those things that were actually designed/
[16:00] <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_> /ubuntu/testrun/1/lucid/i386
[16:00] <fader_> Or even worse, testrun/1/ubuntu/lucid/i386
[16:01] <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 case
[16:02] <cr3> fader_: launchpad pillars dictate that the beginning of the url must refer to one of: product, product group, distro, ~person, ~team, +action
[16:03] <cr3> fader_: 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 with
[16:03] <fader_> :)
[16:04] <fader_> cr3: But LP uses unique IDs down those pillars, which you're looking to avoid, right?
[16:05] <cr3> fader_: 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 weird
[16:07] <cr3> fader_: 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 works
[16:07] <fader_> cr3: I don't know that it looks any weirder than showing a number like 2581141 as the first bug of a project
[16:08]  * 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] <cr3> fader_: 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 time
[16:11] <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/1
[16:15] <cr3> fader_: 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 results
[16:15] <fader_> Ah
[16:15] <cr3> fader_: ie, something users have the most chance of understanding some meaning
[16:16] <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 URLs
[16:16] <fader_> :)
[16:17] <cr3> fader_: at the risk of overthinking this, I could also get some implementation out the door and we could then try kicking the tires a bit
[16:18] <fader_> cr3: True, it may not really be that big a deal
[16:18] <fader_> Get Charline to do some user testing :)
[16:18] <cr3> I like what Jamu once said: designing is expensive, refactoring is cheap. unfortunately, that takes most of the fun out of my work
[16:19] <cr3> fader_: 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 fruits
[16:20] <cr3> fader_: I actually did some usability testing during the rally in dublin and it turned out very well
[16:20] <cr3> fader_: next time, I'll try remote usability testing... can't wait!
[16:21] <fader_> \o/
[16:24] <fader_> Okay, lunchtime for me
[22:36] <hakimsheriff> Hello everybody