[00:02] <kfogel> intellectronica: saw your branch get linked just now
[00:03] <intellectronica> kfogel: yes. had a chance to look at it?
[00:03] <kfogel> intellectronica: not yet, about to
[00:03] <intellectronica> i think it's good to go
[00:04] <kfogel> intellectronica: in this comment, "lisp-style identifier" means with hyphen instead of camelCase, right?
[00:04] <kfogel> Is this a new CSS class or an existing one. If it's new, let's change it to
[00:04] <kfogel> lisp-style-identifier. Otherwise don't worry about it.
[00:05] <intellectronica> kfogel: right. sorry for not being clearer.
[00:05] <kfogel> intellectronica: no, I think you were clear -- just you were here, so I thought I'd check to make abs sue.
[00:05] <kfogel> sure
[00:07] <kfogel> intellectronica: also, you wrote this: "Repeating the same style over and over again kinda' screams CSS class."
[00:07] <kfogel> but making a new class for this feels wrong -- I'd think the right class already exists somewhere.  Do you know if there's one I should use?
[00:07] <kfogel> This is for the table cells in the patches view.
[00:07] <intellectronica> kfogel: i have no idea. launchpad's css is a messy business, but look at the file and if you don't find one feel free to add
[00:08] <kfogel> intellectronica: "the file" is lib/canonical/launchpad/icing/style-3-0.css or lib/canonical/launchpad/icing/style.css
[00:08] <kfogel> ?
[00:08] <kfogel> or somethig else? :-)
[00:09] <intellectronica> kfogel: lib/canonical/launchpad/icing/style.css, i think
[00:09] <intellectronica> there's a section in it dedicated to the bugs application, so it should be ok to jsut add the class there
[00:11] <lifeless> thumper: poing
[00:11] <kfogel> intellectronica: oh, and I'm taking the "<!--" ... "-->" out of the script type=text/javascript block.  Thanks for the comment about the 90s calling :-).
[00:12] <intellectronica> :)
[00:16] <mwhudson> rockstar: if you *are* in the reviewing mood though, https://code.edge.launchpad.net/~mwhudson/launchpad/less-import-requestMirrors-bug-487357/+merge/18361
[00:17] <rockstar> mwhudson, I assume you're probably pretty lonely in your hemisphere currently, so I would review it even if I wasn't in the mood.
[00:17] <mwhudson> rockstar: indeed; thanks
[00:22] <lifeless> mwhudson: ping
[00:22] <lifeless> mwhudson: I'm going to nag you as thumper seems awol. please see up about one page for the bug link  I threw at him
[00:27] <kfogel> intellectronica: what I'm going to do is make an integration branch with your branch, my brancha, and allenap's branch (adding patches view to persons/teams), and run that integration branch through EC2 tests.  I assume if we get review on the three branches, then when the integration branch passes tests, we can merge each of the three individually to devel, right?
[00:27] <intellectronica> kfogel: yups
[00:30] <lifeless> kfogel: or bomb the lot in :P
[00:30] <kfogel> intellectronica: want to review https://code.edge.launchpad.net/~allenap/launchpad/patch-report-for-people-and-teams-bug-506018/+merge/18414 ?
[00:30] <kfogel> lifeless: well, how does one write the PQM submit message for that? :-)
[00:31] <lifeless> kfogel: "foo bar baz"
[00:31] <kfogel> I'm thinking what the combination of "[r=foo...]" on the front would be.
[00:31] <kfogel> ah
[00:31] <intellectronica> ok
[00:31] <kfogel> maybe I'll just do that
[00:31] <kfogel> intellectronica: thanks
[00:37] <kfogel> intellectronica: btw, do you need to get review on https://code.edge.launchpad.net/~intellectronica/launchpad/no-patches-message ?  (I am not a reviewer, unfortunately.)
[00:37] <kfogel> (s/unfortunately/fortunately/, as you please :-) )
[00:38] <mwhudson> lifeless: thumper is in london
[00:38] <intellectronica> kfogel: i do need to get a review, yes
[00:39] <kfogel> intellectronica: is that something I can submit, or do you have to do it?  because if I could, I'd pick one of these gents currently in the channel (assuming cross-team reviews are kosher).
[00:39] <intellectronica> kfogel: wow, if you feel like doing that that would be super awesome, because i'm dying to go to bed
[00:39] <intellectronica> but don't feel obliged
[00:39] <mwhudson> lifeless: do you know if 2.1rc2 will be out soon and if it will have the fix?
[00:40] <kfogel> intellectronica: remember, I'm just submitting to someone else, not reviewing.  But sure, I'll create a merge proposal and point to some test data for them, etc.
[00:40] <intellectronica> kfogel: approved allenap's branch, b.t.w
[00:40] <kfogel> intellectronica: great!
[00:40] <intellectronica> kfogel: you rock
[00:40]  * intellectronica --> zZz
[00:40] <kfogel> intellectronica: if tests pass, and the other branch passes review, then tomorrow we are all focused on the patch-age sorting, because IIUC that's the only thing left.
[00:41] <kfogel> intellectronica: good night!
[00:41] <lifeless> mwhudson: soon yes
[00:41] <lifeless> mwhudson: otoh this bug is going to be biting people, 2+ reports of it a day at the moment (judging by malone + hallway conversations here)
[00:42] <mwhudson> hmm
[00:42] <mwhudson> i wonder if the diff applies cleanly to the bzr we're currently running...
[00:42] <lifeless> yes, it will. its a tiny patch
[00:43] <mwhudson> ok cool
[00:46] <kfogel> mwhudson, thumper: will y'all be around, say, an hour from now?
[00:47] <mwhudson> kfogel: i will, thumper won't (i really hope)
[00:49] <wgrant> +upgrade is severely lacking in the text department.
[00:49] <wgrant> And it seems to be letting me upgrade a branch on which others are stacked. That seems bad.
[00:49] <kfogel> mwhudson: I may hit you with an easy review request a bit later then :-)
[00:49] <mwhudson> kfogel: ok
[00:51] <lifeless> wgrant: you have to be able to do that
[00:57] <wgrant> lifeless: Yes, but there's this nice clicky button with no explanation that will let me break everything.
[00:57] <rockstar> Huh, ec2 missed the fact that my branch wasn't up to date...
[00:59] <mwhudson> rockstar: thanks
[00:59] <mwhudson> rockstar: it's possible the branch hadn't been mirrored by the time ec2 grabbed it?
[01:00] <rockstar> mwhudson, no, my public branch was out of date.
[01:00] <mwhudson> oh
[01:00]  * rockstar shrugs
[01:01] <lifeless> rockstar: hi
[01:01] <lifeless> rockstar: so, the upgrade button seems to show up right after push until the branch is scanned
[01:01] <lifeless> rockstar: I presume the default value in the table causes it to be shown
[01:01] <rockstar> lifeless, :(
[01:02] <rockstar> lifeless, can you please specify that in the bug? I'll fix it tomorrow.
[01:03] <lifeless> rockstar: cool, thanks
[01:03] <rockstar> lifeless, no, thank you for reporting and following up on the bug.  I really appreciate it.
[01:04] <lifeless> anytime, its easy karma :)
[01:06] <rockstar> mwhudson, could we chat really quick?  I'm trying to figure out some of jml's suggested voodoo that I bet you know a lot about.
[01:06] <mwhudson> rockstar: sure
[01:06] <mwhudson> (i've even found my headset now)
[01:06] <rockstar> mwhudson, yay!
[01:07] <rockstar> mwhudson, http://pastebin.ubuntu.com/367205/
[01:08] <rockstar> mwhudson, http://pastebin.ubuntu.com/367206/
[01:18] <lifeless> mwhudson: so you're going to cherrypick the fix ?
[01:18] <mwhudson> lifeless: i guess i should
[01:19]  * mwhudson tries to remember what the process is for using non-released versions of sourcedeps is
[01:19] <mwhudson> rockstar: i'm not going to land the bzr upgrade until after this cp is sorted
[01:19] <mwhudson> rockstar: so don't rush things on my account
[01:19] <rockstar> mwhudson, well, I was already rushing.  :)
[01:20] <mwhudson> heh
[01:24] <lifeless> mwhudson: rockstar was landing another non released version for bzr-loggerhead
[01:24] <lifeless> mwhudson: so build on that :)
[01:24] <lifeless> mwhudson: for now, I'd like to assign the bug to you and bump to critical
[01:24] <rockstar> mwhudson, well, I'm actually doing one cherry pick at a time.
[01:39] <rockstar> Is there a dev wiki entry on landing against the production branches?
[01:39] <kfogel> mwhudson: https://code.edge.launchpad.net/~intellectronica/launchpad/no-patches-message/+merge/18428
[01:40] <kfogel> rockstar: does dev.launchpad.net/Trunk link to what you need?
[01:41] <rockstar> kfogel, no.
[01:41] <kfogel> rockstar: pity
[01:41] <kfogel> :-)
[01:42] <rockstar> kfogel, I'm looking for the instructions for landing against production branches.
[01:43] <kfogel> rockstar: they may not be in the dev wiki.  Is this different from landing against one of the four usual horsemen (db-devel, devel, stable, db-stable)?
[01:44] <kfogel> rockstar: i.e., I'm not clear on the shorthand "landing against production branches".
[01:44] <rockstar> kfogel, yes.  I need to land against what's in production right now.
[01:44] <rockstar> kfogel, none of those four are currently deployed.
[01:45] <rockstar> kfogel, AIUI, I submit to PQM with a release-critical against a production db.
[01:45] <kfogel> rockstar: you mean you need to land your change into production right away??  (Sorry, I'm not being deliberately dense, I'm just not clear on what you're trying todo.)
[01:45] <rockstar> kfogel, yes.  I have a high priority issue that needs to get cherry picked to production.
[01:45] <kfogel> rockstar: I'm not expert in this, having never done it, but I thought you just land the change on one of the regular trunks and then request a cherry pick.
[01:45] <kfogel> The request can be by email?  check with mthaddon or someone who might know better.
[01:45] <spm> what kfogel said
[01:45] <mwhudson> no, it has to be landed on production-devel
[01:45] <mwhudson> doesn't it?
[01:46] <spm> errr....
[01:46] <rockstar> mwhudson, yea, I think that's new.
[01:46] <mwhudson> which ties up pqm for like 14 hours
[01:46] <kfogel> mwhudson: but that's what the cherrypick does, no?
[01:46] <spm> don't you land against one of the rarely used, yet still in PQM branches?
[01:46] <rockstar> spm, yes, and I'm trying to figure out which one.
[01:46] <mwhudson> i think there is much talking past each other going on here
[01:46] <rockstar> After it lands, I then beg a LOSA to deploy it to production.
[01:46] <rockstar> I'm just trying to find a wiki page on how to do it.
[01:46] <mwhudson> rockstar: bzr+ssh://bazaar.launchpad.net/~launchpad-pqm/launchpad/production-devel
[01:47] <rockstar> mwhudson, thanks.
[01:47] <kfogel> mwhudson: (I don't think so; I think it just took a moment to figure out the goal)
[01:47] <kfogel> rockstar: this should be a note somewhere on dev.launchpad.net/Trunk
[02:11] <lifeless> mwhudson: https://bugs.edge.launchpad.net/bzr/+bug/513432 metadata twiddled.
[02:11] <mup> Bug #513432: AttributeError: 'Inter1and2Helper' object has no attribute 'source_repo' <fetch> <Bazaar:Fix Released by mbp> <Bazaar 2.0:Invalid> <Bazaar 2.1:Fix Released by mbp> <Launchpad Bazaar Integration:Confirmed for mwhudson> <https://launchpad.net/bugs/513432>
[02:11] <lifeless> for now, dinner time here.
[02:12] <kfogel> wowwwwwww... combination of "<<<<"  ">>>>" conflict markers and story test ">>>" lines is... dazzling to the eye.
[02:12]  * kfogel rubs his eyes
[02:38] <wgrant> james_w: Oh, 2.5 is going to be gone entirely?
[02:38] <james_w> that's the plan
[02:39] <james_w> 2.5->2.6 was less painful than 2.4->2.5 so there's less holding it back, and moving to 2.6 only means that we can move quicker towards python3
[02:39] <wgrant> The intention has been to only move LP to 2.6 once Lucid is out and the DC is upgraded.
[02:40] <james_w> that could make things tricky
[02:41] <wgrant> Yes.
[02:41] <james_w> we can always stick 2.5 in a PPA for those couple of months, but it would obviously be better if there were fewer PPAs involved
[02:41] <wgrant> I think everybody thought that 2.5 would remain like 2.4 did.
[02:41] <wgrant> We already have 2.5 rebuilds of most stuff in the PPA.
[02:44] <kfogel> mwhudson: any idea what this is about?  I see the import line right where the error message implies it is, but I have no idea what it means nor why it has never happened to me before :-).
[02:44] <kfogel> http://paste.ubuntu.com/367245/
[02:45] <mwhudson> kfogel: make build?
[02:45] <kfogel> https://lists.launchpad.net/launchpad-dev/msg00071.html ...
[02:45] <kfogel> mwhudson: oh, hmrm.  I'd done successful 'make run', I thought.  But let me do make build, let's see.
[02:46] <kfogel> mwhudson: *embarrassment*
[02:46] <kfogel> mwhudson: my 'make run' was in the wrong branch.  nothing to see here, move along...
[03:34] <thekorn> allenap, intellectronica, just in case anyone of you is still around, I got Person.searchTasks() working in my branch, it still needs some more tests, but I'm getting there
[03:35] <kfogel> thekorn: they're in bed (and I'm about to be) but they'll be on in the morning UK time
[03:36] <thekorn> ok
[04:03] <mwhudson> kfogel: reviewed that branch, finally
[04:09] <kfogel> mwhudson: thanks.  I think I should have explained that only Tom Berger's changes needed review -- but actually, you've saved us time by reviewing a lot of my recent changes too :-).
[04:09] <mwhudson> kfogel: oh
[04:09] <mwhudson> well, i just reviewed the diff :)
[04:11] <kfogel> mwhudson: I meant allenap, but same thing.
[04:11] <kfogel> mwhudson: yeah.  That's kind of a bug, in that "the diff" was the wrong thing.  I'm sure there was a way for us to set things up so it would be the right thing, but I didn't do that...
[04:12] <kfogel> mwhudson: no, I was right the first time: intellectronica, sorry
[04:35] <Ursinha> hey mwhudson, I have a question that you might know the answer
[04:36] <mwhudson> Ursinha: shoot
[04:36] <Ursinha> mwhudson: what exactly sets the properties of a bzr revision?
[04:36] <mwhudson> Ursinha: in what context?
[04:37] <Ursinha> mwhudson: I'm using bzrlib to get all the lp commits, one by one, and looking in its properties for the name of the "original" branch
[04:38] <mwhudson> oh right
[04:38] <Ursinha> mwhudson: and I just hit one that has no properties set
[04:38] <mwhudson> well, there's the branch nick i guess
[04:39] <mwhudson> Ursinha: in some sense, there's not much more of an answer than "bzrlib"
[04:39] <Ursinha> hm
[04:39] <mwhudson> there are some common properties, but none you can absolutely 100% rely on
[04:39] <Ursinha> mwhudson: I see
[04:39] <mwhudson> particularly given how old a codebase launchpad is
[04:40] <Ursinha> I was counting on the branch-nick property, and then it exploded because a revision had no branch-nick property
[04:40] <mwhudson> yeah
[04:40] <mwhudson> i think you just have to cope with that case
[04:41] <Ursinha> mwhudson: I'm trying to find one alternative way to get the bugs related to a commit besides people having to add the bug tag to the commit message
[04:42] <mwhudson> Ursinha: ah, i see
[04:43] <Ursinha> I know that this is automagically added to the commit message when you use ec2 land
[04:43] <Ursinha> mwhudson: I think I'll keep relying on the commit message now the bug is added without intervention
[04:43] <Ursinha> do you have any ideas? :)
[04:44] <mwhudson> Ursinha: not really
[04:44] <Ursinha> mwhudson: I mean, do you know a way of getting to a list of related bugs from a branch revision?
[04:44] <mwhudson> Ursinha: well, if the associate was done with ci --fixes lp:12345 then it's a revision property
[04:45] <mwhudson> if the fix was recorded in the web ui, then no, not from the bzr branch
[04:46] <Ursinha> mwhudson: I was thinking about getting the branch nick, then the owner, and searching for the original branch in lp, and getting the list of linked bugs...
[04:47] <mwhudson> Ursinha: that would most likely work, i guess
[04:47] <Ursinha> mwhudson: yeah, that works but it's slow and if you don't have a branch-nick, it fails
[04:47] <mwhudson> Ursinha: really, you want to get the branch with tip revid that of the rhs parent of the mainline commit
[04:47] <mwhudson> Ursinha: which is easy if you have db access :-)
[04:49] <Ursinha> mwhudson: trying to understand what you mean here :)
[04:50] <mwhudson> Ursinha: all mainline commits for launchpad are merges made by pqm
[04:50] <mwhudson> so the revisions have 2 parents
[04:50] <Ursinha> mwhudson: right
[04:50] <Ursinha> pqm and the owner's
[04:50] <mwhudson> the second parent revid is the tip revision of the branch being merged
[04:50] <mwhudson> so if you can find the branch with a given revid as its tip revid, you can find the merged branch
[04:51] <Ursinha> hmmmm
[04:51] <mwhudson> (well, probably, unless the branch has been deleted or something, but then you're SOL anyway)
[04:52] <Ursinha> mwhudson: so searching in the db for the branch using the tip revid
[04:52] <Ursinha> I wonder if that's overkill now
[04:52] <mwhudson> Ursinha: i think using the branch nick is probably a reasonable approach for now
[04:52] <mwhudson> Ursinha: we could export "get me the branch with tip revid $foo" over the api i guess
[04:53] <mwhudson> (maybe it is already! but i doubt it)
[04:53] <Ursinha> mwhudson: that would be neat
[04:53] <Ursinha> mwhudson: I couldn't find it
[04:53] <mwhudson> Ursinha: it's probably not there then
[04:53] <Ursinha> I see I can search using the branch url or the unique name
[04:53] <mwhudson> i don't think it's even an internal api
[04:53] <Ursinha> hm
[05:01] <Ursinha> mwhudson: is that bug 356360?
[05:01] <mup> Bug #356360: API call for finding branches that contain a revid <api> <Launchpad Bazaar Integration:Triaged> <https://launchpad.net/bugs/356360>
[05:02] <mwhudson> Ursinha: looks like it!
[05:05] <Ursinha> mwhudson: :)
[08:25] <noodles775> Morning ppl
[08:25] <al-maisan> Good morning noodles775 :)
[08:25] <wgrant> Morning.
[08:29] <thumper> morning
[08:29] <thumper> wgrant: I bet it isn't morning for you :)
[08:29] <wgrant> thumper: Not quite, no.
[08:30] <thumper> mwhudson: around at all?
[08:33] <adeuring> good morning
[08:33] <al-maisan> moin adeuring
[08:33] <adeuring> hi al-maisan!
[09:08] <mwhudson> thumper: ish
[09:08] <thumper> mwhudson: what's the status of the bzr update cp?
[09:09] <mwhudson> thumper: https://code.edge.launchpad.net/~mwhudson/launchpad/apply-fix-for-bug-513432/+merge/18435
[09:10] <thumper> mwhudson: was it branched from the production branch?
[09:10] <mwhudson> thumper: no
[09:10] <thumper> mwhudson: I'll get flacoste to rc it
[09:10] <thumper> mwhudson: hmm
[09:10] <mwhudson> thumper: but i think it'll cherrypick cleanly :-)
[09:10] <thumper> if you want to land on the production branch, you'll need that
[09:11] <thumper> we don't tend to CP any more
[09:11] <thumper> we just merge a branch into production
[09:11] <mwhudson> sure
[09:11] <mwhudson> but merge into devel first?
[09:11] <thumper> mwhudson: yes, normally
[09:11] <mrevell> hi
[09:12] <mwhudson> thumper: you can review it for that then :-)
[09:12] <thumper> mwhudson: you might want to replace the branch content with the same content but from the production revision
[09:12] <thumper> yep
[09:14] <thumper> done
[09:14] <thumper> mwhudson: so land on devel and I'll have flacoste rc approve before lunch
[09:16] <mwhudson> thumper: at the risk of sounding churlish, it's 22:14 here
[09:16] <mwhudson> thumper: want to do it yourself?
[09:26] <noodles775> mwhudson: Enjoy your evening. I'm assuming there was nothing that stood out as drastically wrong when you went over the bfb ui?
[09:26] <mwhudson> noodles775: no indeed
[09:26] <noodles775> Great, thanks for that.
[09:28]  * noodles775 writes the email to get wider feedback.
[10:02] <intellectronica> james_w: the bad news are that your patch didn't land because of test failures. the good news is that looks like these are unrelated, spurious failures
[10:02] <intellectronica> some good news...
[10:03] <intellectronica> mwhudson: thanks a lot for the review. i guess karl forgot to mention that mine was a tiny branch, dependent on his previous work?
[10:06] <intellectronica> mwhudson: anyway, you didn't make any comment about my work, so i'll interpret that as r=you and ask karl to look the rest of your comments. sorry that you had to do so much extra work (i'm sure the comments are valuable, though).
[11:15] <thekorn> intellectronica, hey, I have Person.searchTasks working for the webservice API in lp:~thekorn/launchpad/make_iperson_ihasbugs, it already has two (doctest) testcases, I'm wondering how many of them do I need, and esp. where to put them
[12:02] <jtv> henninge: what went wrong with my branch to check for unique template names?
[12:02] <adiroiban> danilos: Hi. Should I create a MP for bug 340664 , or since the performace issue is not solve, it is better to not push those changes?
[12:03] <mup> Bug #340664: Add administration page for all POTemplates in ProductSeries or DistroSeries <ui> <Launchpad Translations:In Progress by adiroiban> <https://launchpad.net/bugs/340664>
[12:03] <danilos> adiroiban, sorry, in the meeting
[12:03] <jtv> henninge: ahhh, let me guess: you ran into the problem before my fix had landed?
[12:03] <jtv> adiroiban: if there's a performance problem... it's not the one where Language is being queried far too often?
[12:04] <adiroiban> jtv: i don't think. This is for the +templates
[12:04] <henninge> jtv: I had checked the revisions but mixed up some numbers ...
[12:04] <adiroiban> and afaik this is a long standing issue
[12:04] <jtv> adiroiban: makes sense, but thought I'd better ask
[12:04] <jtv> henninge: right, I don't think it's on staging yet—it only just came out of EC2.
[12:05] <jtv> henninge: s/staging/edge/
[12:05] <asabil> Hi all
[12:05] <jtv> hello
[12:05] <henninge> jtv: just two revisions missing, actually
[12:05] <asabil> does anyone know that the download button on wide screens look bad ?
[12:05] <asabil> (the background image is not large enough)
[12:06] <jtv> asabil: thanks for the report... let me see if that's a known problem.
[12:06] <asabil> you're welcom
[12:07] <jtv> asabil: looks like that one's not known yet... could you file a bug against the "launchpad" project and attach a piece of screenshot to illustrate?
[12:08] <asabil> yeah sure
[12:08] <jtv> thanks
[12:13] <asabil> done: https://bugs.launchpad.net/launchpad/+bug/516000
[12:13] <mup> Bug #516000: The download button look bad on wide screens <Launchpad itself:New> <https://launchpad.net/bugs/516000>
[12:17] <jtv> asabil: great, thanks.  The people who would normally deal with this are in a meeting this week, so it could be a while before somebody gets to it.
[12:20] <asabil> jtv, yeah sure
[12:36] <asabil> looks like lazr.config is used in the launchpad code
[12:37] <asabil> anyone knows if it supports variables substitution ?
[12:39] <jtv> asabil: it doesn't afaik
[12:40] <asabil> ok I see
[12:40] <asabil> thanks
[13:04] <danilos> adiroiban, hi, sorry, in a live meeting here and get only short breaks from time to time :)
[13:05] <adiroiban> danilos: np. just ping me when you have more time. I want to know if I can continue with the implementation for some branches
[13:05] <danilos> adiroiban, anyway, I'd suggest you prepare an MP for 340664 and get it landed, it's still useful where it works
[13:07] <adiroiban> danilos: thanks. That is all for now
[13:07] <danilos> adiroiban, it was just a comment that we should definitely fix those performance problems as well (bug 475435)
[13:07] <mup> Bug #475435: More timeouts on +templates page <timeout> <Launchpad Translations:Triaged> <https://launchpad.net/bugs/475435>
[13:46] <noodles775> Hi james_w, you mentioned in your email that you won't have time to continue the trigger work. I'm looking at continuing it (as I'll need the api exposure for some of the UI), but have a few questions.
[13:46] <noodles775> First, is there any reason that you didn't land your approved branch here: https://code.edge.launchpad.net/~james-w/launchpad/create-source-recipe-build
[13:49] <noodles775> And secondly, ah, I was going to ask about the inclusion of distroseries as an argument for requestBuild() (as defined on the iface), but then noticed that you haven't included it in the implementation?
[13:50] <noodles775> which ever way your intention was, I'd be keen to hear the argument behind it (ie. whether a build should be able to define a distroseries different to the recipe).
[14:49] <kfogel> adeuring: btw, I forgot to list that I'm making screenshots for Jorge (today or maybe tomorrow)
[14:49] <adeuring> kfogel: noted ;)
[14:50] <kfogel> intellectronica: http://paste.ubuntu.com/367596/   has full results so far.  How on earth can it not have terminated after more than eight hours??
[14:50] <intellectronica> kfogel: because technology sucks?
[14:51] <kfogel> intellectronica: oh
[14:51] <kfogel> intellectronica: looking for failures now
[14:51] <intellectronica> sometimes our EC2 machines don't terminate. they have very strong will to live, i guess
[14:51] <intellectronica> it's worth looking at the mgmt console from time to time, because the costs can run very high if an instance is left running for many days
[14:51] <intellectronica> (i'm saying that from experience)
[14:51] <kfogel> intellectronica: "Failure in test test_inline_request_a_reviewer (lp.code.windmill.tests.test_branchmergeproposal_review.TestRequestReview)"
[14:52] <kfogel> intellectronica: *nod*
[14:52] <intellectronica> kfogel: i'd bet this is an unrelated spurious failure. we still get lots of those from windmill
[14:52] <intellectronica> let's try to run the same test locally to verify, but most likely that's the case
[14:52] <kfogel> intellectronica: so, that failure appears after lots and lots of successes, including success of patches-view.txt.
[14:52] <kfogel> okay
[14:52] <intellectronica> yay
[14:53] <kfogel> intellectronica: how do I run a particular Windmill test?
[14:53] <intellectronica> kfogel: https://dev.launchpad.net/Windmill
[14:53]  * kfogel hides his head
[14:53] <kfogel> intellectronica: thanks :-)
[14:54] <intellectronica> kfogel: crucial difference from the example is that it will be a different layer in this case. CodeWindmillLayer (iirc)
[14:55] <intellectronica> the windmill tests for each subdomain run in a separate layer, because of the restrictions browsers place on accessing JS code over different domains
[14:57] <kfogel> intellectronica: ah, gotcha
[14:58] <kfogel> intellectronica: running now.  Meanwhile, the EC2 test seems to be stuck at that spot -- there's been no more output, it just ends in the middle of a word....
[14:59] <intellectronica> argh
[14:59] <intellectronica> happened before. guess you'll have to kill that machine and fire a new test run.
[15:00] <kfogel> intellectronica: ok.  well, I was going to have to re-run anyway, what with the DB patch coming up and possibly a few more changes from me due to mwhudson's review, so no loss really.
[15:00] <kfogel> intellectronica: so test runs get stuck sometimes?  This is not unheard of?
[15:00] <intellectronica> yeah, it happened to me before
[15:01] <kfogel> oh goody, now my whole browser has frozen up
[15:01] <intellectronica> that's not unheard of either ;)
[15:02]  * kfogel snarkily observes that it never happens to him on his Debian box
[15:02] <kfogel> Although, I don't do Launchpad development on my Debian box either, so it's under considerably less strain :-).
[15:02] <intellectronica> because it only runs lynx? :P
[15:02]  * intellectronica runs and hides
[15:03] <kfogel> Yesterday I nearly shut down my whole Ubuntu laptop by running 'bzr log -v -n0 > outfile' in a devel branch.
[15:04] <kfogel> OH
[15:05] <kfogel> intellectronica: I didn't realize windmill tests actually display a browser dancing around!  This is spooky.
[15:06] <intellectronica> kfogel: yes. there's also a way to run them headless, under xvfb.
[15:06] <intellectronica> but they have to run a browser to complete the test. that's the whole point of these tests - they interact with a real browser.
[15:07] <kfogel> intellectronica: sure, I just didn't know that that browser displayed on the screen.
[15:08] <kfogel> intellectronica: anyway, it passed
[15:08] <intellectronica> yes, for me too
[15:10] <kfogel> intellectronica: okay, I'm terminating this instance in Elasticfox.  Any reason I should show mercy?
[15:10] <mars> intellectronica, ping, could you help confirm a JavaScript bug for me?
[15:12] <intellectronica> mars: sure. what's the problem?
[15:12] <asabil> when running launchpad, how can I disable the creation of the thread-*.request files ?
[15:12] <intellectronica> kfogel: no, you should feel free to terminate it if you've lost all hope of getting anything useful from that machine
[15:16] <mars> intellectronica, try going to a bug on staging.launchpad.net, and edit the product.
[15:16] <mars> intellectronica, when I do so I see an infinite spinner
[15:16] <intellectronica> mars: yes, we've seen this problem before
[15:16] <mars> intellectronica, and if I have Firebug turned on to catch all errors, it does grab something
[15:17] <intellectronica> oh?
[15:20] <mars> I can't make out the red error text though.  It is hidden by the long line.
[15:20] <mars> Maybe the error is also present in .dev
[15:40] <intellectronica> mars: sorry, back now
[15:40] <intellectronica> there's a bug already filed about this, let me try and find it
[15:40] <mars> ok
[15:41] <intellectronica> oh, and i can reproduce on FF
[15:43] <intellectronica> mars: https://bugs.edge.launchpad.net/malone/+bug/443217
[15:43] <mup> Bug #443217: Changing a bug's affected project or description doesn't ever finish <bug-page> <javascript> <ui> <lazr.restful:New for intellectronica> <Launchpad Bugs:Triaged by intellectronica> <https://launchpad.net/bugs/443217>
[15:44] <kfogel> adeuring: question about our "make_thing()" meta-factory function from patches-view.txt story tests.  That function has now moved to factory.py, and is LaunchpadObjectFactor.doAsUser().  In https://code.edge.launchpad.net/~intellectronica/launchpad/no-patches-message/+merge/18428, Michael Hudson asks: "Do you really need to commit here?  Zope-level users and database transactions are basically orthogonal."   Full context at http://pas
[15:44] <kfogel> te.ubuntu.com/367658/
[15:50] <adeuring> kfogel: yes, I think we must commit here. A story test does not access the database directly, but via a web server, which has its own database connection. When we manipulate the database via factroy.makeSomething(), the connetcion of the web server does not "see" any change, if we don't commit(). Also, I think we get an error message if we don't commit when the web server accesses the DB after a factory.mkeWhatever() call. Just re
[15:51] <kfogel> adeuring: thanks.  I'll respond to mwhudson with that.
[15:54] <kfogel> adeuring, intellectronica: advice: I'd like to change the "package" column to be called "target" in the patches view, because sometimes it's a package and sometimes it's a product (e.g., if you show the patches view on a project group).
[15:54] <kfogel> Thoughts?
[15:54] <adeuring> kfogel: sounds good. But there is another option, ii think
[15:54] <kfogel> ?
[15:55] <adeuring> you can display "package", if the context is a distribution or distroseries,
[15:55] <adeuring> and you can display "project" if the context is a project group
[15:55] <intellectronica> kfogel: wouldn't it be better to title it dynamically, depending on what kind of target it is? i don't think we use 'target' anywhere in the UI.
[15:55] <intellectronica> adeuring: high five!
[15:56] <adeuring> kfogel, intellectronica: though things will become messy with this approach when we have a patches view for persons...
[15:57] <adeuring> kfogel: ignoring the IPersoncontext, you could get the right column name for the current context from a browser class property.
[15:57] <kfogel> adeuring, intellectronica: So here's why I didn't propose the conditional solution: is it possible that the same view (same column) may display multiple types of targets?
[15:58] <adeuring> kfogel: yeah, now you mention this...
[15:58] <adeuring> if we have a bug with emough targets, that will happen...
[15:58] <adeuring> e.g., a bug where target 1 is a package and target 2 is a project
[15:59] <intellectronica> but don't we only deal with one target at a time?
[15:59] <kfogel> adeuring: well, it's not a matter of quantity, it's just that it could happen -- heck, maybe I could make it happen right now with project group, by attaching a bugtask to a package in a project in that group?
[15:59] <adeuring> kfogel: sure
[15:59] <kfogel> intellectronica: let me see if I can actually make this happen here
[15:59] <intellectronica> i mean, doesn't the patches view filter only bug tasks for a single target (unless it's a distro)?
[16:00] <kfogel> intellectronica: distro, or project group,...
[16:00] <adeuring> intellectronica: but distros are the context where we need this "target/"Pakcages" column...
[16:00] <kfogel> intellectronica: and when the view is on a product, then it shows different src packages
[16:00] <intellectronica> in fact, maybe you also want to hide that column if it's not a distro or a project group
[16:00] <kfogel> intellectronica: we do
[16:00] <kfogel> intellectronica: that is, we hide that column whenever it's not applicable
[16:01] <intellectronica> cool, so i think you should be safe to use either 'project' or 'package' depending on the type of the context
[16:01] <adeuring> intellectronica: really? If we run serachTasks() for a disto, are butasks for projects indeed not included?
[16:02] <adeuring> s/butasks/bugtasks/
[16:02] <intellectronica> adeuring: correct
[16:02] <adeuring> intellectronica, kfogel: OK, then it makes sense to display a more specific column title that "target"
[16:03] <adeuring> ...provided that distro-related bugtasks a not returened for IProject.searchTasks()
[16:03] <intellectronica> the problem with 'target' is that users will confuse it with release-management. we never use target in the UI to mean what it means in the code
[16:04] <kfogel> intellectronica: good point
[16:04] <kfogel> adeuring: that's what I'm trying to confirm right now, re distro-related bugtasks, and also project-group-related bugtasks.
[16:06] <kfogel> adeuring: in https://bugs.launchpad.dev/evolution/+patches, we don't show the "Package" column.  Was this on purpose?  If there's a bugtask on a package related to the evolution product, do we not want to show that in bugs targeting evolution itself?  (I can see a case both ways...)
[16:06] <adeuring> kfogel: yes, because evolution is project (or IProduct)
[16:07] <kfogel> adeuring: "yes, we don't want to show package bugtasks" ?
[16:07] <adeuring> kfogel: well, let's double-check what searchTasks() returns in this case...
[16:09] <kfogel> adeuring: I'm trying to do that via the UI right now, yep.
[16:10] <adeuring> kfogel: bugs/model/bugtask.py, line 1492: extra_clauses.append("BugTask.product = Product.id")
[16:10] <adeuring> so, only bugtasks for the current project(IProduct) are retuned
[16:11] <adeuring> erm, returned
[16:11] <kfogel> adeuring: so trusting of the code... :-)
[16:11] <adeuring> yeah ;)
[16:11] <kfogel> adeuring: but yes, you're probably right.  I'm trying it in the UI anyway, just to make sure.
[16:12] <adeuring> kfogel: sure, that's always better, considering the famous remark by Mr. Knuth about proving corretness and testing code ;)
[16:12] <kfogel> adeuring: okay, I filed this with a patch attachment: https://bugs.launchpad.dev/ubuntu/+source/evolution/+bug/25 .
[16:12] <mup> Bug #25: Allow discussion/commenting on translations <feature> <Launchpad Translations:Triaged> <https://launchpad.net/bugs/25>
[16:12] <kfogel> BUT, it does not show up in https://bugs.launchpad.dev/evolution/+patches
[16:12] <kfogel> adeuring: what's that remark?  I don't know it.
[16:13] <adeuring> something like "beware with the code above. While Iproved its correctness, I did not run it"
[16:17] <adeuring> kfogel: from /usr/share/games/fortunes/computers; Beware of bugs in the above code; I have only proved it correct, not tried it.   -- Donald Knuth
[16:17] <kfogel> nice :-)
[16:20] <jamalta> so i'm having this issue
[16:20] <jamalta> https://lists.launchpad.net/launchpad-dev/msg02281.html
[16:20] <jamalta> i've tried rocketfuel-get, but that doesn't seem to solve the problem
[16:20] <jamalta> and running the mentioned script tells me "Bazaar Explorer requires QBzr. Please install it and try again." but i have both bzr-explorer and qbzr installed.
[16:22] <mars> jamalta, running rocketfuel-get complains about qbzr?
[16:22] <jamalta> nvm, i think i found my problem
[16:23] <jamalta> mars: no the utilities/update-sourcecode script
[16:23] <jamalta> my problem is that rocketfuel-get was failing to download anything because of my proxy :)
[16:23] <jamalta> this time it should be able to solve the problem
[16:25] <lifeless> jml: nice patch
[16:29] <jamalta> i lied, i still can't run launchpad
[16:29] <jamalta> i installed bzr-builder from apt, so i can import bzrlib.plugins.builder.recipe from the python interpreter
[16:30] <jamalta> but make run still complaints it can't import it
[16:34] <jamalta> here is what make run is giving me http://paste.ubuntu.com/367682/
[16:37] <thekorn> jamalta, I had something similar yesterday, after running make clean & make this was solved for me
[16:38] <jamalta> thekorn: thanks
[16:45] <jamalta> thekorn: make fails with the same error :(
[16:49] <lifeless> do you have builder in your optional bzrplugins dir ?
[16:52] <jamalta> lifeless: where is the optional bzrplugins dir?
[16:53] <jamalta> ignore that question
[16:53] <jamalta> there is a broken symlink there
[16:53] <jamalta> hmm.
[16:53] <jamalta> that explains a lot
[16:54] <jamalta> sourcecode/bzr-builder was gone
[16:54] <jamalta> s/was/is
[17:02]  * jamalta sighs
[17:02] <jamalta> still having the issue, this is strange
[17:20] <jamalta> am i supposed to have a sourcecode/bzr-builder?
[17:24] <jml> jamalta, I think so.
[17:25] <jml> lifeless, the subunit-by-default one or the on-edge one?
[17:26] <jamalta> jml: So how can I get it? rocketfuel-get is not fetching it and I'm not quite sure how I lost it in the first place
[17:26] <jamalta> Unless it was recently added, in which case, I don't have it
[17:26] <lifeless> jml: subunit
[17:26] <jml> jamalta, it was added recently, I think. I'm not sure about rocketfuel-get
[17:26]  * jamalta has a feeling that's what scripts/update-sourcecode is for
[17:26] <jml> jamalta, yeah, run that.
[17:26] <lifeless> jml: the on-edge one is  intereseting too; I haven't read the code though, so can't comment about it so much :)
[17:27] <jamalta> jml: i can't
[17:27] <jamalta> ok now i can
[17:27] <jml> lifeless, heh heh.
[17:27] <jamalta> Having bzr-explorer installed on my system broke it for some odd reason
[17:28] <jml> poolie, can you please add a commit message to https://code.launchpad.net/~mbp/launchpad/436294-review-mails/+merge/18227
[17:28] <poolie> oh sure
[17:29] <jml> poolie, you don't have to bother with any of the tags.
[17:29] <jml> poolie, just something meaningful with no newlinesn
[17:31] <poolie> done
[17:32] <jml> poolie, thanks.
[17:32] <kfogel> adeuring: (back from an early lunch)  So, TAL conditions can only be Booleans, right?  But I can do tal:condition="python: arbitrary python code here resulting in boolean"
[17:33] <jml> poolie, fwiw, if you have a commit message and an approved proposal, any Launchpad dev can land it with './utilities/ec2 land <merge_proposal_url>'
[17:34] <jml> poolie, so there's rarely an excuse for a delay in landing
[17:34] <jml> dev w/ commit access, I guess I should say. old habits die hard.
[17:34] <kfogel> jml: when one uses that script, the MP "commit message" is used as the commit message, right?
[17:34] <adeuring> kfogel: yes you can do that. But tal:condition can take anything that _evaluates_ to true/false
[17:34] <jml> kfogel, mostly
[17:35] <jml> kfogel, it also automatically does the [r=oaue][ui=aoueo][bug=4234,908034] stuff
[17:35] <kfogel> jml: ah, ok
[17:35] <jml> kfogel, which I was sick of figuring out manually
[17:36] <kfogel> adeuring: here's what I'm solving: we're going to choose the presence or absence of that patches view column, and (if present!) choose its ("package" vs "project") in a conditional way.
[17:36] <kfogel> s/its/its name/  sorry
[17:36] <adeuring> kfogel: I think the best readable version for this would be to add a property to the the browser.
[17:37] <kfogel> adeuring: "target_name" or something?
[17:37] <kfogel> target_type ?
[17:37] <adeuring> kfogel: right, or target_column_header_name
[17:37] <kfogel> adeuring: so the idea is, if browser.shouldShowTargetName is true, then we choose the column name based on that property
[17:38] <james_w> noodles775: it's not landed as I don't have the rights to do so, and I think the review tweaks still need to be made
[17:38] <adeuring> kfogel: yes
[17:38] <kfogel> adeuring: beautifulicious
[17:38] <kfogel> adeuring: on it
[17:38] <kfogel> adeuring: what's status of patch-age-sort db patch?  landing today you think?
[17:38] <adeuring> kfogel: I'm still waiting for a second DB review...
[17:39] <james_w> noodles775: and nice spot on the distroseries argument, it just needs to be removed from the interface
[17:39] <adeuring> kfogel: my point for using a browser property is: something "if IDistribution.providedBy(context)" in a tal expression tends to look quite ugly. And I am not sure if/how we can import IDistribution into a TAL expression...
[17:41] <kfogel> adeuring: I was considering a route where shouldShowTargetName() becomes a non-boolean method 'targetName()', and returns either a column name or None, and then the .pt file is adjusted accordingly.  Do you think that way is better or your way is better?
[17:41] <kfogel> adeuring: who was your first db review?  jml?
[17:41] <adeuring> kfogel: no, it was stub
[17:42] <kfogel> adeuring: rhetorically, just to shoot the breeze here in the channel, I will ask you if jml is aware of the urgency of this db patch getting in?
[17:42] <adeuring> ahh, I see jml. jml, could you have a look at this mp https://code.edge.launchpad.net/~adeuring/launchpad/bug-512500-searchtasks-patch-age-sort/+merge/18446 ?
[17:43] <adeuring> kfogel: yes, you can do something like tal:define="target_name view/target_name" tal:condition="target_name"
[17:43] <thekorn> hi allenap. does lp:~allenap/launchpad/patch-report-for-people-and-teams-bug-506018 in any way interfere with my work on making searchTasks() available for persons?
[17:44] <adeuring> kfogel: thouhg i need to double-check if these expression can go into the same XML tag
[17:44] <kfogel> adeuring: oh, if a TAL condition expr evaluates to None, then it is treated as false?  That's considered okay?
[17:44] <allenap> thekorn: No it won't, it'll be fine.
[17:44] <adeuring> kfogel: yes. I think an empty string also evaluates to False, for example
[17:44] <kfogel> adeuring: (style-wise, I mean)
[17:45] <kfogel> adeuring: in Python yes, but I never assume TAL == Python.
[17:45] <noodles775> james_w: great, I'll take it from there then. Thanks!
[17:45] <thekorn> allenap, ok, super
[17:45] <james_w> thanks noodles775
[17:45] <kfogel> adeuring: $ python
[17:45] <kfogel> Python 2.6.4 (r264:75706, Dec  7 2009, 18:45:15)
[17:45] <kfogel> [GCC 4.4.1] on linux2
[17:45] <kfogel> Type "help", "copyright", "credits" or "license" for more information.
[17:45] <kfogel> >>> TAL == Python
[17:45] <kfogel> Traceback (most recent call last):
[17:45] <jml> hi
[17:45] <adeuring> kfogel: yes, I think that's ok -- at least i would do the reveiw ;)
[17:45] <kfogel>   File "<stdin>", line 1, in <module>
[17:45] <kfogel> NameError: name 'TAL' is not defined
[17:45] <kfogel> >>>
[17:45] <kfogel> see? :-)
[17:45] <jml> adeuring, kfogel: you have some stuff for me, I see :)
[17:45] <jml> I'll take a look
[17:45] <jml> it's got conflicts.
[17:46] <adeuring> jml: yes, this branch: https://code.edge.launchpad.net/~adeuring/launchpad/bug-512500-searchtasks-patch-age-sort/+merge/18446
[17:46] <kfogel> adeuring: and in the UI, the column name for a Product should be "Project", right?
[17:46] <adeuring> kfogel: yes
[17:47] <adeuring> jml: sigh, yes, I see the conflicts now too...
[17:47] <adeuring> jml: let me merge db-devel again
[17:47] <jml> adeuring, np.
[17:48] <jml> has this patch been discussed before?
[17:52] <jamalta> Are API permissions defined by configure.zcml?
[17:54] <allenap> jamalta: Yes. But then see security.py for where the permissions are actually checked.
[17:54] <jamalta> allenap: thanks
[17:55] <jamalta> allenap: thanks!
[17:56] <allenap> jamalta: Welcome :) You might not be saying that once you've read security.py ;)
[17:56] <jamalta> allenap: It's not too bad! I think I found what I needed actually
[17:57] <jamalta> Much easier than reading configure.zcml ;)
[17:57] <adeuring> jml: yes, I sent a mail to the lp-dev list (last Thursday, I think), and I discussed with stub some problems that we have without the schema change. Basically, it boils down to Storm bot supporting DINSTINCT ON (column name) and to nest query like SELCT * from (SELECT ... ) ORDER BY ...
[17:57] <allenap> jamalta: Cool.
[17:57] <jml> adeuring, ok, thanks.
[17:58] <jml> adeuring, it's all fine by me.
[17:58] <adeuring> jml:  great, thanks!
[17:59]  * adeuring needs to restart X. windows are not properly redrawn. back in two minutes...
[18:00] <allenap> thekorn: Sorry, I'm just looking at your branch. I think the approach of moving IHasBugs.official_bug_tags into a new interface would be better than moving searchTasks().
[18:01] <allenap> thekorn: Person already implements all of IHasBugs because it inherits HasBugsBase, with the exception of official_bug_tags. I'm not sure why that was put on IHasBugs, it doesn't belong there, but I don't think it'll be a big job to move it.
[18:03] <kfogel> adeuring: I have this memory that the exact name "shouldShowTargetName" is something we used because it would have certain effects elsewhere, not merely to match a previously-existing view's method name.  Should I be worried about changing it to targetName or whatever?  http://paste.ubuntu.com/367724/ for kicks
[18:04] <kfogel> I see that lib/lp/bugs/templates/bugtarget-macros-search.pt uses it, but I'm not sure that matters for us, since it's presumably referring to the one in bugtask.py.
[18:04] <allenap> thekorn: A few changes are in my branch at lp:~allenap/launchpad/make_iperson_ihasbugs. I'll test it overnight and see what breaks.
[18:05] <adeuring> kfogel: I think we can choose any name, as long as we won't mess with bugtarget-macros-search.pt.
[18:05]  * adeuring would prefer to do that, but others disagree
[18:06] <kfogel> adeuring: we haven't edited bugtarget-macros-search.pt AFAIK, so we shouldn't affect it.
[18:06] <adeuring> kfogel: xactly.
[18:10] <thekorn> allenap, actually I'm fine with any solution, as long as the resulting person obect does not have an official_bug_tags attribute, I'll look what you have in your branch tomorrow
[18:11] <thekorn> allenap, there is one thing left for me, I don't know how detailed the tests must be, how many of them are needed, and especially where to put them
[18:23] <mpt> sinzui, are you available to talk about USC ratings and reviews?
[18:24] <sinzui> mpt: I may have time this week
[18:26] <mpt> sinzui, we're getting kind of concerned since we have only two weeks until Feature Freeze
[18:27] <sinzui> mpt: I cannot start working on it until this weekend. I will not work on it during my core hours. My team must catchup the work it lost because of spammers
[18:38] <jamalta> So I'm looking into figuring out how to solve bug #515761 and I'm completely stumped. I can't find anything in configure.zcml and security.py that excludes public access to a project's series
[18:39] <mup> Bug #515761: Not able to access project releases anonymously <launchpadlib :New> <https://launchpad.net/bugs/515761>
[18:39] <jamalta> Is there something obvious I could be missing? I don't really want to waste anyones time with this :)
[18:42] <james_w> did edge rollout in the last 12 hours?
[18:50] <thekorn> allenap, I thought about what you said again, I we move official_bug_tags away from IHasBugs, I think we would have similar problems with getUsedBugTagsWithOpenCounts() and getUsedBugTags()
[18:50] <thekorn> where should this methods go?
[18:57] <kfogel> adeuring: want to re-review https://code.edge.launchpad.net/~kfogel/launchpad/506018-patch-report ?  It's changed a lot.  (My latest comment on https://code.edge.launchpad.net/~intellectronica/launchpad/no-patches-message/+merge/18428 has details, actually.)
[18:59] <adeuring> kfogel: yes, I'll have a look
[19:00] <kfogel> adeuring: also, I think I should now make an integration branch that includes lp:~kfogel/launchpad/506018-patch-report, lp:~intellectronica/launchpad/no-patches-message, your branch (which should be attached to https://bugs.edge.launchpad.net/malone/+bug/512500 but isn't? :-) ), and lp:~allenap/launchpad/patch-report-for-people-and-teams-bug-506018 .
[19:00] <mup> Bug #512500: In patches view, offer sorting on patch age. <story-patch-report> <Launchpad Bugs:Triaged by kfogel> <https://launchpad.net/bugs/512500>
[19:01] <kfogel> ah, https://code.edge.launchpad.net/~adeuring/launchpad/bug-512500-searchtasks-patch-age-sort/+merge/18446, got it now
[19:01] <adeuring> kfogel: that branch went into ec2test just 30 minutes ago...
[19:01] <kfogel> adeuring: ah, ok.  But we still need to test all these things together, right?
[19:01] <kfogel> No one has put all four branches together in one instance, AFAIK.
[19:02]  * kfogel afk to put laundry in dryer, bbiab
[19:02] <adeuring> kfogel: if you simpyl merge tehse brnaches, I think sepaeate tests are not necessary. Only when you actually add more code, you'll need new tests
[19:03]  * adeuring is afk for dinner
[19:09] <kfogel> adeuring: well, we shouldn't be adding more code; there are a couple of minor conflicts to resolve, but they're trivial.
[19:13] <mwhudson> adeuring: i think you're mistaken about how page tests work, btw
[19:13] <mwhudson> there's no web server
[19:17] <mwhudson> the testbrowser talks to the publication code directly, there isn't network-level stuff
[19:27] <sesammases> where in the code tree do I find the entry point for the "answers" subsite?
[19:28] <mwhudson> sesammases: ./lib/lp/answers
[19:29] <bac> abentley: you indicate in the whiteboard that you were going to follow up on https://code.edge.launchpad.net/~davidcaste/eopsoa/trunk
[19:29] <abentley> bac, yes.  I actually wanted to talk to mwhudson about that.
[19:30] <mwhudson> oh right
[19:30] <sesammases> thx :)
[19:30] <abentley> mwhudson, are you on duty?
[19:31] <mwhudson> abentley: yeah
[19:31] <abentley> mwhudson, skype?
[19:31] <mwhudson> abentley: one sec
[19:35] <mwhudson> abentley: ok
[19:38] <abentley> mwhudson, I don't see you on Skype.
[19:53] <adeuring> mwhudson: right, there is no "real" webserver, but I maintain that the "server side" of a pagetest uses a different DB connection that that we use directly in tests to manipulate test data
[19:55] <adeuring> kfogel: what is the revision of your branch that Tome reviewed?
[19:57] <kfogel> adeuring: oh, wow, let me see
[19:58] <adeuring> kfogel: sorry, didn't yet start th review -- had to fill my stomach first...
[19:58] <kfogel> adeuring: np (I was also (re)filling mine)
[19:59] <abentley> mwhudson, 516222
[19:59] <kfogel> adeuring: I *think* it was roughly http://bazaar.launchpad.net/%7Ekfogel/launchpad/506018-patch-report/revision/10175
[19:59] <kfogel> give or take a rev or two
[19:59] <adeuring> kfogel: ok
[20:01] <mwhudson> adeuring: i'm still a bit sceptical of that, but i can't be bothered to check now...
[20:01] <kfogel> adeuring: I'm getting tangled up here thinking about this question: if I want to put all four branches together just to do some manual testing, should I base the "root" branch from devel or db-devel?
[20:02] <kfogel> yours is the only one with db patches
[20:02] <adeuring> kfogel: ca't you simply merge one branch into [db-]devel, then merge the next brach and so on?
[20:03] <adeuring> mwhudson: are you sure that DB changes in page tests without  login() and commit() calls work?
[20:03] <mwhudson> adeuring: you need to login() and logout() yes
[20:03] <kfogel> adeuring: oh, I'm trying that
[20:04] <kfogel> adeuring: can think of various reasons why it "shouldn't" work, but I'm probably over-theorizing.
[20:04] <mwhudson> adeuring: but look at, say, the bottom of lp/code/stories/codeimport/xx-codeimport-view.txt
[20:05] <adeuring> mwhudson: oh, yes, now I get it. thanks!
[20:13] <james_w> any chance of a CP for the task_age fix? It's not on edge so I'm still blocked.
[20:14] <kfogel> dang it, bzr merge lp:~adeuring/launchpad/bug-512500-searchtasks-patch-age-sort/+merge/18446 should work!
[20:14] <adeuring> kfogel: yes, but then you can't any longer merge to devel, due to the DB patches in my branch
[20:15] <kfogel> adeuring: no, I mean merging a merge proposal should work
[20:15] <kfogel> adeuring: instead of a branch (i.e., treat it like the branch it refers to)
[20:15] <adeuring> kfogel: interesting...
[20:27] <kfogel> adeuring: Assuming all the branches have been approved, I can land them all with the appropriate "[r=foo]" from the MP, right?
[20:27] <kfogel> adeuring: and I land three of them on devel and one on db-devel, right?
[20:27] <kfogel> adeuring: (I'm not landing any until I've got the integration branch running here -- I want to see this stuff all play together first)
[20:28] <adeuring> kfogel: yes. But again, there is not real point yet for you to merge my branch, because it just contains the DB schema, no real code. I'll try to finish a branch that implements the new sort order for searchTasks() this evening.
[20:29] <kfogel> adeuring: oh!  I didn't realize that, sorry.
[20:29] <kfogel> adeuring: okay, then I won't try to land your branch.  But I _will_ try to get the others into devel today/tonight.
[20:29] <adeuring> kfogel: yeah, makes sense
[20:31] <kfogel> adeuring: though since I've just done the work, I'm going to run with your new db schema and see what happens :-).
[20:34] <kfogel> adeuring: people.canonical.com/~kfogel/patches-view/512500-current-dev-sql.diff in case you want my test data
[20:34] <adeuring> kfogel: no, sorry, need to focus now on my own brnach ;)
[20:37] <kfogel> adeuring: that's for your branch!
[20:38] <kfogel> adeuring: "I'm only trying to help you because I love you, honey..."
[20:38] <adeuring> kfogel: ah, sorry... my fault... seems to be too late for me proper read IRC channels...
[20:38] <kfogel> adeuring: except, it seems it's broken, one sec, trivial fix
[20:51] <kfogel> adeuring: okay, fixed up that diff.  And it's working for me, in an integration branch that includes your db changes.
[20:52] <adeuring> kfogel: great
[20:54] <kfogel> adeuring: http://paste.ubuntu.com/367826/  (some sample URLs under launchpad.dev for you)
[20:54] <adeuring> kfogel: thanks!
[20:55] <kfogel> adeuring: no problem.  oh, I think the "https://bugs.launchpad.dev/ubuntu/warty/+source/evolution" URL should be https://bugs.launchpad.dev/ubuntu/warty/+source/evolution/+patches
[20:55] <kfogel> sigh
[20:55] <kfogel> will fix up and make a new reference paste
[20:56] <Ursinha> rockstar: hi
[20:56] <rockstar> Ursinha, hi back
[20:56] <kfogel> http://paste.ubuntu.com/367828/
[20:57] <Ursinha> rockstar: :) don't know if you saw jtv's request earlier today, about bug 356360
[20:57] <mup> Bug #356360: API call for finding branches that contain a revid <api> <Launchpad Bazaar Integration:Triaged> <https://launchpad.net/bugs/356360>
[20:57] <rockstar> Ursinha, I did.
[20:57] <rockstar> Ursinha, I don't think that will happen for a while though.
[20:58] <rockstar> I started work on it, but after talking with thumper about the Revision table, it would be work that would just get removed.
[20:58] <rockstar> We want to change how we gather revisions.
[20:58] <Ursinha> rockstar: hm.. I see
[20:58] <rockstar> Ursinha, did you see abentley's comment?
[20:58] <Ursinha> rockstar: let me explain why that would be useful
[20:58] <Ursinha> rockstar: reading now
[20:58] <rockstar> He (as usual) has a good point.
[20:59] <Ursinha> rockstar: I need to know the merged branch to be able to get the bugs linked to it, right?
[20:59] <rockstar> Ursinha, yes.
[21:00] <rockstar> Ursinha, also, we put the bug numbers in the PQM commit message.
[21:00] <Ursinha> rockstar: all this work would be to avoid that
[21:00] <Ursinha> rockstar: it would be great if that never fails, but it does, so I'm trying to find another approach
[21:01] <rockstar> Ursinha, well, I'm not sure if we'll be able to provide a better approach soon.  :(
[21:01] <Ursinha> rockstar: to migrate all teams to the tagging schema, we'd like to get rid of the wiki pages
[21:01] <rockstar> Ursinha, you could always mail thumper.  He's in London this week, but putting a bug in his ear about it being important for QA might help.
[21:02] <Ursinha> rockstar: to get rid of the wiki pages, I'm searching for a safe approach to just ignore orphaned commits
[21:02] <abentley> Ursinha, it should be easy to find all the merged branches.  If it's not, we can tweak the API.
[21:03] <Ursinha> rockstar: so, it would be good to be able to rely on the bug added to the commit message by the ec2 script, but not everyone here uses that
[21:03] <Ursinha> rockstar: what I found out is that I can get the branch-nick in the revision properties, but it turns out not all revisions have that
[21:04] <Ursinha> having the branch-nick, I can guess the branch url and search for it using the API
[21:04] <Ursinha> rockstar: but not having that, I have no way out
[21:04] <Ursinha> abentley: how?
[21:05] <Ursinha> abentley: how to find the merged branches using bzrlib, I mean
[21:05] <abentley> Ursinha, look for the merge proposals that are marked merged.
[21:06] <Ursinha> abentley: how do I correlate that with the revision?
[21:06] <abentley> Ursinha, why do you want to start with the revision?
[21:07] <Ursinha> abentley: because when I see a new one in the branches I monitor (stable and db-devel) that triggers the tagging of the bug fixed by that
[21:07] <Ursinha> unless I start to monitor the branches being merged instead of the main branches
[21:08] <Ursinha> by main branches I mean stable and devel
[21:10] <abentley> Ursinha, why not look at branches merged into stable and devel instead of revisions committed to stable and devel?
[21:10] <Ursinha> abentley: could be an option, just haven't thought about that yet :)
[21:10] <Ursinha> abentley: this revision thing is how it works today
[21:11] <abentley> Code is already tracking which branches fix which bugs and which branches have been merged into their targets, so there's an opportunity to avoid double work here.
[21:12] <Ursinha> abentley: good. I'll look into that
[21:12] <Ursinha> thanks for the idea
[21:12] <Ursinha> thanks rockstar
[21:12] <abentley> No problem.
[21:17] <adeuring> kfogel: sorting by creation date of most recnetly added patch is now possible in bugtarget.searchTasks(). lp:~adeuring/launchpad/bug-512500-model-change
[21:17] <adeuring> I'm still waiting for the base branch to run through ec2, so I'm not yet submitting this one for review.
[21:19] <adeuring> kfogel: simply use  bugtarget.searchTasks(orderby='latest_patch_uploaded')
[21:19] <adeuring> sigh.. I meant '-latest_patch_uploaded', for the +patches view
[21:31] <mwhudson> abentley: https://code.edge.launchpad.net/~mwhudson/launchpad/ssl-imports-bug-512763/+merge/18479
[21:34] <abentley> mwhudson, what would you think about providing that comment on force_bzr_to_use_urllib as a docstring?
[21:35] <mwhudson> abentley: i guess it's slightly better
[21:37] <abentley> mwhudson: r=me, preferably with that docstring.
[21:37] <mwhudson> abentley: ok
[21:37] <mwhudson> abentley: thanks
[21:39] <abentley> mwhudson, np.