[00:03] <gary_poster> lifeless: hey.  bad news: I have a 1336 line MP.  possibly good news: it is for ++profile++ .  https://code.edge.launchpad.net/~gary/launchpad/lsprof-on-demand/+merge/33849 if you want to look at it, or I'll try to get someone to look at it tomorrow.
[00:16] <lifeless> gary_poster: thanks
[00:19] <lifeless> gary_poster: it still drops the profile output in the previous place ?
[00:20] <gary_poster> lifeless, yes.  configurable.
[00:20] <lifeless> I have a suggestion
[00:20] <gary_poster> cool;
[00:20] <lifeless> if we used a feature flag
[00:21] <lifeless> with a scope that matches users in canonical-launchpad
[00:21] <lifeless> it would be less risky to have on on staging
[00:21] <lifeless> and also permit turning it on and off without rebooting the appserver
[00:22] <lifeless> you could do this without any schema changes
[00:22] <lifeless> its just a thought
[00:23] <gary_poster> lifeless, that sounds great.  want that in a separate branch?
[00:24] <lifeless> something else that would be really lovely
[00:24] <lifeless> is a kcachegrind file on disk (and oops on disk); and a way to download them (again, enabled for specific users/groups by flags)
[00:26] <lifeless> gary_poster: in end_request, you've added a bunch of vertival white space
[00:26] <lifeless> this is a matter of taste, but I find that very jarring when reading a function
[00:26] <lifeless> I prefer either no VWS or separate functions.
[00:27] <gary_poster> lifeless, download: I maybe could make ++profile++download download the kcachegrind.
[00:27] <lifeless> (PEP8 says to use it for 'significant regiosn's (misquoting)
[00:28] <gary_poster> VWS: OK.  I liked it here obviously, but it was very...organic.  Happy to remove it.
[00:28] <lifeless> we don't need docstrings on tests btw
[00:29] <lifeless> or if we do its nuts :)
[00:29] <lifeless> as long as the intent is clear
[00:29] <lifeless> if its vague, a docstring or comment to make it clear is good in its own right
[00:29] <lifeless> 1334	+
[00:29] <lifeless> 1335	+def test_suite():
[00:29] <lifeless> 1336	+    return unittest.TestLoader().loadTestsFromName(__name__)
[00:29] <lifeless> thats not needed now
[00:31] <lifeless> gary_poster: approved
[00:32] <gary_poster> lifeless: awesome thanks
[00:42] <lifeless> gary_poster: there was one other thing
[00:43] <lifeless> the 'tests are not setting stuff up so ignore it' squicks me; I realise why, and the pragmatic need, but I'd like to be able to put a ratchet on those tests and eliminate the badness.
[00:43] <gary_poster> lifeless: not clear what you mean yet?
[00:43] <gary_poster> oh!
[00:44] <gary_poster> yeah that was annoying
[00:44] <gary_poster> what do you have in mind for ratcheting?
[00:44] <lifeless> well
[00:44] <lifeless> depends on how widespread it is I guess
[00:45] <lifeless> if its only a few root causes, like some test helpers, we could just do warning.warn() in a branch, and iterate on the branch till its done.
[00:45] <lifeless> if its more substantial, perhaps starting the test suite could empty a file
[00:45] <lifeless> and each occurence be logged (one line per)
[00:45] <lifeless> and the total number of lines reported at the end
[00:45] <gary_poster> between a few and several.  I have to run though.  Please copy that in to the MP and I'll act on it tomorrow.
[00:45] <lifeless> lint could report if that file is longer than N
[05:42] <mwhudson> thumper: care to look at https://code.edge.launchpad.net/~mwhudson/launchpad/cross-product-spec-links-bug-3552/+merge/33866 ?
[05:43] <thumper> mwhudson: on a friday afternoon?
[05:43] <thumper> mwhudson: just before beer?
[05:43] <mwhudson> thumper: it'll make the beer taste better
[05:44] <mwhudson> mm, proportionally fonted diffs
[05:46] <thumper> mwhudson: line 23 of the diff
[05:47] <mwhudson> thumper: lolz
[05:48] <mwhudson> thumper: fix being pushed
[06:23] <lifeless> hmm, exported_as doesn't work if there is an attribute with the same name that isn't exported.
[06:23] <lifeless> echannel
[06:29] <mwhudson> thumper: thanks
[08:07] <henninge> jtv: fancy a quick review?
[08:07] <henninge> https://code.edge.launchpad.net/~henninge/launchpad/recife-pofile-creation/+merge/33800
[08:08] <jtv> henninge: coming
[08:08] <henninge> jtv: thanks
[08:09] <jtv> henninge: in this test you say "shared" POTemplates.  IIRC Danilo has been calling them "sharing" POTemplates.
[08:10] <jtv> Also, "a <thing> has the same name" is a bit nonsensical—same name as what?
[08:10] <henninge> jtv: right, I copied that comment without thinking.
[08:10] <jtv> That explains the old-style setup as well.
[08:10] <henninge> And I have always ued 'shared'.
[08:11] <henninge> jtv: what's 'old-style' ?
[08:11] <jtv> I think "shared" is misleading here, because the POTemplate isn't shared.  It shares things with other POTemplates.
[08:11] <henninge> I see
[08:11] <jtv> Old-style is relying on sample data (hoary and warty) instead of creating fresh data.
[08:12] <jtv> (*) in this context.  :)
[08:12] <jtv> After that it suddenly goes into the new style.
[08:12] <henninge> jtv: Good point. I will change that.
[08:13] <jtv> Also, you can shortcut some of the setup by letting the first self.factory.makeSourcePackage cal create your SourcePackageName for you.
[08:13] <jtv> *call
[08:14] <jtv> Probably your distroseries as well.
[08:15] <jtv> Otherwise it's just too much setup to read through!
[08:17] <jtv> henninge: in the comment for test_pofile_creation_shared_in_ubuntu, I assume "POTemplate of project" means "POTemplate of a project," not some other typo such as "POTemplate or project"?
[08:20] <henninge> jtv: you are right
[08:35] <henninge> jtv: Don't think I'll get around an explicit distroseries creation because it has to be for Ubuntu, does it not?
[08:37] <jtv> henninge: ouch—I thought that's what we got.  The code you're testing here is probably one of the very few places that care about the difference.
[08:41] <henninge> jtv: Also, in the second test I use sourcepackagename so often that I'd put it in a variable anyway and creating it explicitely keeps the source packages creation symetric.
[08:42] <jtv> henninge: whatever works for you—just try not to throw too much text at the reader!
[08:42] <jtv> it's not all about the number of lines though.
[08:43] <jtv> A short assignment line is generally easier to read than a very long one with a method call in it and lots of mixed-case letters.
[08:48] <StevenK> adeuring: Hi! Got time to review a trivial MP for me?
[08:48] <adeuring> StevenK: sure (except for a not yet sufficient caffeine level ;)
[08:49] <StevenK> adeuring: https://code.edge.launchpad.net/~stevenk/launchpad/lucille-archivepermission/+merge/33873 when you're sufficently caffeinated
[08:49] <adeuring> StevenK: where is it?
[09:02] <adeuring> StevenK: so, the method newPackageUploader needs to be called by the db user 'lucille'. What does lucille do? And do we know if lucille indeed adds permissions only for people who should get them?
[09:03] <StevenK> adeuring: No, that isn't it, that's just set up.
[09:03] <StevenK> adeuring: The code that this actually affects is in part of the code that didn't change -- it adds new archivepermission rows directly into the database during initialise-from-parent
[09:05] <adeuring> StevenK: so, some sort of copy operationß
[09:05] <adeuring> sß/?/
[09:05] <StevenK> adeuring: Yes, it is initialising a child distroseries from its parent
[09:06] <adeuring> StevenK: ah, ok. r=me then
[09:06] <StevenK> adeuring: Thank you!
[09:07] <noodles775> adeuring: one-liner to fix the latest db-devel test-fix (when the MP diff updates): https://code.edge.launchpad.net/~michael.nelson/launchpad/db-devel-import-fix-20100827/+merge/33876
[09:08] <StevenK> noodles775: Oh, if you're going to fix db-devel, I noticed a .THIS file crept in, can you bin it?
[09:08] <noodles775> StevenK: sure
[09:09] <adeuring> noodles775: approved
[09:10] <noodles775> adeuring: thanks. I've just pushed 9708 which deletes the .THIS file StevenK mentioned.
[09:10] <adeuring> noodles775: well, that's fine, I think ;)
[09:10] <noodles775> StevenK: my landing will remove it from db-devel, but it's actually committed in devel.
[09:11] <noodles775> Thanks adeuring
[09:11] <StevenK> Rah
[09:12] <StevenK> noodles775, adeuring: I have a branch ready for devel, shall I kill that .THIS file in it?
[09:12] <noodles775> StevenK: Sounds good.
[09:12] <adeuring> StevenK: makes sense
[10:28] <gmb> adeuring, Could you review https://code.edge.launchpad.net/~gmb/launchpad/lp-devs-can-reset-watches/+merge/33796 for me please?
[10:29] <adeuring> gmb: sure
[10:29] <gmb> Thanks
[10:33] <noodles775> stub or lifeless: do either of you have time to review a 70line db patch? https://code.edge.launchpad.net/~michael.nelson/launchpad/distro-series-difference-schema/+merge/33515
[10:34] <noodles775> Hi again adeuring, when you've time, can you please take a look at https://code.edge.launchpad.net/~michael.nelson/launchpad/distro-series-difference-basic-model/+merge/33885
[10:35] <adeuring> noodles775: sure
[10:56] <adeuring> gmb: r=me; 1 nitpick
[10:57] <gmb> adeuring, Thank you.
[10:59] <gmb> adeuring, foo*Condition is the usual naming idiom for methods used to decide whether or not we can display an action. Maybe showResetActionCondition() would be clearer.
[10:59] <adeuring> gmb: right, that's better!
[10:59] <gmb> Right, I'll do that, then.
[10:59] <gmb> Thanks adeuring.
[10:59] <stub> noodles775: Reviewed. The derived distro series calling its parent the derived distro series seems a problem.
[11:00] <noodles775> stub: thanks... looking.
[11:00] <stub> Or I think I'm just confused..
[11:00] <stub> oic. This is the difference, it points to the derived distro series, there is some other link that points to the parent series.
[11:01] <noodles775> Yes, there's a reference from IDistroSeries.parent_series... which is why we only need to reference the one (derived) series here.
[11:01] <stub> DistroSeries.parent_series already exists.
[11:01] <stub> Ok... rereviewing :)
[11:01] <noodles775> Correct.
[11:02] <noodles775> Thanks.... just reading your other comments :)
[11:04] <noodles775> stub: Why would we want delete permissions? At the moment I'm planning that these differences will end in a resolved state, but we wouldn't want to delete them until the derived distroseries is itself deleted (if it ever is).
[11:05] <stub> The derived distribution has a patched version of firefox. Tomorrow it decides that it should just use the parents version of firefox.
[11:07] <noodles775> Great, so assuming the parents version has a higher revno, they upload it, this record is marked as resolved and the activity log is updated, but the record is not deleted, as tomorrow the parent might upload a new version, and the previous comments/activity is still useful.
[11:07] <stub> ok
[11:08] <stub> How big do you think the comments and activity will grow?
[11:08] <stub> It will be a pain to split out into a structured format later.
[11:10] <stub> If it is append only, storing it as a single text blob isn't ideal. If it is more a whiteboard or a copy of a text file stored in a branch, that would be fine I guess.
[11:10] <noodles775> On average 4 or 5 lines. If a particular difference goes through resolved->needs attention-> resolved it would be a few more.
[11:10] <stub> But over time
[11:11] <noodles775> Yes, it is just like a whiteboard.
[11:11] <stub> ok
[11:11] <noodles775> Yep, so if overtime it went through that cycle (resolved->needs attention->resolved) *lots*, there would be 2 lines for each change.
[11:11] <noodles775> Do you think its worth adding a separate comment model?
[11:12] <noodles775> (from memory the code/bugs guys made the comment model re-usable... I'll check).
[11:14] <noodles775> stub: oh, and I think I misunderstood your comment above. I am making the activity_log append only.
[11:17] <stub> So we would probably be better off with a separate table containing the activity, one row per addition. Or even a link table between distroseriesdifference and message same as our other comment spools.
[11:18] <noodles775> Yep, just looking at the message table... I'll do that then.
[11:18] <noodles775> Thanks stub.
[11:19] <stub> That gives you the infrastructure for attachments, email interfaces etc. if we want them in the future.
[11:20] <noodles775> Yeah, given that the table already exists, it sounds crazy not to use it.
[11:39] <jtv> noodles775: this definitely needs code review and it may also need UI review: https://code.edge.launchpad.net/~jtv/launchpad/bug-517700/+merge/33888
[11:39] <jtv> (Sorry for the diff size… I didn't exactly aim to use up the entire budget)
[11:40] <jtv> Drat.  Doesn't linkify the bugs in = Bugs 484375, 517700 =
[11:41] <jtv> bugs 484375, 517700
[11:41] <jtv>  That used to work.
[11:41] <jtv> noodles775: oh, hang on—there's conflict now (also neatly pulling it across the 800-line limit)
[11:43] <noodles775> jtv: did you mean adeuring ?
[11:43] <jtv> noodles775: arrrgh, yes, sorry… an experiment in reading the topic line from the tiny low-contrast fineprint my client shows at the top of the window
[11:44] <adeuring> jtv: I'll look at it
[11:44] <jtv> adeuring: hang on, I've got some conflicts to resolve first!
[11:44] <adeuring> jtv: ok, ping me when the branch is ready
[12:02] <jtv> adeuring: MP has updated — https://code.edge.launchpad.net/~jtv/launchpad/bug-517700/+merge/33888
[12:03] <adeuring> jtv: OK, let me first finish the review for noodles775, then I'll need a lunch break, then i'll look at your branch
[12:03] <jtv> adeuring: great, thanks.  I'll probably be out by then, unfortunately
[12:08] <noodles775> stub: updated with an incremental, but feel free to leave it for Monday :D Thanks.
[12:08]  * noodles775 lunches
[12:22] <jtv> bigjools: https://code.edge.launchpad.net/~jtv/launchpad/fakelibrarian-fixture/+merge/33892
[12:22] <jtv> bigjools: I thought you might like to review that one.  :)
[12:27] <adeuring> noodles775: in test_new_non_derived_series(), you are using  the factory method in assertRaises, which is IMHO quite indirect. What about testing the new() method directly?
[13:10] <jelmer> adeuring: Hi, can I add another mp to your queue?
[13:11] <adeuring> jelmer: sure
[13:15] <jelmer> adeuring: Thanks; the MP is at https://code.edge.launchpad.net/~jelmer/launchpad/613468-xb-ppa-qa/+merge/33804
[13:18] <noodles775> adeuring: Yep, I'll update.
[13:28]  * jtv chears adeuring on
[13:29] <jtv> *cheers
[13:53] <bac> hi adeuring
[13:53] <adeuring> hi bac1
[13:53] <adeuring> bac!
[13:55] <bac> hi adeuring, i'm ocr today but won't be able to help for a couple of hours.
[13:55] <adeuring> bac: ok, no problem
[13:55] <bac> thanks abel.
[13:56] <adeuring> (except perhaps for people needing a review after 1730UTC ;) I have an appointment this evening...
[13:56] <adeuring> erm, 1700UTC..
[14:19] <adeuring> jtv: r=me
[14:25] <jtv> adeuring: splendid, thank you
[14:25] <adeuring> welcome :)
[14:45] <benji> my MP is at https://code.launchpad.net/~benji/launchpad/bug-580035/+merge/33911; it's for a bug in a bug fix (found while doing QA)
[14:59] <adeuring> jelmer: R=Me
[14:59] <adeuring> (no longer r=me)
[14:59] <adeuring> ...for this branch ;)
[14:59] <jelmer> adeuring: :-)) and thanks
[15:21] <adeuring> benji: GPGHanlder.getVerifiedSignature() can raise GPGVerificationError. I think this exception should be caught in extract_signature_timestamp()
[15:22] <adeuring> erm, or in ensure:sane:signaturetimestamp()
[15:22] <adeuring> ...or are we sure that we have a valid signature?
[15:23] <benji> adeuring: at the point that I call GPGHanlder.getVerifiedSignature() it has already been called successfully
[15:23] <benji> right
[15:23] <adeuring> benji: ok, thanks!
[15:33] <adeuring> benji: r=me
[15:34] <benji> danke
[15:35] <benji> adeuring: it says "Approve (code)" but at the top still says "Status:
[15:35] <benji> Needs review"
[15:36] <adeuring> benji: fixed
[15:36] <benji> thanks
[16:07] <bac> hi jelmer
[16:07] <sinzui> adeuring, bac: I have a branch for review
[16:07] <bac> jelmer: i'm looking at https://code.edge.launchpad.net/~jelmer/launchpad/buildmaster-enums/+merge/33893
[16:07] <jelmer> hi Brad
[16:07] <adeuring> sinzui: I'll look
[16:07] <bac> at line 379 is it really necessary to do the import locally?
[16:08] <sinzui> adeuring, bac: I am going to start work on a branch to disable google maps. We are treating this as a critical issue.
[16:08] <bac> sinzui: ok
[16:09] <jelmer> bac: Thanks. 379 is a removed line here in the diff
[16:09] <adeuring> sinzui: the mp i should at is this one: https://code.edge.launchpad.net/~sinzui/launchpad/licenses-0/+merge/33916 ? Or the google maps branch?
[16:09] <jelmer> bac: 511 has a local import that I couldn't really work around.
[16:10] <bac> jelmer: you pushed a new branch since i started looking at it, that's why the line numbers don't match
[16:11] <jelmer> bac: Ah, my bad - sorry. I intended to push that to a separate branch.
[16:11] <bac> but in that MP line 511 is the one i was asking about
[16:11] <jelmer> bac: Would you like me to remove that revision or is the MP fine as is (it's a bit large)
[16:12] <bac> jelmer: the branch is so mechanical it doesn't matter
[16:13] <jelmer> bac: Ok
[16:13] <jelmer> bac: I can probably work around the local import by putting BUILDD_MANAGER_LOG_NAME in a separate module. manager.py seems like the best place for it though.
[16:14] <bac> jelmer: the local import isn't critical...just wanted to make sure there was a good reason for it.  if you can remove the need without a lot of hassle that would be great.
[16:27] <bac> jelmer: r=bac, with some import sorting fixes.  perhaps you can find henning's tool and run it? (though that would take longer than doing it by hand i suspect.)
[16:28] <jelmer> bac: I should get used to doing it right in the first place so I'll do it by hand. :-) Thanks for the review
[16:28] <bac> np jelmer.   thanks for the branch.
[16:29] <henninge> bac: I am working on putting it into the tree ATVM. ;-)
[16:30] <bac> henninge: i'll happily review it.
[16:37] <henninge> bac: should I add tests?
[16:37] <henninge> ;)
[16:38] <bac> henninge: that would be nice, of course.  but we do have lots of thing in utilities that are stand-alone tools that don't have tests.
[16:39] <henninge> bac: since the tool changes other files in the tree, the real test is if those changes break the test suite.
[16:40] <henninge> or not
[16:40] <bac> henninge: you've sold me
[16:40]  * henninge prepares MP ;)
[16:48] <henninge> Actually, let me add something else first.
[17:19] <henninge> bac: Here it is:
[17:19] <henninge> https://code.edge.launchpad.net/~henninge/launchpad/format-imports/+merge/33926
[17:22] <bac> thanks henninge
[17:27] <bac> henninge:  i don't understand the comment describing FIRST
[17:28] <bac> do we actually use that anywhere?
[17:28] <henninge> once
[17:28] <henninge> bac: It's about imports that need other imports.
[17:29] <henninge> I feared we'd have more problems like that but luckily only two.
[17:29] <henninge> one of which is lib/canonical/launchpad/interfaces/__init__.py which is the only use of the "SKIP" comment.
[17:30] <henninge> the other one is in lp.code
[17:30] <henninge> bac: sorry, "imports that need other imports" is badly put. It's about import ordering.
[17:31] <bac> henninge: so there are imports that must be done in a specific order or they fail?
[17:31] <henninge> bac: yes, or so says the comment.
[17:31] <henninge> I don't like that very much, either.
[17:31] <henninge> let me find it
[17:31] <bac> cool
[17:32] <henninge> lib/lp/code/bzr.py
[17:47] <henninge> bac: I will end my week now. Do you have any more questions?
[17:50] <bac> henninge: no.
[17:50] <henninge> cool
[17:50] <bac> henninge: sadly, i just ran your tool against lp/registry and it created a 231 line diff
[17:51] <henninge> oops
[17:51] <bac> so in just a week we've diverged that much
[17:54] <bac> henninge: one more question
[17:55] <bac> henninge: you say embedded comments will break the formatter.  is that reported at all or is it so broken you don't get a chance?
[17:58] <henninge> bac: it's not reported at all
[17:59] <bac> henninge: ok.  i guess it'll create such a mess that it'll be easily discovered
[17:59] <henninge> bac: we only had one case like that in the tree that I simply fixed before running the tool
[17:59] <bac> sorry to keep you henninge.  i'll finish the review after lunch.  have a good weekend.
[17:59] <henninge> bac: thank you
[18:00] <henninge> bac: enjoy your lunch ;-)
[18:00] <bac> henninge: i shall...but it's getting cold.
[18:00] <henninge> sorry to keep you ... ;)
[19:47] <benji> indeed; I had almost exactly the same reaction
[19:47] <benji> the thing is, the few things I'd like (probably the same ones you're referring to) would be pretty easy to implement in Python 2
[19:48] <benji> I really wish I had the desire to be the new BDFL.  Now's the time for a Coup d'état.
[19:49] <benji> yeah, I expect most of those won't, but I don't see why most of those couldn't be backported
[19:50] <benji> oops, I'm in the wrong chan
[20:04] <benji> bac: watch out!  https://code.launchpad.net/~benji/launchpad/bug-622765/+merge/33951
[20:06]  * bac ducks
[20:06] <benji> heh
[20:19] <benji> bac: for some reason my MP just shows "Approve (code)" and still shows "Needs review" at the top.  That's the third time that's happened to me.  Has the review UI changed for reviewers?
[20:20]  * benji really needs to start on getting his reviewer merit badge.
[20:20] <bac> benji: that reason would be it is a two step process and i forgot to do the second step
[20:20] <benji> it's the processes fault ;)
[20:21] <bac> benji: reviewers should set it.  when they forget, you can still proceed using 'ec2 land --force'  ... but it is better to just bug them.
[20:21] <bac> benji: done
[20:22] <benji> I like to bug people... everyone wins!
[21:17] <jcsackett> hello, bac.
[21:17] <jcsackett> https://code.edge.launchpad.net/~jcsackett/launchpad/deprecate-official_codehosting/+merge/33953
[21:17] <jcsackett> have time for another review today?
[21:17] <bac> jcsackett: sure
[21:17] <jcsackett> awesome.
[21:18] <jcsackett> bac, this one shouldn't take too long.
[21:18] <jcsackett> apologies if it does.
[22:43] <jcsackett> bac: re your comments, i actually thought it was clearer with the full if structure than "var = (usage_enum == ServiceUsage.something). you think the compressed version would be better?