[10:30] <bigjools> can someone review a small branch please?
[11:36] <danilos> bigjools, reviewed your branch, just a few minor comments
[11:37] <bigjools> danilos: great! thanks
[11:37] <danilos> bigjools, let me know once you address them so I approve it :)
[11:37] <bigjools> ok will do, I need to get some time outside of a uds session :)
[11:38] <danilos> bigjools, heh, sure
[14:13] <mwhudson> 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] <danilos> mwhudson, I am taking a look
[14:26] <danilos> 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] <mup> Bug #375013: Cannot commit directly to a stacked branch <commit> <stacking> <Bazaar:Confirmed> <Launchpad Translations:Triaged> <https://launchpad.net/bugs/375013>
[14:26] <mwhudson> danilos: it's a bit relevant i guess
[14:27] <mwhudson> danilos: but i tried to make the change so that it wouldn't break when that bug is fixed
[14:27] <danilos> 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] <danilos> mwhudson, right, sounds good
[14:28] <mwhudson> 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] <danilos> mwhudson, do we do that at all?
[14:30] <danilos> mwhudson, oh, right, that's the get_stacked_on_url
[14:32] <mwhudson> danilos: right
[14:32] <mwhudson> 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] <mwhudson> (although now i think about it a bit more i don't think it would make any practical difference at all)
[14:34] <danilos> 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] <abentley> mwhudson, nothing looks obviously wrong, but you have an empty comment.
[14:39] <mwhudson> abentley: doh
[14:39] <mwhudson>         # commit() records the committed revision in the database record for
[14:39] <mwhudson>         # the branch.
[14:39] <mwhudson> abentley: look ok?
[14:40] <abentley> mwhudson, yes, but I'm now wondering about the relationship of branchChanged and the scanner.
[14:41] <mwhudson> abentley: branchChanged creates a scan job if the passed in revision id is different from last_mirrored_id
[14:43] <abentley> mwhudson, r=me.
[14:44] <mwhudson> abentley: thanks
[14:44] <mwhudson> abentley: can you do that in the ui so i can ec2 land it?
[14:44] <abentley> mwhudson, done.
[14:45] <mwhudson> abentley: merci
[14:45] <danilos> mwhudson, I was just going to r=me as well, but one is good enough :) abentley, mwhudson: thanks!
[14:45] <danilos> mwhudson, can you get this CPed as well, please?
[14:45] <danilos> mwhudson, or should I ask for that?
[14:46] <mwhudson> danilos: i think it would be good to test the fix on staging when it gets there
[14:46] <mwhudson> danilos: does the translations export thingy work on staging?
[14:46] <danilos> mwhudson, sure, sounds good; I think it does, though I'd have to check with jtv first
[14:46] <danilos> mwhudson, we can also cowboy it to staging to speed it up a bit :)
[14:46] <mwhudson> 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] <mwhudson> yeah, that'd help
[14:47] <danilos> mwhudson, sure, thanks
[14:47] <jtv> danilos, mwhudson: check what exactly?
[14:47] <mwhudson> ec2 is booting
[14:47] <danilos> jtv, does export to branches work on staging?
[14:47] <jtv> I think so.
[14:47] <jtv> Err... yes, it does.
[14:47] <jtv> But of course most of the time it does nothing because the branches aren't hosted on staging.
[14:48] <jtv> I think we even had it run much more frequently on staging for that reason.
[14:48] <danilos> jtv, can we test mwhudson's fix for translations-exporter there?
[14:48] <jtv> Like once an hour or something.
[14:48] <mwhudson> right, but you can set it up by pushing a branch?
[14:48] <jtv> Right.  To staging.
[14:48] <jtv> It has to be set as the translations branch for a productseries, which must have the exports enabled.
[14:49] <jtv> And of course the productseries must have at least one template with at least one actual translation.
[14:49] <jtv> Then I think it's at most an hour's wait.
[14:49] <danilos> jtv, ok, I'll try doing that
[14:49]  * jtv chokes back pointless Yoda quote
[14:51] <danilos> mwhudson, jtv: just to confirm, when we get to CP, this needs to go to loganberry, right?
[14:51] <jtv> danilos: no, to codehosting.
[14:51] <danilos> jtv, what machine is that?
[14:51] <mwhudson> danilos: crowberry
[14:51] <danilos> mwhudson, ok, thanks
[14:51] <jtv> (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] <mwhudson> woo ec2 land detached
[14:52] <mwhudson> which is good as i'm running out of battery
[16:01] <jtv> 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] <gary_poster> 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] <jtv> gary_poster: ah ok...  I tested by moving my lazr branch inside my lp branch and twiddling the config.
[16:04] <gary_poster> heh
[16:04] <gary_poster> ok
[16:04] <jtv> 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] <gary_poster> jtv, link?
[16:06] <jtv> gary_poster: oh, not the wiki... this is doc/buildout.txt.
[16:06] <gary_poster> jtv, ah, ok looking
[16:10] <gary_poster> 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] <jtv> gary_poster: well... can'
[16:11] <jtv> t say step 4 was _entirely_ obvious.
[16:11] <gary_poster> :-)
[16:12] <jtv> For instance I don't recall seeing any "Picked:" output at all, and wouldn't know a spurious one from a...
[16:12] <jtv> an...
[16:12] <jtv> inspurious one.
[16:12] <gary_poster> :-) If you see "Picked:" at all then it's bad.
[16:12] <gary_poster> uh
[16:12] <gary_poster> yeah
[16:12] <gary_poster> so that may be old
[16:14] <jtv> "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.  :)
[16:23] <gary_poster> jtv: please make a foundations bug identifying the confusing bits!
[16:23] <jtv> ok
[23:01] <thumper> any friendly reviewers around?
[23:04] <jelmer> Happy to review, but still a mentat (under mentat?)
[23:12] <thumper> https://code.edge.launchpad.net/~thumper/launchpad/vcs-imports-permission-review/+merge/25047
[23:13] <thumper> this one clears out some weird old permissions for vcs-imports
[23:13] <thumper> and clears the way to have some community members be in the vcs-import team
[23:13] <thumper> https://code.edge.launchpad.net/~thumper/launchpad/fix-factory-ids-in-tests/+merge/25037
[23:13] <thumper> tech debt clean up
[23:16]  * jelmer is reviewing