[00:42] noticed we just passed bug 600000 [00:42] <_mup_> Bug #600000: missing dependency on Bazaar [00:43] \o/ [00:44] is that 600,000 bzr bugs? or am I being a transparent troll again? [01:43] escaping the vortex of home to get some fud [07:23] lifeless: https://bugs.edge.launchpad.net/launchpad-foundations/+bug/600081 [07:23] <_mup_> Bug #600081: count/time of for queries and page rendering should be visible, at least to developers [07:24] what's even better is i can probably fix bug 600000 [07:24] <_mup_> Bug #600000: missing dependency on Bazaar [07:30] poolie: cool, thanks for filing that - really good observation that it should be more visible. [07:32] [07:32] :) [07:32] We can do that just for mbp, if you like. [07:33] giant fist of doom for everyone else [07:35] you are in a web site. there is a performance meter near the top. To the left, some content, to the right a menu. Don't look down. [07:56] and we now have more bugs than bugs.d.o [07:56] despite starting ~8 years later? [07:58] more users of ubuntu, and more users of lp [07:58] and it's easier to file bugs, for better or worse [08:24] good morning === Ursinha is now known as Ursinha-afk [09:42] poolie: reply sent to launchpad-dev list [10:14] thumper, ever wanted to know what tests would fail if we had no branch sample data? http://paste.ubuntu.com/457259/ [10:20] jml: that is cool. I only saw your quesiton; sadly the operational 'work' part of network isn't so much, for me right now. [10:20] jml: its a lot less than it was once, perhaps ? [10:20] lifeless, I don't know. [10:20] lifeless, probably. [10:20] lifeless, I get the impression that the code team hasn't been adding tests which require sampledata, which counts for a lot. [10:20] I'm glad you did that experiment. [10:21] I wonder if its worth putting that in a cron job with an auto merge of trunk and an alert if it increases? [10:21] hmm. [10:22] probably not :) [10:22] I guess I think I could probably fix all of the tests and delete the branch sample data in only a few hours [10:22] the cronjob might take less time, but would be more fiddly [10:22] 82 tests [10:23] yeah. don't forget that the doctests are deceptively big. [10:23] if it was 3 minutes work per test, then I'd agree with that assessment [10:23] right [10:23] so I don't think its a few hours work. [10:23] < 1 week, > a day [10:23] :) [10:23] assuming no surprises [10:24] it would be worth doing a few hours work on it, if you have a few hours up your sleeve. [10:24] I might soon. [10:24] cool [10:24] hmm, back to my slides I think [10:24] me also. [10:24] good bye IRC. === almaisan-away is now known as al-maisan [10:54] Morning, all. [11:49] henninge: been looking at the pottery bug with quoted names in the gettext package name. My solution is to have ConfigFile.getVariable strip quotes (at least if it's clearly a case of a properly-quoted string). === al-maisan is now known as almaisan-away === almaisan-away is now known as al-maisan === matsubara-afk is now known as matsubara [13:27] jtv: sorry, got distracted. [13:27] jtv: yes, that seems to be simple stripping of quotes. [13:27] jtv: I was thinking of another bug that is more complicated. [13:27] henninge: ah [13:27] this is bug 580337 [13:27] <_mup_> Bug #580337: pottery fails with quoted GETTEXT_PACKAGE [13:28] yes, I was thinking of bug 582185 [13:28] <_mup_> Bug #582185: pottery produces "@PACKAGE@.pot" for lp:gawk [13:28] jtv: thanks for going after that fix. [13:30] henninge: do you think I should strip [m4 quotes] as well? [13:30] Or just single/double quotes? [13:30] jtv: I thought I was already doing that. [13:30] Yes, you are... so not sure it has any value. [13:30] I mean, not sure it would have any value for me to add that to getVariable. [13:31] jtv: it would, if you remove it from whereever it is done now. [13:31] It's definitely not limited to this particular variable... so would you like me to strip [bracket quotes] off as well? [13:32] let me take a closer look [13:36] jtv: so, I'd create a function/method that does the stripping and apply it to both the return values of ConfigFile.getVariable and .getFuncitonParams. [13:37] Sounds sensible. [13:37] OK, I can do that. [13:37] jtv: then remove the stripping fom _get_AC_PACKAGE_NAME [13:37] Yu [13:37] p [13:37] jtv: thanks [13:38] ;-) [13:38] but first, OCR. :) I need lunch & sunlight too. === al-maisan is now known as almaisan-away === Mariazinha is now known as Ursinha === jtv is now known as jtv-afk [14:59] flacoste, I remember somebody saying that zope.deferredimport wouldn't help us workaround our circular dependencies. do you know why? === jtv-afk is now known as jtv [15:13] salgado, that does lazy and/or caching imports, does it not? === jtv is now known as jtv-afk [15:14] mars, yes [15:15] salgado, so that would break the import loops, at the expense of making the code look messier :/ === almaisan-away is now known as al-maisan [15:15] IIRC the function and effect is clear when reading the mainline Zope code [15:16] But I also remember that the I saw were primarily for the purpose of marking functions as deprecated [15:17] that's one of the functionalities it provides, but certainly not the primary one [15:21] I must have not realized that when I read the code [15:21] salgado: i don't, i think gary is the one that made the explanation, but he's offline until Monday [15:23] mars, the docs ( http://pypi.python.org/pypi/zope.deferredimport) have just a brief mention of how to use it for deprecating things === jtv-afk is now known as jtv === matsubara is now known as matsubara-lunch [17:22] losa ping [17:22] oops, wrong channel === deryck is now known as deryck[lunch] === cr3_ is now known as cr3 === deryck[lunch] is now known as deryck === matsubara-lunch is now known as matsubara === jtv is now known as jtv-afk === al-maisan is now known as almaisan-away [20:05] leonardr: is there a special way to remove an exported item in the API or is it as simply as removing exported()? [20:05] bdmurray: you need to remove it in a backwards-compatible way (ie. at this point, it has to still be present in beta and 1.0) [20:05] is this a field or a named operation? [20:06] leonardr: its a field - can_expire from the review yesterday [20:06] i believe i mentioned the syntax in my review. let me check [20:08] can_expire_beta = exported(Bool(...), exported_as='can_expire', [20:08] ('devel', dict(exported=False)) [20:08] yes, I think so [20:08] that means it's present in beta and 1.0 but not in devel [20:08] or subsequently [20:08] what do you think of flacoste's comments? [20:08] I agree with them and will remove unexport can_expire [20:09] ok, just remove it totally if you like [20:09] by removing exported() [20:09] so it doesn't need to backwards compatible then? [20:10] bdmurray: i left this to your judgement in a way :-) [20:10] i doubt it was used [20:11] but leaving it for backward compatibility isn't that bad either [20:11] apart for the cruft it leaves in the code [20:11] well, it was and that is what made us realize people were misinterpreting its meaning [20:11] then let's leave it in [20:11] for backward compatibility [20:11] and to some degree, we need to stick with our policy [20:12] otherwise, we'll get burned at some point [20:12] but if they thought it meant something it doesn't mean aren't we helping them? [20:14] and people here is likely 1 or 2 people [20:14] I'd say better to get rid of the cruft [20:14] then [20:14] let's nuke the whole attribute altogether [20:14] their script will blow up though [20:15] I was planning to let the consumers I know of know about this [20:17] but really either way is fine with me === matsubara is now known as matsubara-afk [20:51] where are the current docs for landing an approved branch ? === salgado is now known as salgado-afk [21:14] lifeless: https://dev.launchpad.net/LandingChanges is what I wrote when I researched this for myself. Linked from https://dev.launchpad.net/PatchSubmission, linked from the front page. [21:15] thank you === Ursinha is now known as Ursinha-afk [23:16] sinzui: ping [23:16] hi lifeless [23:17] hiya [23:17] did you get my mail about profiling? [23:18] I did and I think it is fine to keep the config in its module [23:18] I'm popping down to reception to pay for the last week we've been here and pickup some soft drink, but if you want to talk about how to make headyway on milestones, I've got time and interest right after that. [23:18] sinzui: no, I don't mean the config, I mean for use with analysing the milestones timeouts [23:18] Oh, yes I did read your email [23:19] those patches were just me cleaning up the stuff I looked at as I pulled on the 'why isn't profiling easy' thread [23:19] brb [23:28] who was chasing the merge conflict between stable and db-devel? [23:31] sinzui: so yes [23:31] sinzui: you say you haven't made headway; is it just no time, or would you like a hand ? [23:31] Not much time this release [23:32] no worries [23:32] The packaging oopses and feature have precedence. [23:32] if you would like a hand, making things fast is a bit of a passion :) [23:34] I would like a hand. I am exhausted today, but would like to talk about it latter, may be in a few hours after I eat [23:35] enjoy your dinner sinzui [23:35] I'll be mostly around except for a short gap while I go from hotel to poolie's, who is very graciously letting me use a desk @ his place [23:35] anytime you want, ping me [23:36] thanks === flacoste is now known as flacoste_afk