[00:00] wgrant: yea, if we move it to it's own JS file we can just make sure it gets built into launchpad.js and then for the feature flag users make it a seperate request for now [00:01] wallyworld_: does that make sense? To create a .js file in lib/lp/app/javascript/plain.js or something? [00:01] wgrant: I have the tests passing, so I can redo the work, and move back to list of tuples or commit and land the use of structure [00:01] and the builder should pick it up for launchpad.js automatically still [00:01] since it searches in there right? [00:01] It runs find over the tree [00:01] and then we'll manually add the url as a new script tag for feature flag users? [00:01] StevenK: "redo the work" is about ten lines of code, but I guess it's OK [00:01] until I can get a chance to run through it and YUI-ize it? [00:02] rick_h: i was just going to wrap in a CDATA tag for now - we already do that all over the place [00:02] essentially a 2 line change to the mp [00:02] wallyworld_: ok then. I've never done that so that was the less comfy way for me [00:02] wallyworld_: but awesome, works for me [00:02] Make sure that the CDATA tags are commented. [00:02] Or IE's JS parser will choke [00:02] of course [00:02] i cut n pasted :-) [00:03] The web needs to die. [00:03] from elsewhere [00:03] no, IE needs to die [00:03] Holy shit [00:03] IE9 supports XHTML [00:03] yea, IE9 is the first real browser in a long time [00:04] IE10 actually might make me not hate it..but until then [00:04] Only 12 years late :) [00:04] IE9 is still missing html5 history/geo location/etc that everyone else has now [00:05] wallyworld_: ok, so looking at: http://yuilibrary.com/yui/docs/api/files/yui_js_yui-log.js.html#l36 [00:05] wgrant: Compilation failed', "zope.tal.taldefs.TALError: invalid syntax (, line 1) in expression u'python:${tag/1}', at line 148, column 15" [00:05] the logging is looking for a setting in Y.config.debug = false [00:05] StevenK: python: tag[1] [00:05] Sigh, TALES. [00:06] you can hardly say python: and then give it TALES instead. [00:06] rick_h: that's for the src filters - include and excluded modules [00:06] wallyworld_: and looking at how the YUI instance is setup, if you were to add config: { debug: false } to the list in YUI.GlobalConfig that would work [00:06] wgrant: Silence. :-P [00:06] wallyworld_: it wraps the whole thing [00:06] if the debug is false it bypasses all logging [00:07] rick_h: but we still want errors logged in prod [00:07] wallyworld_: the whole method does nothing but return the Y instance at the end [00:07] wallyworld_: ok, then we'll have to set the config.logExclude filters for warning? [00:08] nvm, those are for the source, we need on log level, looking me [00:08] rick_h: my understanding is that the include/exclude filetrs are for modules [00:08] looking more :/ can't type [00:08] afaict, we need logLevel but that's not a global option sadly [00:09] wallyworld_: the problem is that's on the console module [00:09] we want to touch the raw log included in yui.js [00:09] they're different, the loglevel would do us no good here [00:09] yep :-( [00:10] that's the conclusion i camr to as well [00:10] wallyworld_: I still say we turn off debug. This is the YUI log module. Any JS errors are exceptions that go around this [00:10] wgrant: I had to set tal:content to python: tag[0] too, but I think I have it working. [00:10] wallyworld_: the only errors this would eat are places where we willingly do Y.log.error() [00:10] StevenK: Of course [00:10] rick_h: sounds like a reasonable plan i think [00:11] or sorry, Y.log(msg, "error") [00:11] yeah, knew what you meant :-) [00:11] wgrant: So I have your blessing to toss it at ec2 and find something else to do? [00:12] StevenK: If it doesn't use structure, I have no objection. [00:12] Because the worst you can do is break the links :) [00:13] wallyworld_: so I'm not sure which of these you need: http://paste.mitechie.com/show/505/ [00:13] rick_h: i knew 30 minutes ago when i read the docs :-) [00:13] i'll sort it [00:14] short term memory is broken, brain too full, it hurts to think [00:14] wallyworld_: I *think* it's the first but not 100% sure [00:14] but anyway, if it fails jsut a heads up you might need the other [00:15] np, will find out in about 3 minutes [00:18] rick_h: it's just "debug: true|false" [00:18] wallyworld_: yea, the check in the code is if (!c.debug) [00:18] sorry, if (c.debug) [00:25] * StevenK has been seeing some wierd behaviour today [00:26] Refreshing MP pages "Shows transferring data" for a good long while until I get bored and stop it [00:28] StevenK: bazaar.lp.net was sloooow yesterday [00:28] timed out a lot [00:28] rick_h: now all i need is deryck to come back online and +1 the fucker :-) [00:29] rick_h: WRT to your convoy MP, I was expecting we'd have /+combo/r14335/ and then something like /+combo/r14436/ ? [00:30] * StevenK stabs the messaging indicator more [00:30] StevenK: the use-convoy mp is/will be linked against 2 bugs. if i land with --incr, both bugs will remain in progress, right? [00:30] I believe so [00:31] that makes me sad, since one will be fixed [00:31] i guess we can close manually [00:32] Right, we don't really deal with that case [00:37] i can do recipe builds from private branches, right? [00:38] You can not. [00:38] ah, foo, i thought i'd seen it [00:38] maybe i was thinking of private ppas [00:38] StevenK: do you remember what prevents them? [00:38] jelmer: Builders don't have SSH keys [00:39] was this connected to mwh's thing of allowing ssh with a limited-time token? [00:39] Precisely. [00:39] wgrant: oh, right [00:40] jelmer: sorry to bother you - is there anything i can do to get lp-land etc working in precise? [00:42] wallyworld_: can you tell me what package version of bzr-pqm you have installed? [00:43] wallyworld_: Do you really have to conflate those two changes into a single branch? [00:43] jelmer: 1.40-bzr80-1 [00:43] wallyworld_: One is almost guaranteed to include regressions and need rolling back at least twice, while the other is a critical regression fix. [00:43] wgrant: i could land in devel but then there will be merge conflicts for the other one [00:44] Ah [00:44] "at least twice" - you so such a pessimist [00:44] How safe is use-convoy with the flag off? [00:44] This sort of stuff has an exceptionally bad track record. [00:44] it uses ye old launchpad.js as before [00:44] Sure, but there are presumably some changes. [00:44] And none of this has tests. [00:45] minor ones - mainly going to multiple YUI instances instead of a single instance [00:45] all the yui tests pass [00:46] The YUI tests don't use launchpad.js [00:47] true, but i diffed launchpad.js from trunk and it was the same [00:47] as the branch [00:47] wallyworld_: the easiest thing to do is probably to run "bzr branch lp:bzr-pqm ~/.bazaar/plugins/pqm" [00:47] accounting for expected skew [00:51] jelmer: thanks! looks ok. i'll know for sure when i land the next branch [00:52] wallyworld_: Ah, OK [00:52] I guess it's somewhat reasonable, then :) [00:53] wgrant: i bloody hope so at least. i've done a lot of smoke testing. [00:53] but lp is soooo big it's impossible to touch everything [00:53] StevenK: no, the other way around. /$revno/+combo [00:53] that way we can have as many paths as we want in there to start [00:54] wgrant: if my optimisim ^H^H^H^H^H blind hope proves false, i'll do a separate fix for the bug straight away [00:54] StevenK: so if the files were in /var/convoy/build/js we could set the root to /var/convoy and make the app provide /build/js/$revno/+combo as the url [00:55] wallyworld_: Sounds good. [01:03] rick_h: Really? The icing stuff is icing/ [01:03] rick_h: And lifeless said he wanted it like it [01:04] StevenK: right, well I don't think the order matters. In this way it's easier for me to regex since I can basically match anything up until the last item and make that a path (supporting multiple levels if required) and combo or +combo don't matter so we don't have to deal with changing upstreams usage [01:05] rick_h: But it does matter [01:05] StevenK: I think this gets the effect we want (changing the paths at run time based on the LP instance) without making too many changes [01:05] why? [01:05] rick_h: Since /+combo is proxied off in the apache config [01:05] So the URL has to *start* with /+combo [01:05] right, but we can't change that check to combo$? [01:06] I really don't want to do regex matches in the apache config [01:06] ok, shoot me a couple of urls we want to match and I'll see if I can change the regex to support what we want and what U1 and Landscape are doing at the same time [01:07] I didn't realize we had the limitation so I was merely trying to add directory support [01:07] rick_h: So, I'd make it configurable -- turn it on with a parameter in combo_app() [01:08] StevenK: so you're thinking a config of "allow_paths" or something that turns on/off grabbing path info from the url? [01:08] and then just if set do it the LP way? [01:09] rick_h: And I was expecting something like /+combo/r12456/yui/yui/yui-min.js or /+combo/r14858/lp/registry/timeline.js [01:09] rick_h: Right, exactly. [01:09] ok, so I want to match /(toss)/(some)/(path)/(hints)/?... then right? [01:09] ok, I think I can reverse the regex for that in convoy. I'll update the tests and push a new one tomorrow then [01:11] Right, so what you want to do for /+combo/r12456/?yui/yui/yui-min.js is actually return /r12456/yui/yui/yui-min.js. Not really important, but I'd prefer the comment showing the filename didn't include the revno dir [01:12] right, all good [01:12] I follow, sorry, just was thinking normal url with path first, file end [01:12] should be an easy adjustment [01:24] sinzui: Still around to discuss the SSo issue a bit? [01:26] I am about [01:26] sinzui: Do you think the emailaddress-stealing code is still useful? [01:27] wgrant, I do. I recall users being very confused about the email mismatch [01:28] wgrant, but I really think the issue is that users expect synced email addresss to be synced [01:28] sinzui: More confusing than when they get logged into a different account, and then can't find their original account because it no longer has an email address to search by? [01:28] wgrant, If the l.lp.net did not lie about what/who it was, the sync issue might be mitigated [01:30] sinzui: We should certainly inform affected users that something is up. [01:30] wgrant, yes. [01:30] But I think that automatically "fixing" it is harmful. [01:30] Because in most cases the second SSO account is mistake. [01:31] And transferring the address to the second LP account just exacerbates the mistake. [01:31] I think we should rather warn on login. [01:31] That $otherperson has the primary address, see this wiki page for details. [01:32] We could explain we think identities are mismatched. We could let the user choose the transfer the email address (without email confirmation) [01:32] Right. [01:32] In fact, I was thinking that we could only really do this with addNotification. [01:32] But +openid-callback could prompt directly. [01:32] Add an extra step to the login. [01:33] Do we know enough info when this happens to advise the user to go back to SSO and sort the matter out? Do we know enough to tell the user about the two identities in Lp that are criss-crossed? [01:34] We sort of know in the case of Ubuntu. I do not think so in the case of another SSO provider [01:34] We can identify the other persoin in LP. [01:34] In the case of another SSO provider it doesn't matter. [01:34] Because we don't trust their email addresses. [01:34] So we *can't* do reassignment. [01:34] Well, Do I (me) really trust Ubuntu SSO at the moment. [01:34] We want to reassignment purely because login.launchpad.net confuses people by looking like Launchpad. [01:35] Heh [01:35] No. [01:35] * sinzui looks if he can delete email address now [01:35] You can now. [01:35] For a few months now. [01:35] kill-bugtask-launchbag-with-fire => devel [FAILED] (up for 1:38:25) i-568d8234 [01:35] :-( [01:35] StevenK: Which test? [01:36] I haven't looked yet [01:36] sinzui: So, I think that if an identifier is known we should trust it. If the email address isn't known by Launchpad, we add it to their person. If it *is* known by Launchpad but is on another account, we log them in but tell tham what's going on and how to fix it. [01:36] sinzui: They (and we) can do the proper fix then. [01:37] Because we can present the primary email addresses of both people. [01:37] Ubuntu is almost as bad as google. If I leave Canonical, my primary identity is compromised. People leave their employers more often then they change the personal addresses. [01:37] Whereas now we silently steal the conflicted primary email address, making it very hard to work out what the original state was, and how to recover. [01:37] I still do not trust [01:38] This also moves us towards a workflow for external providers. [01:38] Where logging in will create an invalid person, because it has no verified email addresses. [01:39] This same post-login workflow process could be used to verify an address. [01:39] wgrant: +1. Fixing bad data is always harder than letting a user know that something is wrong [01:39] sinzui: Right. And this situation only arises when a mistake has already been made, because just about nobody has a reason to have two SSO accounts. [01:41] wgrant, the mistake was ours I think. We made no distinction between imported identities and those users claimed and were active [01:42] SSO should purge ever address that that was not active when received from Lp and only accept those that are given my users [01:44] sinzui: Until last week SSO still had emailaddresses for Launchpad teams. [01:44] But we deleted those. [01:44] I don't know if it still has NEW ones. [01:45] including @lists.launchpad.net? That is an obvious imposability [01:45] I've endeavoured to understand the situations in both DBs and codebases. [01:45] But it is complicated. [01:45] I believe all @lists.launchpad.net addresses should be gone from SSO's DB now, unless they are associated with a proper account. [01:45] Which is a bit crazy, but possible I suppose. [01:46] rick_h: StevenK: use-combo is in ec2 :-) [01:47] yay!!! [01:51] wgrant, when Lp sees a mismatched email address. What can Lp do for the user? Transfer the email? I think Lp should suggest a merge instead. Since SSO does not have merging, I do not think we can explain how to make the identities the same if sso has 2+ identities for the user [01:51] sinzui: Right, I'm not sure. [01:51] sinzui: I've also just realised a complication. [01:51] Its a lost of email deletion and reclaiming I suspect [01:52] sinzui: If we don't steal the address, how do we deal with reactivating a deactivated account? [01:52] We don't have a preferredemail :/ [01:52] So I have a deactivated account, and log in with its OpenID, but the SSO preferredemail is on a different account. [01:53] The only way out is a logintoken. [01:53] Either to do the merge, or to validate and select a new preferredemail. [01:54] well, I think you are proposing a fix to an unreported bug. User complain we did not deactivate their account because they can login again. If Lp asked the user he wants to proceed, he would not compain [01:54] It gets even more complicated when we consider SCA [01:54] Which relies on the implicit reactivation behaviour. [01:54] And cannot have user interaction. [01:55] * wgrant dies violently. [01:56] You mean we make a Frankenstein identity from other identities, log the user in and say...Your Alive! Click here to die if you do not want to be a gestalt [01:57] Until last week the only way getOrCreateByOpenID could fail was if the account was suspended. [01:57] Currently it will fail if the provided email is owned by a team. [01:57] And ideally it would not return a valid person if it had to reactivate. [01:57] But SCA assumes it does. [01:58] And SCA involves money :) [01:58] I am not keen on suspending another 3000 spam profiles...screw SCA [01:59] I wonder if lifeless has jurisdiction over CA [01:59] Which owns SCA nowadays. [01:59] Ah, no, they're under OS [01:59] Sad. [02:03] I guess SCA is pretty similar to SSO [02:03] In that they both touch Launchpad in completely inappropriate ways. [02:03] I'm just less sure about how to fix SCA. [02:03] Because it relies on being able to obtain a Launchpad person for any unsuspecting SSO account. [02:04] Do we need to fix it now. Do users want us to fix it? [02:04] The problem is I broke it last week. [02:04] And fixing this cleanly will break it further. [02:04] Telling users we can fix SCA by doing what we do now and locking you out of part of your identity [02:04] Perhaps I should just restore the old behaviour of stealing the team address, however distasteful that may be. [02:05] This doesn't fix any of the other problems, though. [02:05] SCA prevents us from fixing the corruption issues :( [02:07] Although bug #901336 is encouraging. [02:07] It already breaks in some cases. [02:07] So maybe we can break it more and nobody will complain :) [02:07] Stealing a team address is very bad. We know every team address is a one that is being used. We delete any team address that the user does not indicate is being used [02:09] Lp has to tell the user that the address belongs to a team. The options are to remove the address (confirm via email to do it), login as the owner and delete the team, or go that to SSO and remove the badness [02:09] Sure. [02:09] That's clearly the correct solution. [02:09] But SCA relies on being able to get or create an LP person for any SSO account. [02:09] Without user interaction. [02:10] We probably want to decide to break that. [02:11] I do not think SCA advocates identity theft. Surely they have some guidelines for when to not honour the operation [02:12] The XML-RPC API that they use pretty much just calls getOrCreateByOpenIDIdentifier directly. [02:12] And the only way that could fail was in the case of a suspended account. [02:27] Although I guess if they getOrCreate the person early, they can fail before the transaction. [02:29] sinzui: So, I think for now I will fix it to steal team addresses again. But I will obtain the SCA code and talk to CA people about how it can do better. [02:30] okay [02:30] The quick fix is probably just to attempt to get the person right before payment. [02:30] That way there's only a small race, which probably already exists. [02:36] StevenK: bollocks. we need to get a new ec2 image with convoy packaged or else make fails [02:36] wallyworld: Or just add it to launchpad-developer-dependencies, and ec2 should auto-install it. [02:37] wgrant: of course, much easier [02:37] StevenK: ^^^^ can you do that? i have no idea how and want to get this fucker though ec2 [02:38] actually, i think there's already a partial branch for it [02:38] Ah, buildbot will need a manual upgrade too, actually. [02:42] how do we do that? [02:43] webops :) [02:43] thought that may be the case [02:44] i'll wait for StevenK to pop up and we can get it sorted in one go [02:44] Oh, blah. [02:44] That means convoy will need catification [02:44] you mean whiskers and a saucer of milk? [02:44] :-) [02:44] Close enough. [03:00] Oh, right [03:01] wgrant: You don't like that idea? [03:08] wallyworld: O hai -- https://code.launchpad.net/~stevenk/meta-lp-deps/use-convoy/+merge/89174 [03:08] StevenK: you want a review? [03:09] wallyworld: I do, yes. [03:09] wallyworld: I have to wait for convoy to publish in the LP PPA anyway. [03:09] looks ok to my untrained eye, will _1 [03:09] +1 [03:10] StevenK: so what's the next step? looks like i can't ec2 land today? [03:10] You could, but it would then fail buildbot [03:11] bollocks [03:11] * StevenK sees if convoy is installable from the PPA [03:11] so we could get your ppa installed on bb? [03:12] Only if you want a GSA to visit you personally with some sharp implements [03:12] wallyworld: Jump on mumble, and I'll outline it [03:13] StevenK: ok. i may have to reboot so if i drop off, i'll be back in a bit [03:13] wallyworld: So, I'd suggest ec2 testing today [03:13] If it works, then get convoy into cat and onto bb [03:13] * StevenK glares at mumble [03:14] 3 copies?! [03:14] * StevenK wields kill [03:14] not to be landing such think on friday [03:31] lifeless: WCPGW! [03:57] sinzui: +1 on that mp if you want to send it to ec2 before you go to bed [04:00] wallyworld: meta-lp-deps changes merged, waiting for the recipe builds -- they should kick off automatically in the next 1-2 minutes [04:00] \o/ thanks :-) [04:01] StevenK: Did you just make them uninstallable in the DC? :) [04:06] wgrant: Huh? [04:07] wgrant: But buildbot doesn't update from the PPA? [04:07] StevenK: No. [04:07] StevenK: But making the dependency packages uninstallable on buildbot is pretty unpleasant. [04:09] wgrant: I was of the opinion that the dependencies packages had to get copied to CAT [04:09] Ah, true. [04:18] Oh, damn it. [04:19] My launchbag branch failed with a message so large my mail server rejected it. [04:19] lol [04:19] And I think the instance has just killed itself. [04:28] StevenK: Locally run bin/test -cvvt lp.bugs? [04:28] Yes, I was planning on [04:35] wallyworld: Right, meta package updated. [04:35] Strangely, apache2 is a Suggests of developer-dependencies [04:35] It's forcibly installed by rf-setup [04:35] wonder why [04:36] Because it's not required to run the tests [04:36] ok [04:36] So people will have to install libapache-mod-wsgi when they want to test the combo loader [04:37] wallyworld: In either case, you can toss your branch at ec2 test [04:37] Sigh, libapache2-mod-wsgi [04:37] * wallyworld tosses [05:03] wallyworld: It should have built, can you run 'bin/ec2 ls --show-urls' and see what the log shows [05:04] StevenK: ah, bollocks. i didn't look back at the console after i ran and there was an error. trying again [05:04] What error? [05:05] i pasted in the mp url instead of the branch [05:12] * wgrant tries not to be sick. [05:14] wgrant: Hmm? [05:16] StevenK: https://bugs.launchpad.net/launchpad/+bug/556680/comments/5 and https://bugs.launchpad.net/launchpad/+bug/881019/comments/15 [05:16] Beware, there is OpenID. [05:19] The novel you posted to bug 556680 is impressive. [05:21] wgrant: can has quick review? https://code.launchpad.net/~wallyworld/launchpad/sortable-dates-fix-918892/+merge/89380 [05:22] wallyworld: Ah, heh. [05:22] r=me [05:23] wallyworld: I won't ask how long *that* took to track down. [05:23] thanks. took me ages to find the problem. seems really simple now [05:23] about 4 #@%@^ hours [05:25] my brain hurts sooooo much today. this week it has done a lot of cogitating [05:26] wgrant: could use lp-land for me? pretty please. ec2 land now works but lp-land still is broken [05:26] Good to see you living dangerously :) [05:27] well, there are no tests for it [05:27] Heh [05:27] and it's broken anyhow [05:28] Submitted [05:28] wallyworld: What's wrong with you lp-land? [05:29] *your [05:29] huwshimi: an api change in precise [05:29] one of the bzr libs [05:29] wallyworld: Oh, awesome [05:30] various get_foo methods replaces by get('foo'), or something like that [05:30] it's known [05:42] wgrant: Total: 3223 tests, 112 failures, 99 errors in 56 minutes 38.785 seconds. [05:43] I think I see why the failure mail was 15MiB. [05:43] wallyworld: I wonder if pqm-submit works for you [05:44] StevenK: use-convoy => devel [FAILED] (up for 0:37:03) i-e81c158a.... waiting for the email to arrive to see what happened [05:44] That will take another 3+ hours [05:44] You can add --show-urls and open the URL it shows [05:45] StevenK: actually, i updated bzr-pqm earlier today so perhaps it will work [05:46] StevenK: failures due to doc test errors. extra lines like "import site' failed; use -v for traceback" [05:47] Hm [05:47] You may have to run them locally [05:47] so with that extra output, most all doc tests break. but other tests appear fine [05:47] It's of course possible that ec2 only runs apt-get upgrade, so it won't have installed convoy... [05:48] how is import site related to convoy being installed? [05:48] Is there much else it could be related to? [05:48] They're not obviously related, but it's the only thing that comes to mind. [05:48] no, but i don't get the correlation [05:48] site overrides our pythonpath and various other evil things. [05:49] wgrant: The make was successful, so it has [05:49] Hmm [05:50] upgrade will install new dependencies of already installed packages that are to be upgraded [05:50] Except sometimes it doesn't. [05:50] Depends on the situation [05:51] yes, without convoy installed, make failed [05:51] apt has some funny ideas [05:51] Frequently eg. linux-generic gets held back, despite just requiring installation of new ABIed packages. [05:51] i tried locally a test and i got a different error [05:51] 'import sitecustomize' failed; use -v for traceback [05:52] similar but different [05:53] wgrant: ec2 does aptitude update and aptitude -y full-upgrade [05:53] Yay for pointlessly different package resolution [05:54] i get 'import sitecustomize' failed; use -v for traceback whenever devel/bin/py runs [05:54] everything that doesn;t try and match text against stdout like doc tests do seems to work [05:55] Let's delete all doctests. [05:55] I can't see anyone disagreeing with that plan. [05:55] i'd still like to know wtf is going on [05:56] doctests are useful if they are used as doco plus examples to show how to use the apis [05:56] use -v for traceback :) [05:58] self.user = request.user [05:58] AttributeError: 'LaunchpadTestRequest' object has no attribute 'user' [05:58] RARGH! [05:58] Hmm [05:58] request.principal ? [05:59] python 2.7 related error it seems https://pastebin.canonical.com/58488/ [06:00] StevenK: request.user should be right, but maybe LTR doesn't provide it. [06:00] It would seem it does. [06:00] Er, does not [06:04] wgrant: lbr.user == AttributeError: 'LaunchpadBrowserRequest' object has no attribute 'user' / lbr.principal == None [06:09] * StevenK shakes his fist at LaunchBag [07:50] * StevenK is concerned that we don't any production OOPS report from today. [07:52] StevenK: postgres was restarted for an upgrade, so it's not entirely surprising. [07:52] Ah [07:52] The amqp2disks died, but I restarted them. [07:53] wgrant: http://www.flickr.com/photos/telekon/6718360105/ === almaisan-away is now known as al-maisan [08:59] good morning [09:08] Morning guys === al-maisan is now known as almaisan-away === jtv is now known as jtv-eat [11:32] morning === jtv-eat is now known as jtv === stub1 is now known as stub [12:25] Does anyone know where lifeless's list of architecture values lives on the web? (ISTR "visible" and "fast" being two of them) [12:28] jml: http://launchpad.readthedocs.org/en/latest/values.html ? [12:29] or http://launchpad.readthedocs.org/en/latest/strategy.html [12:29]