[11:43] <bac> morning gmb.  so the forced build has already failed?
[11:43] <gmb> bac: Really? I hadn't looked at it since I forced it; been going through the review queue.
[11:43] <bac> or am i reading the waterfall wrong?
[11:44] <gmb> bac: The bit at the top refers to the last build, not the current one.
[11:44] <gmb> It's still building.
[11:44] <gmb> Though I'm going to check the output now that you've mentioned it :)(
[11:44] <bac> i ran another branch through ec2 last night and got a single failure of xx-front-page-bug-lists.txt.  didn't you make a change about ordering of front page bugs?
[11:44] <bac> i notice that test was a failure in the buildbot output too
[11:44] <bac> but, i cannot reproduce it locally
[11:47] <bac> gmb: ^
[11:48] <gmb> bac: Hmm. I didn't spot it in the buildbot output but I didn't look much further than the bzr errors. I wonder if my testfix might turn out to be timebomb. I'll check.
[11:49] <bac> gmb: it just looked like an issue with the output ordering
[11:50] <gmb> bac: Yeah, that's what I mean. I changed the order by on the query but it's now ordering by bug.datecreated, which is more volatile than (datecreated, id). I might need to change the test to not echo out bug ids.
[11:52] <gmb> bac: Annoyingly, of course, it passed ec2. Oh well.
[11:53] <gmb> bac: http://pastebin.ubuntu.com/372418/ stop the test from blowing up, though it no longer tests the ordering of the results (though we don't really care all that much about the ordering of those five bugs as long as they're the most recently filed).
[11:53] <gmb> bac: Is that worth landing or should I come up with another solution?
[12:05]  * bac looks
[12:06] <bac> gmb, i haven't looked at the test in detail but why do you say datecreated is more volatile?  don't you know the creation order?
[12:09] <gmb> bac: Ideally, yes, but if that test is really timebombing in production then evidently there's something going on that we don't know. Also, the order should be linear - 1, 2, 3, 4, 5 - but if you look at the test, it's not. That was a change I made after chaning the query ordering; I should really have spotted the potential timebomb then.
[12:09] <gmb> bac: I need to investigate this more, because that ordering is plain weird.
[12:09] <gmb> But I'm concerned that leaving things as they are will leave the build broken, or at least very susceptible to breakage
[12:10] <bac> gmb: right, i think it needs some investigation.  i'd hate to put in a test fix that masks a real problem, of course.  but if it's just a testing issue then your fix is good.
[12:11] <gmb> bac: Yeah. I think we should land the elided version of the test and then find out what's causing the ordering oddness and deciding whether we care.
[12:11] <bac> ok
[12:11] <gmb> bac: So can I do that with your r=?
[12:12] <gmb> (I'll file a bug to track the ordering problem)
[12:12] <bac> yes
[12:12] <bac> oh, and happy birthday!
[12:13] <gmb> Thanks :)
[12:47] <bigjools> gmb: I have a birthday present for you
[12:48] <bigjools> a 3524 line Soyuz branch :D
[13:26] <gmb> bigjools: Laugh? I nearly herniated.
[13:27] <bigjools> gmb: I wouldn't spend too much time doing details on it - it's a very mechanical change
[13:27] <gmb> bigjools: I'll have a quick glance, but I think you're right. As long as the tests pass and dogfood doesn't melt or something...
[13:27] <bigjools> well dogfood melts a lot anyway :)
[13:29] <gmb> bigjools: Land it :)
[13:29] <bigjools> quicker 3k5 branch review evar
[13:29] <bigjools> quickest*
[13:30] <bigjools> don't say I never give you anything on your birthday
[13:43] <gmb> bigjools: Indeed.
[13:45] <bac> gmb: so what's going on with buildbot and bzrlib?
[13:46] <gmb> bac: WTH... apparently nothing.
[13:46] <gmb> It seems to be stuck.
[13:46] <bac> gmb: but there is now a version imcompatability, right?
[13:47] <leonardr> rockstar: see my latest comment on https://code.edge.launchpad.net/~leonardr/lazr.restful/multiversion-pagetest/+merge/18868 when you come in
[13:48] <gmb> bac: Yes, it looks that way. I'll speak to a LOSA.
[16:07] <rockstar> leonardr, actually, that would be a problem, wouldn't it?
[16:08] <rockstar> beta should be newer than 3.0, which is newer than 2.0, etc.
[16:08] <leonardr> rockstar: actually beta is the _earliest_ version, but 3.0 is newer than 2.0, etc
[16:08] <rockstar> leonardr, what is meant by "earliest" though.
[16:08] <rockstar> It shouldn't mean that 1.0 overrides it.
[16:09] <leonardr> rockstar: well, right now launchpad has a 'beta' web service and nothing else
[16:09] <leonardr> now that i have multi-version working i'm going to create a '1.0' version that's different
[16:09] <rockstar> leonardr, yes, but then we'll go 1.0, and beta will be what 2.0 is created from.
[16:09] <leonardr> that's what i mean by saying beta is the earliest
[16:09] <leonardr> rockstar: no, we do have a 'floating development version', but in launchpad's case that is called 'trunk'
[16:10] <leonardr> 'beta' is a specific version
[16:10] <leonardr> that will become obsolete and stop changing
[16:10] <rockstar> leonardr, huh, that's odd.
[16:11] <rockstar> leonardr, okay, I guess it makes sense to have 1.0 supersede beta then.
[16:11] <leonardr> rockstar: if you are confused it's likely others will be confused and think that 'beta' is the permanent cutting edge
[16:11] <leonardr> but i don't know what we can do about that
[16:11] <leonardr> it's more like gmail, which was in 'beta' for 5 years and now it's not
[16:12] <leonardr> the only differnece is that we have to keep 'beta' around for a while
[16:13] <rockstar> leonardr, yeah.  Having worked on the other side of the REST API (on Tarmac), when the API changes now, baby Jesus cries.
[16:13] <leonardr> thus the multi-version project
[16:13] <rockstar> leonardr, I think "trunk" for bleeding edge is probably misnamed, since it's likely it could be in production as "trunk"
[16:13] <leonardr> rockstar: it's not too late to change it
[16:14] <leonardr> if you have a better idea
[16:14] <rockstar> leonardr, well, just what I was assuming where beta is the floating development version.
[16:14] <leonardr> my only alternative is 'dev' or 'development'
[16:15] <rockstar> leonardr, are we going to release an API version on every release of Launchpad?
[16:15] <leonardr> rockstar: no, API versions will correspond roughly with ubuntu releases
[16:15] <leonardr> and will be retired at the same rate as ubuntu releases
[16:15] <rockstar> Ah, okay.
[16:16] <rockstar> So maybe "dev" would be appropriate, since (at this point in time), it would correspond to the scripts in Lucid.
[16:17] <leonardr> flacoste: ^- what do you think?
[16:17] <leonardr> incidentally, flacoste, the multiversion lazr.restful work is complete as of yesterday
[16:33] <flacoste> leonardr: i saw good progress on that, great! but complete? i guess we still need some changes in the client support, no?
[16:33] <flacoste> leonardr: btw, i don't have an opinion on dev vs trunk
[16:33] <flacoste> we could call it 'unstable'
[16:33] <leonardr> flacoste: yes, we need to add multiversion to lazr.restfulclient
[16:33] <leonardr> flacoste: that would be good in continuing the analogy to ubuntu
[16:40] <jtv> gmb: I figure you owe me one, if a small one: https://code.edge.launchpad.net/~jtv/lazr-js/bug-427263-3/+merge/18882
[16:40] <gmb> jtv: Sure
[16:40] <jtv> thanks!
[16:43] <gmb> jtv: From the diff it looks like you're setting the content attribute to ".".  But if I'm reading the mp right, you're setting it to zwnj... so is the diff just bong?
[16:43] <jtv> gmb: looks like... hang on
[16:44] <jtv> gmb: that's what you get when you prototype in a separate branch... this was an older approach.  Not hard to fix, but I'd better check that the fix works.  :)
[16:44] <gmb> :)
[16:50] <jtv> gmb: I just pushed the correction.
[16:52] <gmb> jtv: Looks good. r=me.
[16:53] <jtv> gmb: thanks... no "this is incredibly hackish, how did you even conceive of it"?  :)
[16:53] <jtv> Because I'm quite proud of that part.  :-)
[16:53] <gmb> jtv: I confess, I'm intrigued.
[16:53] <gmb> So do tell :)
[16:54] <gmb> (Though I would call it 'inspired' rather than hackish, but maybe that's just me.)
[16:54] <jtv> at this point, my bluff called, I sorely wish I had an interesting story to go along with this patch
[16:54] <jtv> It's just something I tried because nothing else seemed to work.
[16:54] <gmb> jtv: Heh, well, fair enough.
[16:54] <jtv> Gotta work on that story...  :/
[16:54] <gmb> jtv: May all your experiments prove successful.

[16:55] <gmb> Indeed.
[16:55]  * gmb calls it a day
[16:56] <jtv> g'night!
[17:15] <salgado> bac, can you review https://code.launchpad.net/~salgado/launchpad/kill-rogue-ec2-instances/+merge/18935 for me, once you're done with Edwin's?
[17:16] <bac> salgado: yep
[17:16] <salgado> thanks bac!
[17:19] <adeuring> bac: could you please review this mp: https://code.edge.launchpad.net/~adeuring/launchpad/bug-518746-faster-retrieval-of-patch-age/+merge/18936 ?
[17:19] <bac> adeuring: yes.  please add to topic.
[18:34] <bac> salgado: sorry for the delay.  am starting on yours now.
[18:40] <bac> salgado: you should've said it was only two lines long!
[18:49] <salgado> bac, nah, there really was no hurry to get this reviewed, so I didn't mind staying in the queue
[18:49] <salgado> and thanks, btw. :)
[19:55] <adeuring> thanks for your review, bac!
[19:55] <bac> np abel
[20:06] <leonardr> bac, can you add https://code.edge.launchpad.net/~leonardr/lazr.restfulclient/shorten-cache-filename/+merge/18951 to the queue?
[20:08] <bac> leonardr: why is that branch marked private?
[20:09] <leonardr> bac: not intentionally
[20:09] <leonardr> bac: fixed, i don't know how that happened
[20:10] <bac> leonardr: also, is it still possible to get a LP instance in lplib that does not use caching?  i looked at it yesterday and it seems there is no way.
[20:10] <leonardr> bac: it's not possible, but i've never heard anyone express a desire for that before
[20:11] <bac> leonardr: it used to be possible and i used it when testing against lp.dev.  probably not a strong use case
[20:11] <bac> leonardr: and certainly not relevant to this review.
[20:12] <leonardr> bac: i don't think that's a big problem
[20:18] <bac> leonardr: done.  thanks.
[20:19] <leonardr> thank you
[21:39] <sinzui> bac hi
[21:39] <bac> hello
[21:39] <sinzui> I have a branch I created with deryck to migrate hwdb
[21:39] <bac> ok
[21:39] <sinzui> I gave it to abel, but could you review it?
[21:40] <bac> sure, if i'm not duplicating abel's work
[21:40] <sinzui> bac: I have serious doubts that use hardwaredb is clearer than hwdb
[21:41] <bac> i think hwdb is pretty darn clear
[21:41] <bac> and short
[21:43] <sinzui> yes
[21:43] <sinzui> I think I should rename it to hwdb
[22:27] <EdwinGrubbs> bac: ping
[22:32] <bac> hi EdwinGrubbs
[22:39] <EdwinGrubbs> bac: I'm not so sure about moving the paths from bin/sprite-util into the Makefile, since there are a bunch of other variables that are dependent on them. For example:
[22:42] <EdwinGrubbs> bac: The png that create-image makes needs to be referenced by the css file that create-css makes. Since the css is in icing/build and the image is in icing/, "../icon-sprites" is the relative path, but that is much less clear when some of the paths are in the Makefile.
[22:42] <EdwinGrubbs> bac: passing in all the necessary info from the Makefile seems unwieldy.
[22:43] <EdwinGrubbs> Alternatively, I could add commands to sprite-util that return the paths, so the makefile can set up variable names.