=== matsubara-afk is now known as matsubara === Ursinha_ is now known as Ursinha-afk === matsubara is now known as matsubara-afk === bigjools changed the topic of #launchpad-reviews to: On call: - || reviewing: - || queue: [bigjools] || This channel is logged: http://irclogs.ubuntu.com/ || https://code.edge.launchpad.net/launchpad/+activereviews [10:30] can someone review a small branch please? [11:36] bigjools, reviewed your branch, just a few minor comments [11:37] danilos: great! thanks [11:37] bigjools, let me know once you address them so I approve it :) [11:37] ok will do, I need to get some time outside of a uds session :) [11:38] bigjools, heh, sure === matsubara-afk is now known as matsubara === Ursinha-afk is now known as Ursinha [14:13] abentley, danilos, jtv: any of you want to review https://code.edge.launchpad.net/~mwhudson/launchpad/directbranchcommit-calls-branchChanged-bug-578331/+merge/25059 ? [14:24] mwhudson, I am taking a look [14:26] mwhudson, does the fact that we can't really commit to a stacked branch have any relevance here? (just mentioning, we do have a work-around in place for that, but I expect us to always have get_stacked_on_url return None because of bug 375013) [14:26] Bug #375013: Cannot commit directly to a stacked branch [14:26] danilos: it's a bit relevant i guess [14:27] danilos: but i tried to make the change so that it wouldn't break when that bug is fixed [14:27] mwhudson, of course, no need to hard-code here something that we'll want to fix later, I just wonder if it's important [14:27] mwhudson, right, sounds good [14:28] danilos: it's important to check the branch, because we could end up with the fact that the branch has been unstacked not being recorded [14:30] mwhudson, do we do that at all? [14:30] mwhudson, oh, right, that's the get_stacked_on_url [14:32] danilos: right [14:32] danilos: tangentially, i think it would be marginaly better in your stacking workaround to check if the bzr branch is stacked rather than the database branch [14:33] (although now i think about it a bit more i don't think it would make any practical difference at all) [14:34] mwhudson, I am not the most knowledgeable person about the code side of things, so we are probably going to do whatever you guys suggest if it really makes sense :) [14:38] mwhudson, nothing looks obviously wrong, but you have an empty comment. [14:39] abentley: doh [14:39] # commit() records the committed revision in the database record for [14:39] # the branch. [14:39] abentley: look ok? [14:40] mwhudson, yes, but I'm now wondering about the relationship of branchChanged and the scanner. [14:41] abentley: branchChanged creates a scan job if the passed in revision id is different from last_mirrored_id [14:43] mwhudson, r=me. [14:44] abentley: thanks [14:44] abentley: can you do that in the ui so i can ec2 land it? [14:44] mwhudson, done. [14:45] abentley: merci [14:45] mwhudson, I was just going to r=me as well, but one is good enough :) abentley, mwhudson: thanks! [14:45] mwhudson, can you get this CPed as well, please? [14:45] mwhudson, or should I ask for that? [14:46] danilos: i think it would be good to test the fix on staging when it gets there [14:46] danilos: does the translations export thingy work on staging? [14:46] mwhudson, sure, sounds good; I think it does, though I'd have to check with jtv first [14:46] mwhudson, we can also cowboy it to staging to speed it up a bit :) [14:46] danilos: but in general i am (a) at uds (b) not officially lp any more, so it might be best for you to chase the cp [14:47] yeah, that'd help [14:47] mwhudson, sure, thanks [14:47] danilos, mwhudson: check what exactly? [14:47] ec2 is booting [14:47] jtv, does export to branches work on staging? [14:47] I think so. [14:47] Err... yes, it does. [14:47] But of course most of the time it does nothing because the branches aren't hosted on staging. [14:48] I think we even had it run much more frequently on staging for that reason. [14:48] jtv, can we test mwhudson's fix for translations-exporter there? [14:48] Like once an hour or something. [14:48] right, but you can set it up by pushing a branch? [14:48] Right. To staging. [14:48] It has to be set as the translations branch for a productseries, which must have the exports enabled. [14:49] And of course the productseries must have at least one template with at least one actual translation. [14:49] Then I think it's at most an hour's wait. [14:49] jtv, ok, I'll try doing that [14:49] * jtv chokes back pointless Yoda quote [14:51] mwhudson, jtv: just to confirm, when we get to CP, this needs to go to loganberry, right? [14:51] danilos: no, to codehosting. [14:51] jtv, what machine is that? [14:51] danilos: crowberry [14:51] mwhudson, ok, thanks [14:51] (On staging we also have it running on a separate server, so if you want to ask a LOSA for a manual run, be sure to mention it has to run on staging codehosting) [14:52] woo ec2 land detached [14:52] which is good as i'm running out of battery [16:01] gary_poster: I don't understand your review comment... Do I need to "bzr add" the new lazr.batchnavigator in the download cache? The wiki only says to "bzr up" and then "bzr commit" the download cache, which seems pointless. [16:03] jtv, my review comment was trying to say that, if you want to *test* the branch with your new eggs, you can do so without committing to the download-cache via that flag I copied. However, before you *land* your branch, you definitely need to add before you commit--yes, quite pointless otherwise. [16:03] gary_poster: ah ok... I tested by moving my lazr branch inside my lp branch and twiddling the config. [16:04] heh [16:04] ok [16:04] gary_poster: it's a bit unclear: the steps on the wiki for upgrading a package refer to steps 4—6 of installing a package, which don't really say why they're doing this. [16:04] jtv, link? [16:06] gary_poster: oh, not the wiki... this is doc/buildout.txt. [16:06] jtv, ah, ok looking [16:10] jtv, yes, could be clearer. uh...you could make a bug I guess. I assume steps 5 and 6 are obvious but step 4 is a bit more mysterious? That step is about getting the package into download-cache/dist. It does it automatically for you. Copying it over manually is what I tend to do myself, and is just fine, and is more transparent as to what is going on, so perhaps that would be better to recommend. [16:11] gary_poster: well... can' [16:11] t say step 4 was _entirely_ obvious. [16:11] :-) [16:12] For instance I don't recall seeing any "Picked:" output at all, and wouldn't know a spurious one from a... [16:12] an... [16:12] inspurious one. [16:12] :-) If you see "Picked:" at all then it's bad. [16:12] uh [16:12] yeah [16:12] so that may be old [16:14] "You need to see if it means that you have dependencies, some of which may be indirect dependencies." I'd say it was Greek but I might stand a chance of deciphering some of that. :) === Ursinha is now known as Ursinha-lunch [16:23] jtv: please make a foundations bug identifying the confusing bits! [16:23] ok === gary_poster_ is now known as gary_poster === matsubara is now known as matsubara-lunch === Ursinha-lunch is now known as Ursinha === matsubara-lunch is now known as matsubara === gary_poster is now known as gary-lunch === gary-lunch is now known as gary_poster === matsubara is now known as matsubara-afk [23:01] any friendly reviewers around? [23:04] Happy to review, but still a mentat (under mentat?) [23:12] https://code.edge.launchpad.net/~thumper/launchpad/vcs-imports-permission-review/+merge/25047 [23:13] this one clears out some weird old permissions for vcs-imports [23:13] and clears the way to have some community members be in the vcs-import team [23:13] https://code.edge.launchpad.net/~thumper/launchpad/fix-factory-ids-in-tests/+merge/25037 [23:13] tech debt clean up [23:16] * jelmer is reviewing === Ursinha is now known as Ursinha-afk