| * StevenK stabs the lack of completion for bzr rm | 01:42 | |
| wgrant | StevenK: How's the ec2 run looking? | 02:30 |
|---|---|---|
| StevenK | branch-privacy-properties => devel [OK] (up for 2:33:55) i-2ca43755 | 02:33 |
| wgrant | Good good | 02:38 |
| * StevenK smacks wgrant. | 02:38 | |
| StevenK | steven@undermined:~/launchpad/lp-branches/devel% grep -c '^# ' lib/lp/bugs/model/bugtaskflat.py | 02:38 |
| StevenK | 0 | 02:38 |
| wgrant | Oops, indeed. | 02:39 |
| StevenK | wgrant: Do I need to add access_policy and access_grants to {I,}Branch, or are they internal only? | 02:39 |
| StevenK | I note BTF is missing access_policies and access_grants on its model. | 02:40 |
| wgrant | StevenK: We'll likely add them later, but you can't add them in this branch. | 02:40 |
| StevenK | wgrant: Sure, they have to wait until the DB patch hits prod and devel | 02:40 |
| wgrant | And then you'll add them if you need them. | 02:41 |
| wgrant | And not add them if you don't need them. | 02:41 |
| wgrant | Same as any other piece of code :) | 02:41 |
| StevenK | I was plotting writing tests for the DB patch, which made me ponder model code. | 02:41 |
| wgrant | lib/lp/bugs/tests/test_bugtaskflat_triggers.py may be of some interest. | 02:42 |
| wgrant | wallyworld: Why'd you delete that branch? It attracted the Scanner's Curse? | 02:43 |
| wallyworld | yes | 02:44 |
| wgrant | :( | 02:44 |
| wgrant | I still haven't been able to reproduce that locally. | 02:44 |
| wallyworld | it won't delete properly either it seems | 02:44 |
| wgrant | Yeah, you can't delete lp:launchpad branches any more. | 02:44 |
| wgrant | Not once they've started to scan. | 02:44 |
| wallyworld | well it lets me try | 02:44 |
| wgrant | Sure. | 02:44 |
| wallyworld | and then errors in a funny way | 02:44 |
| wgrant | Then it 502s. | 02:44 |
| wallyworld | why? | 02:45 |
| wallyworld | it sholdn't let me delete | 02:45 |
| wallyworld | if i'm not supposed to | 02:45 |
| wgrant | It should let you delete. | 02:45 |
| wgrant | You are supposed to. | 02:45 |
| wgrant | It just doesn't work. | 02:45 |
| StevenK | Because BranchRevision exists | 02:45 |
| wallyworld | hooray! | 02:45 |
| wgrant | I'm not sure exactly what's going on, but I *believe* that the BranchRevision delete is unflushed at the end of the request. | 02:45 |
| wgrant | So the commit() in the response post-processing flushes the 90krow delete outside the timeout. | 02:46 |
| wgrant | And crashes. | 02:46 |
| wallyworld | not good | 02:46 |
| wgrant | s/outside the timeout/outside the timeout exception handler/ | 02:46 |
| wgrant | It probably turns into a normal timeout if we flush explicitly after the delete. | 02:46 |
| wgrant | wallyworld: I'll review that branch after lunch, btw. | 02:52 |
| wallyworld | wgrant: no problem. whenever :-) | 02:52 |
| StevenK | Wow, a smile from wallyworld. | 02:53 |
| wallyworld | >:-( | 02:53 |
| mwhudson | isn't branchrevision deleted by an ON DELETE CASCADE? | 02:54 |
| mwhudson | which is another way of saying the same thing i guess | 02:54 |
| mwhudson | btw buildout is very slow if you strace it :) | 02:55 |
| StevenK | s/ if you strace it// | 02:56 |
| wgrant | mwhudson: Ah, indeed. | 03:03 |
| wgrant | That explains why it's unflushed. | 03:03 |
| mwhudson | could this be a pg9.1 regression? | 03:04 |
| wgrant | No | 03:04 |
| mwhudson | or has it been a problem for a while? | 03:04 |
| wgrant | It's been a problem forever, it's just more prevalent now with the lower timeout. | 03:04 |
| wgrant | You used to have to retry a couple of times to delete big branches. | 03:04 |
| StevenK | Can we bump the timeout for Branch:+delete? | 03:05 |
| StevenK | The 'proper' fix is the death of destruction of most of BranchRevision | 03:05 |
| mwhudson | yes | 03:06 |
| wgrant | wallyworld: 70+ if safe_hasattr(user_or_reference, 'id'): | 03:11 |
| wgrant | wallyworld: Can that be replaced by IPerson.providedBy(user_or_reference)? | 03:11 |
| wallyworld | no, cause it's not always a person, could be PersonRoles | 03:12 |
| wgrant | wallyworld: Perhaps try adapting it to IPersonRoles? | 03:13 |
| wgrant | Then you can just say IPersonRoles(user_or_reference).in_admin | 03:13 |
| wgrant | If the adaption fails, it's not a person or an IPersonRoles. | 03:14 |
| wallyworld | i guess it will fail by returning None? | 03:14 |
| wgrant | wallyworld: By default it'll raise a TypeError | 03:15 |
| wgrant | But the second arg specifies a default | 03:15 |
| wgrant | So IPersonRoles(1, None) will return None | 03:15 |
| wallyworld | that's the one i'll use, i don't like flow control by exception | 03:15 |
| wgrant | It is good to avoid where possible, indeed. | 03:15 |
| wgrant | wallyworld: Looks like the branch fixes bug #1009360, bug #1009358 (maybe?), bug #1009281? | 03:25 |
| _mup_ | Bug #1009360: RemoveBugSubscriptionsJob duplicates get_bug_privacy_filter <disclosure> <tech-debt> <Launchpad itself:Triaged> < https://launchpad.net/bugs/1009360 > | 03:25 |
| _mup_ | Bug #1009358: Unsharing information from a team doesn't remove the members' bug subscriptions <disclosure> <Launchpad itself:Triaged by wallyworld> < https://launchpad.net/bugs/1009358 > | 03:25 |
| _mup_ | Bug #1009281: SharingService.deletePillarSharee revokes all access to any involved artifacts <disclosure> <Launchpad itself:Triaged> < https://launchpad.net/bugs/1009281 > | 03:25 |
| wgrant | 1009358 is linked already, nevermind | 03:25 |
| wgrant | The other two aren't, though. | 03:25 |
| wallyworld | ah, didn't realise thise were filed | 03:25 |
| wallyworld | but yes | 03:25 |
| wallyworld | i'll link those to the branch | 03:25 |
| wgrant | Great, thanks | 03:25 |
| wallyworld | wgrant: that should be fixed now | 03:41 |
| wgrant | wallyworld: Great. I'm experimenting with refactoring the admin specialcase. | 03:42 |
| wgrant | Since everywhere that needs to do it ends up mildly hideous. | 03:43 |
| wallyworld | wgrant: should that be done in a separate branch? i'd like to get this one (and the next) landed | 03:44 |
| wgrant | 318+ getUtility(IRemoveBugSubscriptionsJobSource).create( | 03:53 |
| wgrant | 319+ user, bugs=None, information_types=information_types) | 03:53 |
| wgrant | wallyworld: Doesn't that need a pillar restriction? | 03:53 |
| wgrant | Otherwise it's going to do a full consistency check over every bug of that information type. | 03:53 |
| wallyworld | yes, that's the intent at the moment | 03:54 |
| wallyworld | but i could add a pillar check in | 03:54 |
| wgrant | We can't run it on production like that, but I guess it's a reasonable intermediate. | 03:55 |
| wallyworld | that bit was ported across from the deleted remove grantee job | 03:55 |
| wgrant | In the long-term we probably want to restrict to bugs with the relevant AP and a subscriber in the team. | 03:55 |
| wgrant | The join through BugSubscription + TeamParticipation is not completely cheap, but it's far cheaper than a full consistency check. | 03:55 |
| wallyworld | wgrant: i have to go pick up the kid, be back later. i'll add the pillar check before landing | 04:03 |
| wgrant | wallyworld: Thanks, I'm almost done. | 04:03 |
| wallyworld | ok, no rush | 04:03 |
| wgrant | Would be done quicker if the celery job tests weren't hanging... | 04:03 |
| wallyworld | yeah, that happens sometimes to me too | 04:03 |
| StevenK | wgrant: branch-privacy-properties => devel [OK] (up for 4:05:35) i-2ca43755 | 04:05 |
| wgrant | StevenK: Excellent. It's landing rather than testing? | 04:05 |
| StevenK | It will land | 04:05 |
| StevenK | wgrant: r15414 | 04:13 |
| wgrant | Marvellous. | 04:14 |
| StevenK | It's about seven hours away from stable. | 04:16 |
| wgrant | We're fixing that. | 04:16 |
| StevenK | We are? | 04:16 |
| wgrant | I also filed RTs this morning to make qastaging updates faster. | 04:16 |
| wgrant | Well, the test suite will take half an hour soon :) | 04:16 |
| StevenK | wgrant: More than one RT? | 04:17 |
| wgrant | Well, one thing was only tangentially related. | 04:17 |
| wgrant | Oh | 04:27 |
| wgrant | Bah | 04:27 |
| wgrant | Test was failing because the job was crashing because of a typo, and the test didn't notice | 04:27 |
| micahg | Bug #590523 doesn't seem to have been triaged to a specific type of failure on that page, if I have a new OOPS, should I just add it to the page or file another bug? | 05:10 |
| _mup_ | Bug #590523: Archive:+delete-packages times out <boobytrap> <lp-soyuz> <timeout> <Launchpad itself:Triaged> < https://launchpad.net/bugs/590523 > | 05:10 |
| micahg | s/page/bug/ | 05:10 |
| wgrant | micahg: Add it to that page. | 05:12 |
| micahg | thanks | 05:12 |
| StevenK | wallyworld, wgrant: https://code.launchpad.net/~stevenk/launchpad/fix-copyrights/+merge/110229 | 05:23 |
| wgrant | StevenK: lib/lp/app/__init__.py wants reverting | 05:23 |
| wgrant | It's a file of monkeypatches without an import section, really. | 05:24 |
| StevenK | wgrant: Done. | 05:26 |
| wgrant | StevenK: lib/lp/services/database/locking.py's __all__ is in the wrong place. | 05:27 |
| StevenK | wgrant: Also fixed | 05:28 |
| StevenK | The branch is now at +1 | 05:28 |
| wgrant | Otherwise it's good | 05:30 |
| wgrant | Thanks | 05:30 |
| wgrant | micahg: Hah | 05:35 |
| wgrant | micahg: Copying 4 sources with a total of more than 250 binaries in one operation. | 05:36 |
| wgrant | micahg: I am not surprised it timed out. | 05:36 |
| micahg | I'm special :) | 05:36 |
| wgrant | So, the solution to the bug is to not do that. | 05:39 |
| wgrant | Because it's not sensible :) | 05:39 |
| micahg | wgrant: umm, to copy 4 source packages to 4 different series in the same PPA shouldn't require 4 times through the page | 05:39 |
| wgrant | For a sensible source package, sure. | 05:40 |
| micahg | maybe it should just be done asynchronously | 05:40 |
| wgrant | You can't make any assumptions about sources averaging 62 binaries each | 05:40 |
| wgrant | Probably, yes. | 05:40 |
| StevenK | PCJ? | 05:40 |
| wgrant | die | 05:40 |
| bigjools | I have a plan for async ppa copies | 05:41 |
| * micahg loves copyPackage | 05:41 | |
| bigjools | just never got around to implementing it | 05:41 |
| wgrant | micahg: So, how can there possibly be more than 250 binaries? | 05:41 |
| wgrant | l10n? | 05:41 |
| micahg | wgrant: yes, the l10n packages were made arch:any because of skew issues | 05:41 |
| wgrant | blink | 05:42 |
| wgrant | When was this? | 05:42 |
| StevenK | micahg: !!! | 05:42 |
| micahg | or was there another reason for that... | 05:42 |
| wgrant | Recall that we now keep arch-all published until all the arch-any are gone. | 05:42 |
| micahg | StevenK: I didn't do it :) | 05:42 |
| wgrant | But making them all arch-any is just completely ridiculous and not justifiable :) | 05:42 |
| micahg | wgrant: http://bazaar.launchpad.net/~mozillateam/thunderbird/thunderbird.lucid/view/head:/debian/changelog#L123 | 05:45 |
| micahg | it's a waste of mirror space and bandwidth as well | 05:46 |
| wgrant | Ew | 05:46 |
| lifeless | wgrant: ok, so, hot patches | 05:47 |
| wgrant | Oh right. | 05:47 |
| wgrant | lifeless: Indeed | 05:47 |
| lifeless | they have the following properties: | 05:48 |
| lifeless | - they may break running code | 05:48 |
| wgrant | micahg: Amusingly, the copy actually succeeded a few milliseconds before the timeout, but generating the notification timed out. | 05:48 |
| lifeless | - they will apply as regular dbpatches | 05:48 |
| wgrant | I think it might be loading too many objects for the cache to survive. | 05:48 |
| lifeless | - but we can apply them by-hand superfast. | 05:48 |
| wgrant | lifeless: Right. | 05:48 |
| lifeless | so, I'm not sure why we would land them on devel. | 05:49 |
| wgrant | lifeless: Though generally they're just index additions, so cannot break running code (unless postgres misplans and performance suffers) | 05:49 |
| lifeless | I can't find any reference to landing them on devel in the wiki page history | 05:49 |
| lifeless | though I'm not quite at rev 0 | 05:50 |
| micahg | wgrant: interesting | 05:50 |
| wgrant | I quote: | 05:50 |
| wgrant | 10:51 < wgrant> lifeless: What's the process for live index creation these days? | 05:51 |
| wgrant | 10:51 < wgrant> Apply before or after landing? | 05:51 |
| wgrant | 10:51 < wgrant> It should take about 60ms to create :) | 05:51 |
| wgrant | 10:52 < lifeless> wgrant: land on qastaging, add and QA there, then prod. | 05:51 |
| wgrant | 10:53 < wgrant> land on devel, add and QA on qastaging, then prod? | 05:51 |
| wgrant | 10:53 < lifeless> yes | 05:51 |
| lifeless | wgrant: so clearly I'm inconsistent | 05:51 |
| lifeless | hmm | 05:51 |
| lifeless | stub went back to sleep | 05:51 |
| wgrant | Landing on db-devel provides no benefit. | 05:51 |
| wgrant | And it's extremely awkward to deal with, because db-stable can be undeployed for weeks. | 05:52 |
| wgrant | Because of the one-patch-per-downtime. | 05:52 |
| wgrant | So we'd end up with db-stable being deployed out of sequence. | 05:52 |
| wgrant | For no benefit whatsoever. | 05:52 |
| lifeless | well, thats a very absolute statement. | 05:53 |
| wgrant | It's also absolutely correct :) | 05:53 |
| * lifeless wonders if disproving it is worthwhile or a distraction | 05:53 | |
| lifeless | ELOCAL, bbiaw | 05:53 |
| wgrant | k | 05:53 |
| lifeless | wgrant: so what we originally wrote was to have the hot patch qaed by application to qastaging | 06:26 |
| wgrant | lifeless: Right, that makes sense. | 06:30 |
| wgrant | lifeless: In practice we often go live directly to production with indices, because there's no meaningful QA until the code is there. | 06:31 |
| wgrant | (though they usually have been tested with real queries on one of the three stagings first) | 06:32 |
| StevenK | qastaging, staging, and the staging that is spelt with no s, t, a, i, n, one less g, and with two d's, three o's, and an f? | 06:33 |
| wgrant | Those, indeed. | 06:34 |
| wgrant | lifeless: So, I don't see that there's anything achieved by landing on db-devel. | 06:35 |
| wgrant | We shouldn't do something just because the policy that's never been executed in full says we should do it. | 06:36 |
| wgrant | There has to actually be a reason :) | 06:37 |
| wgrant | wallyworld: 204+ return [ | 06:39 |
| wgrant | 205+ enumerated_type_registry[InformationType.name].items[value] | 06:39 |
| wgrant | 206+ for value in self.metadata['information_types']] | 06:39 |
| wgrant | wallyworld: Isn't that just this: | 06:39 |
| wgrant | return [InformationType.items[value] for value in self.metadata['information_types']]? | 06:39 |
| wallyworld | not sure, i can try it | 06:40 |
| wallyworld | i wrote that code ages ago | 06:40 |
| wgrant | IIRC the registry was created for de-JSONing things. | 06:40 |
| wgrant | But you have the actual enum here | 06:40 |
| wgrant | So you don't need the registry. | 06:40 |
| wallyworld | no i don't :-) | 06:40 |
| wallyworld | the job state is saved | 06:40 |
| wallyworld | and then read later from json | 06:40 |
| wgrant | Hmmm? | 06:41 |
| wgrant | You do! | 06:41 |
| wgrant | You get the name of the enum from the enum | 06:41 |
| wgrant | And then use it to look up the enum | 06:41 |
| wgrant | in the enum registry | 06:41 |
| wallyworld | i'll try it | 06:42 |
| wallyworld | i may have copied the code from when i didn't have the enum name | 06:42 |
| wgrant | That sounds most plausible. | 06:42 |
| wgrant | # The enumerated_type_registry is a mapping of all enumerated types to the | 06:42 |
| wgrant | # actual class. | 06:42 |
| wgrant | So it indeed just returns the class | 06:43 |
| wgrant | So enumerated_type_registry[InformationType.name] is just InformationType | 06:43 |
| wallyworld | sounds about right, i have to go and re-read the source | 06:43 |
| wgrant | It's also tempting to ignore Guido and replace the overlong list comprehension with "map(attrgetter('value'), information_types or [])" | 06:45 |
| wallyworld | does he not like map? | 06:46 |
| wgrant | He tried to remove it from Python 3 | 06:46 |
| wallyworld | why? | 06:46 |
| wgrant | http://www.artima.com/weblogs/viewpost.jsp?thread=98196 | 06:47 |
| wgrant | Basically, Guido doesn't like functional-style code :) | 06:49 |
| wallyworld | wgrant: seems like an opinion on style rather than anything of substance at first glance | 06:49 |
| wgrant | Sure | 06:49 |
| wgrant | But he actually tried to remove them from the language :( | 06:49 |
| wallyworld | that's one of the good things about pythin, that it's multiparidigm | 06:50 |
| wgrant | Precisely. | 06:50 |
| wgrant | (I think listcomps might not be so bad if we didn't have a policy against using single-letter variable names) | 06:51 |
| lifeless | wgrant: I agree, I'm trying to reconstruct our reasoning | 06:57 |
| lifeless | wgrant: we failed to write some of it down | 06:57 |
| wgrant | lifeless: Perhaps stub remembers? | 07:02 |
| wgrant | I don't remember much of it from IRC, so it was probably mostly between you two | 07:02 |
| lifeless | ondeed | 07:02 |
| lifeless | he is asleep just now | 07:02 |
| wgrant | :( | 07:03 |
| lifeless | I think there are at least minor downsides to going straight to devel, but also less duplicate work merging stuff up etc | 07:03 |
| lifeless | one of the undone longer term things is making hot patch application be -done- (in make schema etc) using the same sql we use to apply it live. | 07:04 |
| lifeless | to avoid manual handling | 07:04 |
| wgrant | wallyworld, StevenK: Looks like the in-progress branch denorm will make lp:launchpad branch search about 12x faster. | 07:04 |
| wgrant | Yay | 07:04 |
| wallyworld | great | 07:04 |
| wgrant | lifeless: Right, it'd be nice to automate that. | 07:04 |
| wgrant | lifeless: It is infeasible at present due to slony. | 07:04 |
| lifeless | its totally doable | 07:05 |
| lifeless | just not done | 07:05 |
| wgrant | Well. | 07:05 |
| wgrant | Awkward. | 07:05 |
| lifeless | and not worth doing now. | 07:05 |
| wgrant | And probably not worth it given slony's demise | 07:05 |
| wgrant | Right | 07:05 |
| wgrant | The remaining big issue is CONCURRENTLY. Not sure how best to work around that. | 07:05 |
| === almaisan-away is now known as al-maisan | ||
| adeuring | good morning | 07:43 |
| wallyworld | wgrant: fancy a quick +1 on a +16/-471 mp (deletes RemoveGranteeJob). then i can chuck at ec2 https://code.launchpad.net/~wallyworld/launchpad/delete-RemoveGranteeSubscriptionsJob/+merge/110256 | 08:04 |
| wgrant | wallyworld: Looking | 08:05 |
| wallyworld | thanks | 08:05 |
| wallyworld | the additonal lines are just in a generic base class test since the test job has been replaced | 08:06 |
| wgrant | wallyworld: Well that was challenging. | 08:07 |
| wgrant | r=me | 08:07 |
| wgrant | Also just looked over your amendments to the one I reviewed earlier. That looks good too. | 08:07 |
| wgrant | Thanks for applying my suggestions. | 08:07 |
| wallyworld | np, thanks for the reviews | 08:07 |
| wallyworld | wgrant: so, i think if i add the filter for grantee when leaving a team the job should be performant | 08:08 |
| wgrant | The pillar filtering isn't perfect, but in another iteration or two it should be good. | 08:08 |
| wallyworld | wgrant: you think it should be on AP? | 08:08 |
| wgrant | wallyworld: That's probably best. eg. now it will miss series bugs. | 08:09 |
| wgrant | AP is probably more direct. | 08:09 |
| wgrant | And accurate. | 08:09 |
| wgrant | We'll need grantee filtering for normal removals too | 08:09 |
| wgrant | eg. if I revoke someone's access to Ubuntu userdata. | 08:09 |
| wgrant | That's a couple of hundred thousand bugs. | 08:09 |
| wallyworld | yes, makes sense | 08:10 |
| wgrant | We care about the bugs that have the relevant AP and have a subscriber that is a participant in the grantee. | 08:10 |
| wallyworld | the grantee will be removed first though | 08:10 |
| wallyworld | before running the job | 08:10 |
| wallyworld | but that shouldn't matter i don't think | 08:11 |
| wgrant | Right. | 08:11 |
| wgrant | That certainly makes things look a bit nicer. | 08:11 |
| wallyworld | for team membership removal, the filtering will be a bit different | 08:11 |
| wgrant | Yeah | 08:11 |
| wgrant | That has no AP filter. | 08:11 |
| wallyworld | since the team itself still has access | 08:12 |
| wgrant | It's just any private bug with a participating subscriber. | 08:12 |
| wgrant | Right, the team isn't relevant to the job. | 08:12 |
| wgrant | The removed member is. | 08:12 |
| wgrant | Any subscriber participating in the former member is affected. | 08:12 |
| wallyworld | the team could be used to narrow the search | 08:12 |
| wgrant | Hmm. | 08:12 |
| wgrant | Indeed. | 08:12 |
| wgrant | I'm not sure if that's worth it, but it is indeed a good thought. | 08:13 |
| wgrant | In general the set of subscriptions should be very small. | 08:13 |
| wallyworld | so we need to record in the metadata (former) grantee and optionally team | 08:13 |
| wgrant | Well | 08:13 |
| wgrant | The job only really cares about a set of criteria to identify the bugs to reconcile. | 08:14 |
| wgrant | I don't think it needs to know about grantees directly. | 08:14 |
| wgrant | We just need to say "please reconcile subscriptions for participants of ~launchpad in Ubuntu's user data bugs" | 08:14 |
| wgrant | That could mean that ~launchpad had a grant revoked. | 08:14 |
| wgrant | Or it could mean that ~launchpad was removed from a team. | 08:15 |
| wallyworld | sure, but i'm more specifically talking about removing a team member | 08:15 |
| wgrant | Er, in the team removal case there wouldn't be the AP restriction, but yes. | 08:15 |
| wgrant | wallyworld: That's the same. | 08:15 |
| wallyworld | so we only care about bugs the former member has access to via the team | 08:15 |
| wgrant | Right. | 08:15 |
| wallyworld | had | 08:15 |
| wallyworld | anyways, i'll code it up and see what falls out | 08:16 |
| wgrant | In most cases it won't be worth filtering by "had access to via the team" | 08:16 |
| wgrant | It will be more efficient just to consider all subscriptions. | 08:16 |
| wgrant | But it is something to consider for bad cases, and it may not be too bad to do it all the time. | 08:16 |
| wallyworld | ok, i wasn't going to assume that, but i'll defer to you for that | 08:16 |
| wallyworld | i think if the cost of doing it is small, we may as well | 08:16 |
| wgrant | wallyworld: Subscriptions are going to become pretty rare, I think. | 08:17 |
| wgrant | Structural subscriptions handle widespread notification. | 08:17 |
| wgrant | APGs handle widespread access. | 08:17 |
| wgrant | There's no more use case for widespread subscriptions :) | 08:17 |
| wallyworld | but the subquery to get the subscriptions | 08:17 |
| StevenK | I like the idea that subscriptions are going to die. | 08:18 |
| wallyworld | would benfit from the extra filtering | 08:18 |
| wgrant | wallyworld: So | 08:18 |
| wgrant | Maybe. | 08:18 |
| wgrant | But, for example, I'm removing a user with 5 subscriptions from a team with access to Ubuntu's user data bugs. | 08:18 |
| wgrant | It's clearly more efficient there to just look at the subscribed bugs. | 08:18 |
| wgrant | The converse case can also be argued, of course. | 08:19 |
| wgrant | But huge numbers of subscriptions shouldn't be common at all. | 08:19 |
| wgrant | Huge access grants will be. | 08:19 |
| wallyworld | the structure of the job though is to select bugsubscription where bug in (...) | 08:20 |
| wallyworld | and it's the subsquery that needs to be fast | 08:20 |
| StevenK | We still need to transition to APGs/APAs. | 08:20 |
| StevenK | That is going to be ... fun. | 08:20 |
| wallyworld | yep :-) | 08:20 |
| lifeless | also subscriptions will be a separate service in future too. | 08:31 |
| StevenK | So you keep saying | 08:31 |
| lifeless | I do | 08:31 |
| lifeless | how is auditor ? | 08:31 |
| StevenK | I've not touched it this week, due to Monday and I'm still stuck having the fixture being able to run manage.py or some other form of it. | 08:32 |
| wgrant | StevenK: Huh? What transition? | 08:35 |
| wgrant | StevenK: We're already using them internally for all bug access checks. | 08:35 |
| wgrant | It's just the UI that's not rolled out yet. | 08:35 |
| wgrant | And it mostly works. | 08:35 |
| wgrant | These are the final pieces coming together. | 08:35 |
| StevenK | Perhaps I am misrecalling the Marvellous, Foolproof and Excellent Disclosure Plan. | 08:36 |
| StevenK | wgrant: However, branch access is another matter. But, that is progressing, slowly. | 08:38 |
| wgrant | Not particularly slowly. | 08:39 |
| wgrant | We just have to wait for the bug stuff to mature and then refactor it to do branches too. | 08:39 |
| wgrant | Branches are a faaaar simpler problem. | 08:39 |
| wgrant | Once you discard stacking. | 08:39 |
| StevenK | I was about to say "*cough* stacking" :-) | 08:39 |
| lifeless | 'discard' | 08:40 |
| jml | heh heh | 08:40 |
| StevenK | wgrant: I say slowly, because I have a DB patch that drags it forward and I can't land it for a week. | 08:41 |
| StevenK | And when it deploys is another matter entirely. | 08:42 |
| wgrant | StevenK: You can probably land the DB patch on Monday night. | 08:42 |
| wgrant | It can be deployed on Tuesday. | 08:42 |
| StevenK | wgrant: That plan requires that the model code is dropped in a deployment on Monday. | 08:44 |
| StevenK | But okay. | 08:44 |
| wgrant | StevenK: That's the plan. | 08:44 |
| wgrant | Although if we push it we can drop the model code tomorrow. | 08:44 |
| wgrant | Let's push it :) | 08:44 |
| StevenK | I haven't written the branch yet. | 08:45 |
| wgrant | It's about -10 | 08:45 |
| wgrant | We can deploy today's branch in about 3 hours | 08:45 |
| wgrant | Land the model removal | 08:45 |
| wgrant | Deploy model removal tomorrow | 08:45 |
| wgrant | Land DB patch | 08:45 |
| wgrant | Deploy DB patch Monday night :) | 08:45 |
| StevenK | There are at least seven branches that need QA before we can deploy in three hours. | 08:47 |
| wgrant | The ones with non-trivial QA are ∅ | 08:48 |
| wgrant | Well, r15407 and r15410 require a small amount of thought. | 08:49 |
| StevenK | wgrant: So, model droppage now, or tomorrow morning? | 08:49 |
| wgrant | StevenK: I'd prepare the branch now, since it's trivial. | 08:50 |
| wgrant | It shouldn't be landed until today's is deployed. | 08:50 |
| wgrant | I think you can just delete any statement mentioning _transitively_private or _explicitly_private. | 08:51 |
| StevenK | Of which there are two ... | 08:51 |
| wgrant | 3 lines mention explicitly, 8 transitively | 08:52 |
| wgrant | But close enough | 08:52 |
| wgrant | So it's going to be like -13 | 08:52 |
| wgrant | Not -10 as I said :( | 08:52 |
| StevenK | wgrant: I'm at -18/+0 already | 09:00 |
| jml | https://bugs.launchpad.net/launchpad/+bug/1013056 | 09:00 |
| _mup_ | Bug #1013056: Creating a PPA requires one to be a team admin <ppa> <Launchpad itself:New> < https://launchpad.net/bugs/1013056 > | 09:00 |
| wgrant | jml: Argh | 09:01 |
| wgrant | Make it go away | 09:01 |
| jml | I'm trying. | 09:01 |
| wgrant | That one comes up occasionally | 09:01 |
| wgrant | I don't have a good answer. | 09:01 |
| czajkowski | I was thinking something similar | 09:01 |
| jml | I filed it. | 09:01 |
| wgrant | I know you filed it. | 09:01 |
| jml | Here are some answers I can think of. I won't claim they are good. | 09:01 |
| wgrant | The issue comes up in discussion occasionally. | 09:01 |
| jml | make it launchpad.Append | 09:01 |
| jml | make a new object, say, ArchiveCollection, and hook permissions on to that. | 09:02 |
| bigjools | append on what? | 09:02 |
| wgrant | So, allowing it technically is easy. | 09:02 |
| wgrant | Socially it's less obvious whether it's sensible. | 09:02 |
| jml | bigjools: IPerson | 09:02 |
| bigjools | ah ok | 09:02 |
| wgrant | jml: I'm a member of ~ubuntu-bugcontrol | 09:02 |
| wgrant | Should I be able to create a PPA? | 09:02 |
| wgrant | No. | 09:02 |
| wgrant | ubuntu-bugcontrol isn't a PPA team. | 09:02 |
| jml | wgrant: right. similar for mailing list teams. | 09:02 |
| StevenK | wgrant: http://pastebin.ubuntu.com/1040482/ | 09:03 |
| jml | and the last thing Launchpad needs is another knob. | 09:03 |
| StevenK | jml: No, we have enough of those working on it already. :-P | 09:03 |
| bigjools | badumtish | 09:03 |
| wgrant | jml: Precisely. | 09:03 |
| wgrant | jml: So I would just make your robot a team admin. | 09:03 |
| wgrant | And ignore the question. | 09:03 |
| jml | wgrant: we have a contractor too. | 09:03 |
| bigjools | can we apply a Knob-count approach like LOC? :) | 09:03 |
| wgrant | jml: Can't SCA have an API to do it or something? | 09:04 |
| wgrant | There's no sane way to do it in LP without adding a knob. | 09:05 |
| jml | wgrant: we can probably get by, but I'd rather leave the bug open for the moment. I don't like bots with team admin privs either. | 09:05 |
| wgrant | Sure. | 09:05 |
| wgrant | We need something more flexible. | 09:05 |
| wgrant | But we have no way to do that without making everything suck right now :/ | 09:05 |
| jml | wgrant: by 'have an API', you mean write a front-end and secure that? | 09:05 |
| wgrant | jml: Maybe. | 09:06 |
| wgrant | jml: I mean, SCA already accepts API requests from webapps to manage subscriptions. | 09:06 |
| wgrant | And those webapps have admin UIs | 09:06 |
| wgrant | That could be used to ask SCA to perform admin operations like setting up a PPA for a new app. | 09:06 |
| jml | wgrant: yeah, we could possibly do that. We weren't planning on having SCA create PPAs, but that might work. | 09:07 |
| wgrant | StevenK: Ah, comments, I see. That's cheating. | 09:07 |
| StevenK | Hahaha | 09:07 |
| StevenK | wgrant: Do you think it's reasonable? | 09:07 |
| wgrant | StevenK: It does what we want, it works, it doesn't fail tests, it doesn't add ugly code. | 09:09 |
| wgrant | I don't see how it could not be reasonable. | 09:09 |
| wgrant | StevenK: Deployment report is green and the two remaining revs before yours are 30s QA. | 09:12 |
| StevenK | wgrant: I think this branch model may also have to kill the transitively_private triggers tests. I'm not certain. | 09:14 |
| wgrant | Oh, indeed. | 09:14 |
| wgrant | bzr rm lib/lp/code/model/tests/test_branch_privacy_triggers.py | 09:15 |
| cjwatson | wgrant: map/listcomp> the tradeoff has changed a bit in Python 3 though - map returns an iterator, so if you need a concrete list then the map approach is an extra six characters versus Python 2 | 09:15 |
| wgrant | cjwatson: True. | 09:15 |
| wgrant | StevenK: Actually, it shouldn't matter. The trigger tests don't use the model. | 09:15 |
| wgrant | StevenK: It's all string-based SQL | 09:15 |
| wgrant | StevenK: But might as well delete them anyway. | 09:16 |
| cjwatson | 15412 is a bit more than 30s QA since it's gone wrong before, but hopefully not overly much. | 09:17 |
| wgrant | Meh, it's only worth two API calls. | 09:18 |
| cjwatson | Actually, I could do that on dogfood now couldn't I | 09:19 |
| wgrant | You could indeed. | 09:20 |
| wgrant | It won't be on qastaging for a couple more hours. | 09:20 |
| StevenK | wgrant: https://code.launchpad.net/~stevenk/launchpad/destroy-branch-privacy/+merge/110274 | 09:24 |
| wgrant | StevenK: r=me, ec2test time. | 09:26 |
| StevenK | wgrant: Tossed at ec2 test. | 09:27 |
| wgrant | StevenK: Great. | 09:29 |
| StevenK | It will be great if it doesn't fail any tests. Not before. | 09:31 |
| wgrant | Meh | 09:31 |
| bigjools | jml: I saw a car today with a sticker in the back window that said "Beached as!" | 09:32 |
| bigjools | and I thought of you | 09:32 |
| jml | bigjools: :) | 09:33 |
| al-maisan | hmm .. can someone please take a look at this build : https://launchpad.net/~openquake/+archive/testing/+build/3575134 | 09:58 |
| al-maisan | the upload of the resulting binaries seems stuck | 09:58 |
| wgrant | al-maisan: Cronjobs are disabled for a DB upgrade in a few seconds. | 10:00 |
| wgrant | Should be processed in a few minutes. | 10:00 |
| al-maisan | ah, I see, thanks! | 10:00 |
| wgrant | al-maisan: The webapp downtime is down to 70s, but we're still disabling cronjobs about 15min before for safety. | 10:01 |
| al-maisan | no problem at all -- at least I know what's going on now :) | 10:02 |
| wgrant | al-maisan: That uploaded a few minutes ago. | 10:11 |
| al-maisan | thank you William! | 10:11 |
| jml | ooh, a db upgrade | 10:13 |
| jml | will this include my patch? | 10:13 |
| wgrant | jml: This was stub's index work. Yours is nearly 24 hours away. | 10:13 |
| jml | wgrant: ta | 10:14 |
| === matsubara is now known as matsubara-lunch | ||
| === al-maisan is now known as almaisan-away | ||
| === mrevell_ is now known as mrevell | ||
| wgrant | cjwatson: Did you get around to doing that QA on DF? | 11:19 |
| rick_h | StevenK: you get +10 internet points for your email signature I noticed today | 11:22 |
| cjwatson | wgrant: Yes; I've been waiting for qastaging to update. | 11:25 |
| wgrant | It'll be there in about 30s. | 11:25 |
| cjwatson | (So I can mark it qa-ok.) | 11:25 |
| cjwatson | Cool. | 11:25 |
| wgrant | Ah right | 11:25 |
| wgrant | That'll be another 5 minutes. | 11:25 |
| wgrant | Thanks. | 11:25 |
| wgrant | There we go, right on time. | 11:26 |
| cjwatson | wgrant: Bug 648611: any particular reason you feel it necessary to include upload status granularity in that? | 11:29 |
| wgrant | cjwatson: I don't remember who that was discussed with. ScottK and others. But if it's no longer an issue for you, then there's no need for it. | 11:30 |
| jml | wgrant: do you know if the codehosting puller is still in use? | 11:33 |
| cjwatson | Maybe I should talk with ScottK then. | 11:34 |
| wgrant | jml: Mirrors and imports still use it. Mirrors can't be created any more, but there are still some old ones in use. | 11:34 |
| cjwatson | It'd be easier to just make it per-pocket, since that's almost exactly analogous to per-pocket upload. | 11:34 |
| jml | wgrant: ah ok. I'm surprised imports use it. | 11:34 |
| jml | oh wait | 11:34 |
| wgrant | jml: Same as ever. | 11:35 |
| jml | to pull it from internal location where branch is | 11:35 |
| wgrant | importds push their branches up to escudero | 11:35 |
| wgrant | LP pulls from escudero | 11:35 |
| wgrant | Because who cares about sanity :) | 11:35 |
| jml | wgrant: I thought I recalled some discussion about using the codeimport system to do pulling | 11:35 |
| jml | ddaa had a reason for that, I'm sure. | 11:36 |
| jml | huh | 11:36 |
| jml | I wonder. Could / should the ScriptActivity table have a place in the web ui, exposed to LP developers & admins. | 11:36 |
| StevenK | rick_h: Haha | 11:37 |
| wgrant | jml: s/table/service/ | 11:37 |
| jml | wgrant: even better. | 11:38 |
| StevenK | wgrant: Are you going to be awesome and do my QA, since dinner for Sarah and I is about 3 minutes away from serving? | 11:38 |
| wgrant | StevenK: Mostly done already | 11:38 |
| jml | hmm. hmm. hmm. | 11:38 |
| StevenK | wgrant: ec2 has another ~ 110 minutes, but it should be good to lp-land when it finishes. | 11:39 |
| wgrant | jml: Hm hm? | 11:39 |
| jml | wgrant: I was thinking about starting work to pull codehosting out of LP | 11:39 |
| jml | wgrant: and then about how I wonder how much work it would be to make & deploy a scriptactivity service as we just described | 11:39 |
| cjwatson | Oh, hey, maybe I lied when I said to technical-board@ that my permissions branch would probably land tomorrow or failing that Monday. | 11:40 |
| jml | wgrant: and then about how I don't know whether anything *has* been pulled out of LP into a separate service successfully | 11:40 |
| wgrant | cjwatson: Pocket permissions? With a bit of luck it'll be deployed 40 minutes after gnuoy returns from lunch. | 11:40 |
| wgrant | jml: It depends on how much of codehosting you want to pull out of LP. | 11:41 |
| cjwatson | Yeah, I missed your chatter about pushing it. | 11:41 |
| wgrant | How much of codehosting do you want to pull out of LP? | 11:41 |
| jml | wgrant: and how if I started I'd be afraid that the work would spiral out of control with lifeless, yourself and others telling me that I'm doing it wrong or adding new requirements or elucidating requirements that I'm not fully conscious of yet. | 11:41 |
| jml | wgrant: I think the ssh server / vfs bit makes sense. | 11:41 |
| jml | wgrant: maybe the apache rewrite support too. I'm not sure. | 11:42 |
| wgrant | Nothing like this has been extracted before. | 11:42 |
| jml | wgrant: an obvious pre-req would be extracting lp.services.ssh into a library. | 11:42 |
| wgrant | I was going to do poppy to start. But I ran into trouble with naming the libraries. | 11:42 |
| wgrant | Right. | 11:42 |
| wgrant | That's pretty easy to do. | 11:43 |
| jml | and I don't know how I'd answer questions like what to use for config. | 11:43 |
| wgrant | And it's probably most of the integration points. | 11:43 |
| jml | wgrant: poppy would also be a good place to start. | 11:44 |
| wgrant | I'd probably just use a separate minimal lazr.config-based thing. But configglue or something might be easier and better. | 11:44 |
| wgrant | jml: I'd suggest starting with poppy, as it uses the sshserver and is much simpler in every other respect. | 11:44 |
| jml | wgrant: it seems to me that doing one small thing, and (crucially) writing down the steps taken would be a giant leap for Launchpad. | 11:44 |
| wgrant | Most definitely. | 11:44 |
| wgrant | poppy is probably the smallest, easiest piece to rip out like that. | 11:45 |
| wgrant | It's extremely isolated. | 11:45 |
| jml | Yeah. The list for me goes: poppy, codehosting ssh, maybe codeimport, builddmaster. | 11:45 |
| jml | Although you mentioned scriptactivity, which probably goes somewhere toward the right. | 11:46 |
| wgrant | scriptactivity is sort of the opposite. | 11:47 |
| wgrant | It's an internal service used by everything, but it's very isolated and an excellent example of something that should be a microservice. | 11:48 |
| wgrant | scriptactivity is probably a prereq for getting rid of other things. | 11:49 |
| wgrant | Since they'll want a way to record activity. | 11:49 |
| jam | anyone have much experience with lxc? I'm running low on space on '/' so I'm trying to put the rootfs on an alternate drive. But once I do 'lxc-start' just returns without starting anything, or giving me anything informative. | 11:51 |
| jam | I've tried playing with the config file, to point the root to another location | 11:51 |
| jam | maybe if you know of an error log or something like that? | 11:52 |
| wgrant | jam: Tried 'lxc-start -n foo -o /tmp/lxclog -l DEBUG'? | 11:53 |
| jml | wgrant: yeah. it's realizing that it's a pre-req that got me 'hmming' in the first place | 11:53 |
| wgrant | Yeah | 11:54 |
| jml | Specs fall apart, the scope it cannot hold; more work items are loosed upon the world | 11:54 |
| jml | wgrant: anyway, I'll keep it in mind as a possible skunkworks project | 11:55 |
| wgrant | Sounds good. | 11:58 |
| wgrant | So, poppy and scriptactivity, in that order, would be my recommendation for anyone wanting to do this sort of thing. poppy because it's simple, and scriptactivity because it's simple and a core pre-req from the other end. | 11:59 |
| jml | wgrant: doesn't poppy need to use scriptactivity | 11:59 |
| * jml just remembered something. | 11:59 | |
| wgrant | jml: It's a daemon. | 11:59 |
| wgrant | Not a cronjob. | 11:59 |
| jml | ah, ok. | 11:59 |
| jam | wgrant: it appears /sbin/init was just dying, but that appears to be because I had that device mounted with "nosuid,nodev" | 12:01 |
| jam | it seems to work now | 12:01 |
| wgrant | jam: That would be unhelpful, indeed. | 12:01 |
| wgrant | It was GNOME-mounted removable media? | 12:01 |
| jam | wgrant: I added it to fstab, using the params done by GNOME disk-utility | 12:02 |
| cjwatson | udisks mounts everything with nosuid,nodev. | 12:02 |
| jam | I couldn't find a Gnome utility that would let me say "always mount this disk" | 12:02 |
| wgrant | Ah yes, udisks, I had forgotten what was underneath today. | 12:03 |
| cjwatson | udisks2 in quantal, because it would be a shame to leave anything the same. | 12:05 |
| jml | wgrant: you don't appear to be subscribed to DisklessArchives. I made an edit, and james_w added a comment the other day for which we'd welcome your feedback. (Can wait until tomorrow though) | 12:06 |
| wgrant | jml: I couldn't find a subscribe button, and /UserPreferences is like all the way over there. | 12:06 |
| jml | wgrant: URL hack! ?action=subscribe | 12:06 |
| wgrant | Ah, didn't think that would still work. | 12:07 |
| wgrant | Surely new moin has fixed mutating GETd | 12:07 |
| wgrant | s | 12:07 |
| wgrant | Evidently not. | 12:07 |
| wgrant | Thanks. | 12:07 |
| jml | wgrant: np. | 12:08 |
| wgrant | jml: The API service will live in the LP tree. | 12:08 |
| wgrant | The squid bits will not. | 12:08 |
| wgrant | Ideally the API service would be part of the main Zope stack, but the main Zope stack is so terrible that it's not feasible at present, so we have to hack. | 12:09 |
| jml | wgrant: that makes sense. it's a shame from a test cycle pov. | 12:10 |
| wgrant | Giving the testing hostname to real clients is an interesting idea. I'm not sure if it's a good one. | 12:10 |
| wgrant | jml: Certainly. | 12:11 |
| lifeless | wgrant: we an use the testing hostname as the new, browser-safe permanent hostname | 12:11 |
| lifeless | wgrant: and initiate a very slow migration. | 12:11 |
| wgrant | True. | 12:11 |
| jml | wgrant: however, once we have one non-zope api server in LP to facilitate fast requests, why not move the existing api services to that same technology | 12:11 |
| lifeless | see #ca-internal for a chat between me and james_w about this | 12:11 |
| wgrant | jml: That's the plan. | 12:11 |
| lifeless | wgrant: btw, LP's stack *can* answer in 3ms. | 12:11 |
| wgrant | jml: Whether the plan will happen this decade is unclear :) | 12:11 |
| wgrant | lifeless: hahahah | 12:12 |
| jml | I hope not using zope stack means that at least the unit tests will be fast | 12:12 |
| wgrant | +opstats maybe | 12:12 |
| lifeless | wgrant: definitely, see the haproxy stats page. | 12:12 |
| lifeless | wgrant: I noting that the publication stack through to render and return is likely fast enough for our needs; there is definitely potential issues below that. | 12:13 |
| lifeless | wgrant: I'm inclined to suggest trying in the main stack in the first instance; it means we know fairly likely places for the rot to be located. | 12:13 |
| wgrant | Right, for a no-op publication to a no-op view that has hardcoded hacks to avoid most of the stack, it can be fast. | 12:13 |
| jml | alas for my TDD cycle time! | 12:14 |
| lifeless | jml: the TDD cycle time for the horizontally scaling nodes should be fine. | 12:14 |
| lifeless | jml: it will need a test harness, but that by definition has to be fast to start and use. | 12:15 |
| wgrant | That's like 3% of the effort. | 12:15 |
| jml | btw, at some point before we actually start work it'd be good if you two, james_w and I could have a call to walk through the implementation plan. I realize that TZ wise it's a huge pita. | 12:16 |
| wgrant | lifeless: Are you sure you didn't hallucinate the conversation with james_w? | 12:16 |
| jml | also, it looks more like 6-8 weeks than 4-6. | 12:16 |
| wgrant | I don't see it. | 12:16 |
| wgrant | jml: It mostly depends on how far you want to rewrite the backend publication stack. | 12:17 |
| wgrant | lifeless wants you to rewrite them a lot. | 12:17 |
| wgrant | I don't. | 12:17 |
| wgrant | lifeless: Which day was it? | 12:18 |
| lifeless | wgrant: today | 12:18 |
| lifeless | may have been here. Lets see | 12:18 |
| lifeless | wgrant: u1-internal | 12:20 |
| wgrant | Oh, sneaky. | 12:20 |
| wgrant | I don't think I'm in there. | 12:20 |
| lifeless | very very so | 12:20 |
| * wgrant grabs logs. | 12:20 | |
| === almaisan-away is now known as al-maisan | ||
| === _mup__ is now known as _mup_ | ||
| stub | jml: Yes, I think scriptactivity should definitely be exposed. I always imagined a page of green/red/yellow blobs for each component we can track. | 12:24 |
| stub | jml: I think the trick is to start simple, as bikeshedding and feature creep turn it into a big problem very quickly | 12:25 |
| jml | stub: agreed | 12:25 |
| jml | stub: the main thing I'm interested in is knowing which cronjobs are still being run and with what options so I can delete more code. | 12:25 |
| jml | although I don't think SA tracks options | 12:25 |
| wgrant | jml: bzr branch lp:lp-production-crontabs | 12:26 |
| jml | mirable dictu! | 12:26 |
| lifeless | deleting scriptactivity itself would be a start | 12:28 |
| === matsubara-lunch is now known as matsubara | ||
| wgrant | cjwatson: Perhaps we should revert your revision quickly, just to prevent the rest of UE from getting the idea that LP deadlines don't always slip. | 12:31 |
| cjwatson | wgrant: haha | 12:38 |
| wgrant | Also, we're not really in a hurry for something else, I just wanted to stop StevenK complaining that things are too slow. | 12:39 |
| StevenK | wgrant: You know, scriptactivity could probably be replaced by auditor ... | 12:43 |
| wgrant | Potentially. | 12:45 |
| stub | and the bikeshedding and feature creep starts... | 12:47 |
| lifeless | jml: pretotyping | 12:47 |
| StevenK | stub: For auditor? I don't think the feature could creep much :-) | 12:48 |
| wgrant | StevenK: That just means it's already crept. | 12:48 |
| StevenK | wgrant: But it hasn't? | 12:48 |
| StevenK | Log events via POST, grab them via GET. Done. | 12:49 |
| StevenK | It might need some squinting in terms of actor/object acted on, but shrug. | 12:49 |
| StevenK | wgrant: It was good natured complaining about things going slowly. :-) | 12:50 |
| wgrant | Sure. | 12:50 |
| wgrant | But we might as well make things faster where we can. | 12:50 |
| stub | StevenK: It started as exposing some information in the DB, now you are posting information into it :) | 12:51 |
| StevenK | stub: No, it was always the plan that we had to post information into it, so nyah. | 12:52 |
| wgrant | jml: How soon are you likely to want that call? | 12:58 |
| jml | wgrant: before we start implementing, after you guys think it's ready for us to start implementing. | 13:00 |
| jml | wgrant: modulo some scheduling stuff that I need to talk to james_w and mvo about. | 13:00 |
| wgrant | Right. | 13:00 |
| ivory | jelmer: could you review this please? https://code.launchpad.net/~ivo-kracht/launchpad/bug-999662/+merge/110322 | 13:08 |
| jelmer | ivory: sure, I'll add it to my queue | 13:11 |
| ivory | jelmer: thanks | 13:11 |
| flacoste | gary_poster: i really liked the format of your latest parallel tests update | 13:11 |
| flacoste | gary_poster: it read very well! | 13:11 |
| gary_poster | flacoste, thanks! I'll go review it to see what I did differently. ;-) | 13:12 |
| mgz | ivory: skim-by, is that change wrap the <a> in xx-distirbution-changes.txt valid? I'd think id'd break a doctest | 13:12 |
| wgrant | ivory: Did you consider using fmt:approximatedate? It handles timestamps within the last 24 hours a little more useful, by saying eg. "2 hours ago" | 13:12 |
| flacoste | gary_poster: i think the summary rocked, or maybe is that the news are particularly good this week ;-) | 13:13 |
| wgrant | For more than a day it just uses the date. | 13:13 |
| StevenK | "a moment ago" \o/ | 13:13 |
| gary_poster | flacoste, lol, cool, I'll take either one :-) | 13:13 |
| wgrant | mgz: Doctests default to normalising whitespace. | 13:14 |
| wgrant | mgz: So you can normally wrap however you want. | 13:14 |
| ivory | wgrant: i did but somehow it didn't work, maybe i did something wrong but then abel proposed to do it like that ... | 13:14 |
| cjwatson | Not that you'd know it by looking at lots of our existing doctests. | 13:14 |
| wgrant | cjwatson: Shhh | 13:14 |
| mgz | wgrant: they don't generally, but does launchpad set that flag? | 13:15 |
| wgrant | mgz: I meant our doctests, yeah. | 13:15 |
| mgz | thanks, good to know. | 13:15 |
| wgrant | default_optionflags = (doctest.REPORT_NDIFF | doctest.NORMALIZE_WHITESPACE | doctest.ELLIPSIS) | 13:15 |
| StevenK | Some of our unit tests also make use of doctest.NORMALIZE_WHITESPACE, which I find hideous. | 13:15 |
| cjwatson | doctest.ELLIPSIS is handy when converting doc to unit though. | 13:17 |
| ivory | mgz: i don't really understand what you mean.i didn't change xx-distribution-changes.txt | 13:17 |
| mgz | ivory: *-packages.txt, but wgrant settled that question | 13:19 |
| === jcsackett changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | Welcome our new intern: ivory | On call reviewer: jcsackett | Firefighting: - | Critical bugs: 3.47*10^2 | ||
| wgrant | cjwatson: It is done. | 13:34 |
| cjwatson | Neat. | 13:42 |
| StevenK | wgrant: ec2 is done. | 13:43 |
| === al-maisan is now known as almaisan-away | ||
| wgrant | StevenK: Might as well land it. The deploy isn't completely done yet, but the appservers are and nothing's going to cause a revert. | 13:44 |
| StevenK | wgrant: r15417 | 13:47 |
| wgrant | StevenK: Excellent, thanks. | 13:47 |
| wgrant | Hopefully by the end of the year we'll be doing this in two hours, not two days. | 13:47 |
| ivory | jelmer: thank you :) | 13:57 |
| danilos | flacoste, mrevell, jamestunnicliffe, matsubara: hi, shall we try hangout again: https://plus.google.com/hangouts/_/40c23fb864bd02615f8a2bc4d8919084f9053f90?authuser=0&hl=sr | 14:59 |
| danilos | mrevell: hi, shall we try hangout again: https://plus.google.com/hangouts/_/40c23fb864bd02615f8a2bc4d8919084f9053f90?authuser=0&hl=sr | 15:02 |
| mrevell | Th | 15:02 |
| mrevell | danilos, Cheers! | 15:02 |
| mrevell | flacoste, Hangout: ^^^ | 15:03 |
| mrevell | danilos, Google Plus is now talking to me in Serbian. | 15:04 |
| danilos | mrevell, don't you feel happy about it? just get hl=sr off the URL, sorry :) | 15:05 |
| matsubara | https://dev.launchpad.net/Projects/WorkItems | 15:05 |
| mrevell | czajkowski, In case you're interested, hangout ^^^ | 15:07 |
| jamestunnicliffe | https://launchpad.net/~linaro-infrastructure/+upcomingwork | 15:12 |
| danilos | matsubara, and https://launchpad.net/people/+me/+upcomingwork | 15:13 |
| danilos | mrevell, https://blueprints.launchpad.net/linaro-infrastructure-misc/+spec/engineering-view-fixes | 15:17 |
| danilos | mrevell, https://bugs.launchpad.net/launchpad/+bug/1004416 | 15:18 |
| _mup_ | Bug #1004416: Work Items not allowing users to edit them properly <work-item-tracker> <Launchpad itself:Triaged by linaro-infrastructure> < https://launchpad.net/bugs/1004416 > | 15:18 |
| === salgado is now known as salgado-lunch | ||
| sinzui | jcsackett, can you review https://code.launchpad.net/~sinzui/launchpad/commercial-jobsource-zcml/+merge/110365 today? | 16:29 |
| jcsackett | sinzui: sure. | 16:36 |
| jcsackett | sinzui: r=me, but i'm confused by moving the lp.services imports? is that a merge artifact, or was there a problem with standard sort order? | 16:44 |
| sinzui | jcsackett, someone sorted imports and I merged | 16:45 |
| sinzui | I can resort | 16:45 |
| jcsackett | sinzui: cool, thanks. :-) | 16:48 |
| jml | dist/zope.testing-3.9.4-p13.tar.gz. p13? my sympathies! | 16:58 |
| === matsubara is now known as matsubara-afk | ||
| jml | httplib2.SSLHandshakeError: [Errno 1] _ssl.c:504: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed | 17:03 |
| jml | ^^ got that error while trying to do API call against a dev instance | 17:03 |
| jml | how can I work around? | 17:03 |
| jml | (alternatively, how can I test creating a PPA on Launchpad as a user who does *not* have a commercial subscription?) | 17:04 |
| cjwatson | Can anyone advise on the problem I'm having in https://code.launchpad.net/~cjwatson/launchpad/export-change-override/+merge/109549 ? | 17:11 |
| jml | cjwatson: looking. | 17:13 |
| jml | cjwatson: perplexing. copy_field doesn't seem to have any positional args beyond the first, so I'm in favour of the "Not being called" idea. Maybe it's something to do with the circular import hackery? | 17:18 |
| cjwatson | I thought I used a keyword arg. | 17:20 |
| jml | cjwatson: you did. yes. I checked for an error that in retrospect couldn't be possible. | 17:22 |
| cjwatson | I'm not really convinced this proposed change actually makes the code any easier to maintain, but I'm not the reviewer ... | 17:22 |
| jml | why do lazr.restful, lazr.restfulclient and launchpadlib only include the first 6 points of the GPLv3 license? | 17:23 |
| cjwatson | I suppose I could start print-debugging through copy_field. | 17:23 |
| jml | http://www.gnu.org/licenses/gpl.txt vs http://bazaar.launchpad.net/~lazr-developers/launchpadlib/trunk/view/head:/COPYING.txt | 17:23 |
| jml | same date & version, I think. | 17:23 |
| jml | oh. lgpl. | 17:24 |
| jml | never mind. | 17:24 |
| === salgado-lunch is now known as salgado | ||
| jml | sinzui: fwiw, my build was not from a public source. | 18:46 |
| jml | mischan | 18:47 |
| sinzui | jml: the same issue is happening. builds are not private, so they cannot issue a 403 or show a privacy banner. the privacy is very smart as it looks at the object, then the view to ensure the banner is shown | 18:49 |
| jml | sinzui: then the bug has the wrong title. | 18:50 |
| sinzui | fix it | 18:50 |
| jml | sinzui: ok. | 18:50 |
| ev | lifeless: if I may briefly go back to the conversation of not being able to use launchpadlib directly from a wsgi app because it's not thread safe. | 19:30 |
| ev | What are your thoughts on talking straight HTTP to the webservice, rather than going through lplib? | 19:30 |
| ev | this being an alternative to adding a rabbit/celery layer | 19:30 |
| lifeless | ev: love it. | 20:13 |
| ev | so that's a yes, avoid lplib for this then? :) | 20:14 |
| ev | lifeless: and good morning | 20:14 |
| lifeless | ev: I have no soft spot for it :P | 20:15 |
| ev | heh | 20:15 |
| ev | awesome | 20:15 |
| ev | that makes things much simpler | 20:15 |
| === salgado is now known as salgado-afk | ||
| === jcsackett changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | Welcome our new intern: ivory | On call reviewer: - | Firefighting: - | Critical bugs: 3.47*10^2 | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!