[00:00] what: http://paste.ubuntu.com/701996/ [00:02] haha uh, why have i had an ec2 t1.micro running since march? [00:02] Haha [00:02] Aren't they effectively free now? [00:10] only for new signups i think? [00:11] anyway it hasn't been costing me very much or i'd have noticed within a month i guess :-) [00:37] sigh, 4 attempts to get ec2 test running :/ [00:37] (merge failure, odd ssh failure, local net glitch) [01:50] wgrant: Didn't we remove polls? [01:51] StevenK_: Yes, but they were revived. [01:51] we tried [01:51] Because Ubuntu use them. [01:51] Really? They haven't been used for the last few elections [01:51] Morning [01:51] wgrant: Ubuntu uses them for what? [01:51] StevenK_: ubuntu womens [01:52] IIRC === StevenK_ is now known as StevenK [01:52] Most elections are condorcet [01:52] Ubuntu Women also used that, not LP polls [01:58] So perhaps we should ask Ubuntu again? [01:58] * StevenK [01:58] Sigh [01:58] * StevenK searches for a single word that means 'person or team' [01:59] person [01:59] Or Person. [01:59] so, feature flags [01:59] wgrant: IE, I want a class name for the refactored code. [02:01] err hm [02:01] why does LaunchpadTestRequest set .features to NullFeatureController? [02:04] i guess LaunchpadTestRequest is used in some tests that don't have a db connection, perhaps [02:08] StevenK: Atom [02:14] lifeless: Any idea what's going on with the lazr.restful OOPS fix? [02:18] ECONTEXT [02:20] lifeless: The one you mailed IIRC benji about a week or so ago. [02:20] The __traceback___ one. [02:20] I thought he fixed it already [02:20] he acked it and made a branch immediately [02:21] Yeah. [02:21] But it apparently never landed. [02:21] * wgrant hunts. [02:23] https://code.launchpad.net/~benji/launchpad/bug-854695/+merge/76285 [03:50] wallyworld_: I don't think you want the trigger to initialize transitively_private in the BEFORE trigger, as it will be overwritten in the AFTER trigger anyway. Just 'ALTER TABLE Branch ALTER COLUMN transitively_private SET DEFAULT TRUE;' should be fine? [03:51] stub: sounds better. for some reason i thought we frowned upon default values for non null columns though? [03:51] and i think the default needs to be false [03:52] False is bad. [03:52] We frown on adding a new column with a DEFAULT, as that causes all rows in the table to be rewritten with the new DEFAULT. [03:52] Adding a DEFAULT to an existing column is fine === wgrant changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: - | Critical bugs: 255 - 0:[#######=]:256 [03:52] stub: ok [03:52] stub: if the trigger fails, will the row be rolled back? [03:53] wallyworld_: I chose DEFAULT TRUE because if the trigger is broken (it isn't), we default to private. Either TRUE or FALSE should be fine as the DEFAULT> [03:53] wallyworld_: Yes, if the trigger fails the whole transaction will be rolled back. [03:53] stub: wgrant: the reason for me asking for default = false is that i need to check the short circuit rules in the trigger [03:54] ok [03:54] if transitively_private is true, then it may not bother doing anything [03:54] short circuit checks private, not transitively_private [03:54] But double checking is good :-) [03:55] Tests are better... [03:55] yes, agreed. i will write one now that we are taking this approach [03:55] Hmm... the MP has gone [03:56] lifeless did not realize the field is already maintained with the AFTER trigger [03:56] stub: i renamed the branch [03:56] in anticipation of landing it in two parts [03:56] You can rename branches? [03:56] i'll rename it back [03:56] yes, apparently :-) [03:57] I managed to misspell logintoken as lockfile in my branch name the other day... [03:57] stub: renamed back now [03:57] go to the branch details link [03:58] and you can rename [04:37] Can haz review? https://code.launchpad.net/~stevenk/launchpad/refactor-team-rename/+merge/78037 [04:56] Obviously, the answer to that question is "no". [04:57] Indeed. [04:57] So. [04:57] You've moved it into the model, apparently. [04:57] Which is probably where it should be. [04:57] But... [04:58] Person and Team don't need a model mixin, because they're both the same class. [04:58] So make it a method in IPerson itself? [04:58] reason = self.context.can_be_renamed() or so? [04:59] Quick possibly. checkRename or something like that. [05:00] * StevenK refactors the refactor [05:00] StevenK: Also, can you put the "has" in the template? [05:00] Removes the has_ppa check under has_mailing_list. [05:00] But I can't ... [05:01] Why not? [05:01] Because it changes the prose for the both check [05:01] This %s has %s and may not be renamed. [05:02] "has a PPA ... and has a mailing list" versus "has a PPA and a mailing list" [05:02] %s is "an active PPA with packages published", "a mailing list", or "an active PPA with packages published and a mailing list" [05:02] Oh [05:02] Right [05:02] Also, possibly s/user/person/ [05:02] Also fixed [05:11] is there a reviewer in the house ? [05:13] https://code.launchpad.net/~lifeless/python-oops-datedir-repo/hashing/+merge/78039 [05:21] lifeless: Why BSON? :( [05:22] These are going to be even less readable than SSO OOPSes. [05:24] wgrant: decoders exist; handles binary crud (which we get like it or not) [05:24] And makes it just about impossible to view OOPSes unless oops-tools is agreeable and fast. [05:24] neither of which is true. [05:25] this is a component in fixing that [05:25] And until then our error analysis capabilities are crippled. [05:25] how so ? [05:25] It becomes extremely difficult to respond in realtime to complaints involving OOPSes. [05:26] details dude [05:26] give me the details [05:26] I don't speak BSON. [05:26] text editors don't like BSON. [05:26] oops-tools is slow to render, and even slower to pick up OOPSes, and often doesn't ever see them at all. [05:26] import bson; bson.loads(open('foo', 'rb')) [05:26] Mmm, perhaps. [05:26] OK. [05:27] slow to render is as yet undiagnosed. Slow to pick up is what I'm on an arc to fix. [05:27] not seeing them is fixed as soon as that chroot comes around. [05:28] * StevenK gets spammed by wgrant [05:28] StevenK: Oh? [05:28] bugmail? [05:28] Yeah [05:28] lifeless: Also, what about eg. dev/DF OOPSes? [05:28] Damn it, come on MPJ! [05:28] wgrant: DF - install oops-tools. [05:28] hahahaha [05:28] wgrant: dev - oops-tools is about to be opened [05:29] wgrant: tests can use the programmatic interface [05:29] So everyone has to run their own Django app to see oopses? [05:29] wgrant: or you can set the serializer to rfc822 - I kept compat for a reason. [05:29] We need a sensible dev story for this before it becomes the default. [05:29] +2,000,000 [05:29] no, we need to get this shit sorted [05:30] that django app is easier to install than LP [05:30] Yes, but sorting shit so it breaks other shit is not ideal. [05:30] 2 branches + buildout and a postgresql cluster [05:30] wgrant: its not breaking other stuff [05:30] It's another barrier to contribution [05:30] Which is already too high [05:30] So, fail [05:30] It's breaking the ability to debug a local Launchpad instance. [05:30] And to see test failures. [05:31] no, its not - to either. [05:31] the test suite attachOopses uses rfc822 serializer - it receives the oops dicts. [05:32] Ah [05:32] oopses written by subprocesses will change format, yes. But they are *already* a PITA to get at - and trivially decoded using... bson [05:32] It is trivial. [05:32] StevenK: its a barrier to -some- forms of contribution, but I look at a local oops about once a month, if that. [05:33] I tend to look at OOPS on carob using cat, now I won't be able to. :-( [05:33] StevenK: pages will still show backtraces to local devs, the console backtrace will still be plain text [05:33] But analysis of dev and prod OOPSes at the moment is now often done by means of cat, grep and cut [05:33] I hate our oops-tools app [05:33] so fix it [05:33] Sure, in the oddles of free time I have? [05:33] Right, we should fix it. [05:33] But *before* we break everything that isn't it. [05:33] I don't see why BSON has to happen at the same time as hashes. [05:33] we are -stalled- on multiple important improvements to our data gathering - to whit, extra info on appserver resource usage, clearer metadata, evolving the damn thing. [05:33] It seems unrelated. [05:34] they are separate fields in the repository object, and we can configure them however we want. [05:34] e.g. dev mode can use rfc822 if you don't mind extra data being dropped. [05:35] wgrant: Can you have another look at my MP? [05:35] StevenK: Was just doing so. [05:35] lifeless: What is the benefit in moving to BSON at the same time? [05:35] again, claiming this is breaking things is very exaggerated. Yes, the shell pipelines you used won't work. Are they intractably different with a new serializer? No. [05:35] +71 -44 makes me a little sad. I prefer removing more code than I add. [05:36] wgrant: A) I haven't moved anything to bson, B) see above. [05:37] 87+ Defaults to using serializer_bson. [05:37] Hm, this might be able to be refactored further. [05:37] yes [05:38] but our packages are version locked, except perhaps txlongpoll which I haven't looked into, so when bumping the version, if we want rfc822 explicitly we can do that. Its not coupled to *this* merge proposal. [05:38] (Separately, yes, I plan to use bson when I update the dep in LP, I'm being pedandtic because of the hyperbole you're tossing at this) [05:42] wgrant: so, what are you asking be written before we change to bson ? [05:42] Well, ideally we would have OOPS analysis tools that didn't involve obscene shell pipelines. [05:43] But that seems to not be practical. [05:43] wgrant: (Note that 'do not break anything' is incompatible and I reject that out of hand) So it 'provide a full text index' - we have plenty of ability to search with os.walkdirs + bson in an adhoc manner, IF/when oops-tools fails to meet our needs. [05:43] wgrant: I would *love* to run up solr etc and JFDI [05:44] wgrant: but thats a long pipeline, and I'm tired of getting significantly better data from oopses being blocked - when the change needed to do it differently is not all /that/ big [05:46] again though, policy vs requirements - this branch lets us choose [05:46] Blah, too hard to refactor further. Mainly because browser/person.py is *obscene* [05:47] wgrant: your smoketest branch - +1 [05:48] lifeless: Thanks, I'll propose it properly in a sec. [05:49] wgrant: Can haz a vote? [05:49] lifeless: A couple of questions, but yours is approved. [05:51] wgrant: oops-pruner [05:51] wgrant: thanks [05:51] lifeless: But they're normally on disk as 1234.ABC1234 [05:51] Not OOPS-* [05:52] wgrant: I've just pushed a change to make {Person,Team}EditView.setUpWidgets() identical, but it's very hard to refactor further. [05:52] StevenK: REFACTOR FURTHER [05:52] Always refactor further. [05:52] wgrant: yes, but the *id* is normally OOPS-blah. And using the id directly is simpler than using the id minus OOPS- [05:53] wgrant: also, the name on disk at the moment is all to do with sorting [05:53] True. [05:53] Go ahead, then. [05:54] wgrant: I tried. TeamEditView can't use BasePersonEditView as a parent due to circular import hell. [05:54] Oh? [05:54] browser.person import browser.team? [05:55] wgrant: http://pastebin.ubuntu.com/702084/ [05:57] StevenK: WTF, why does browser.person import from browser.team? [05:58] Move Team*Menu into browser.team [05:58] classImplements(TeamIndexView, ITeamIndexMenu) [05:58] classImplements(TeamEditView, ITeamEditMenu) [05:59] But yes, that's a little screwed. [06:26] jamesh: hi [07:07] Morning. [07:07] wgrant: Hi William, thanks for QA'ing my +initseries branch ;). === almaisan-away is now known as al-maisan [07:08] It turned out to not be so important, but it was easy enough :) [07:09] lifeless: hi [07:09] Always nice to start my day with a qa-ok message from the other side of the planet ;) [07:10] jamesh: ola~ [07:10] jamesh: so, two things; oops-datedir-repo can write bson reports now (and trunk oops-tools can read them) [07:11] jamesh: this makes extension and handling a -lot- easier, I think you'll agree ;) [07:11] yep. [07:12] jamesh: secondly, I was wondering if you'd tried integrating stuff again? [I'd love to have an answer for getting oopses into the oops-tools django app itself, for instance] [07:13] lifeless: I haven't done much since we last talked. My test u1 branch does log reports with unmodified Django (by subclassing Django's WSGI handler) [07:14] perhaps that subclass should be in oops-* somewhere? I don't know enough django to know if that makes sense [07:15] jamesh: also, thats awesome - we're in business ;) [07:15] wgrant: as promised (and as penalty you get the review :P) https://code.launchpad.net/~lifeless/python-oops/hostname/+merge/78053 [07:17] lifeless: http://paste.ubuntu.com/702108/ <- Using this instead of the standard WSGIHandler should be enough. [07:18] actually, that plus oops_on_status=['500'] [07:18] lifeless: Approved. [07:18] for the oops-wsgi middleware [07:18] With missing apostrophe. [07:18] wgrant: and aggregate->aggregation [07:19] wgrant: do you mean 'machines''s' ? [07:19] Right. [07:21] wgrant: on thursday, can I pick your brain on wabbit ? [07:22] lifeless: Of course. [07:22] jamesh: is there a preferred way to receive rabbit events in django ? [07:25] lifeless: I don't think so. We've been handling them in a Twisted reactor running as a separate thread [07:25] aieeee [07:26] jamesh: how have you been handing off back to django code? or are you calling it from deferToThread sort of things? [07:26] bbiab [07:27] lifeless: I haven't poked too deeply in this area, but I think we're usually pushing out messages from Django views rather than receiving them [07:28] Django is not that well suited to long-poll style request handling, which is the main type of request I'd expect to want to receive messages [07:29] jamesh: I want to add oopses to the django db as they happen [07:29] jamesh: and write them to disk likewise [07:30] I smell a daemon... [07:30] Doing that from the WSGI app seems, er, aaaaaaa [07:30] wgrant: we have one [07:31] wgrant: doing that from outside the django transaction is also aaaaaa [07:31] Huh? [07:31] OMG, there's so much Team stuff in browser/person.py :-( [07:31] lifeless: okay. So I probably wouldn't try to squeeze that into a Django web app. You could certainly use the Django ORM from a separate daemon that receives the messages. [07:31] That would seem like the least insane way to go about things. [07:32] Unless we're using SQLite, running it in a separate process should really be less than a problem. [07:32] wgrant: I've moved the classes that caused the circular import, shall I explode the size of this branch and move everything that they depend on too? [07:32] wgrant: why would sqlite be a problem? [07:32] jamesh: SQLite doesn't do multiple writers, does it? [07:33] wgrant: pretty sure it does. [07:33] it does [07:33] I'm sure it is possible to configure the locking out of it, but I'm pretty sure it is in by default [07:33] but you need latest shiny [07:33] and its still got a large lock even tuned optimally [07:34] we can do a separate daemon, though I have an aesthetic dislike - I'd rather have an API on the one app and not poke into its backend [07:34] I don't think you're in any worse situation by having two processes accessing the database than a single process accessing the database from multiple threads with multiple connection objects [07:34] OTOH I don't want to make this a pile of yak shaving [07:34] jamesh: we're using pgsql anyhow [07:35] 27M oops reports would give even sqlite a bit of a hernia [07:35] without -very- careful tuning [07:35] lifeless: well, you can use your Django ORM classes outside of a web app. [07:35] I'm not suggesting that you duplicate all the application logic [07:35] * StevenK prods wgrant. [07:35] jamesh: sure, I know :) [07:36] jamesh: like I said, its an aesthetic. We'd avoid a lot of issues in LP if we did that there, for instance. [07:36] StevenK: Sorry, missed that. Could you possibly move it in a prereq? [07:36] * lifeless shrugs, we can start with a daemon and db access and switch to daemon + web api later [07:37] wgrant: BLEH [07:38] you'll just have to make sure your separate daemon process sets $DJANGO_SETTINGS_MODULE to something sensible before importing django [07:54] wgrant: This pipe is already 1885 lines and I'm not finished yet. [07:54] :D [07:56] wgrant: Right, every {I,}Team class moved is 2006 lines. === mrevell_ is now known as mrevell [07:56] Now to fix __all__ and imports [07:56] And configure.zcml [07:58] StevenK: Nice cleaning :) [07:59] OH GOD, IT BURNS [08:01] PersonNavigation needs TeamMembershipSelfRenewalView, PersonView needs TeamJoinMixin and TeamOverviewMenu. [08:01] circular imports a-go-go [08:01] wgrant: ^ [08:04] Oh damn, and the Mixin is a parent class. [08:04] Hah. [08:04] /wrists [08:04] But why would PersonView need TeamJoinMixin? [08:05] Oh no. [08:05] I think PersonView might be used for teams as well. [08:05] StevenK: surely your wrists are used to the strain [08:05] wgrant: Looks like it. [08:06] Ah, TeamIndexView [08:06] Hopefully you can export TeamIndexView to browser.team, and take TeamJoinMixin over there. [08:06] I've already moved it. [08:06] I moved every {I,}Team class. [08:07] Now I'm trying to make pyflakes happy [08:07] Change TeamIndexView to inherit TeamJoinMixin, instead of PersonView inheriting it. [08:07] Hopefully only the team views need it. [08:09] StevenK: I mean from playing WoW of course... :) [08:10] bigjools: I quit WoW 3 months ago. [08:10] StevenK: good grief, are you feeling ok? [08:12] And that is why I didn't tell many people. [08:13] online games are like a drug addiction - I've gone cold turkey twice now [08:15] lifeless: fwiw, the Django bug report about fixing the WSGIHandler to not need that fix is no longer in the "design decision needed" black hole [08:15] jamesh: did it win or lose ? [08:16] lifeless: https://code.djangoproject.com/ticket/16674 <- they moved it to accepted, and wanted more verification that the change wouldn't cause problems. [08:16] \o/ [08:29] wgrant: pyflakes clean, 2287 lines [08:34] StevenK: But does it run? :) [08:34] No, not yet. [08:35] Fighting with ZCML [08:44] wgrant: I have a small subset of tests passing, 2477 lines. [08:44] Heh. [08:45] Let me toss me it at ec2 to find the rest. === gmb changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: gmb | Critical bugs: 255 - 0:[#######=]:256 === al-maisan is now known as almaisan-away [11:11] stub, hi? [11:11] yo [11:11] stub, can you suggest what to do on bug 866160? [11:11] sorry bug 866100 [11:11] <_mup_> Bug #866100: bug search with affects_me=on times out < https://launchpad.net/bugs/866100 > [11:13] poolie: Need the OOPS to sync [11:14] hm and now it's not timing out [11:14] how uncooperative [11:14] poolie: I think it times out on first try [11:14] (and then caches) [11:14] that's likely [11:14] well, the oops will sync later [11:14] It timed out once for me, refreshed later. [11:16] I'm looking forward to 2 days of lp hacking \o/ Holidays! [11:17] :) [11:19] * gmb -> lunch [11:20] stub, i put an example failing query there, in case that helps [11:20] good night now [11:20] g'nite poolie [11:22] poolie: We don't know if that is the slow query. All we know is that it is the query being run when the timeout was hit. [11:23] that is true, but that's similar to the query that was sometimes very slow when run on qas and by losas on prod [11:23] anyhow no rush [11:24] If it is, things to try are to move the BugTask.id IN () subquery using BugAffectsPerson into a normal join, or to enforce it is actually run as a subquery rather than the planner turning it into a normal join by using a WITH clause. [11:25] I can reproduce with a simpler query on production. [11:26] I don't think either of those options I mentioned will help greatly here [11:31] We are ordering results using a field on Bug, but all the selection is going on in bugtask. [11:34] Not sure what we can do here. We can optimize for the case where we know we will not match many BugTask rows, but if we wanted to do 'All bugs targetted to Launchpad, order by date_last_updated' it would likely fail. === almaisan-away is now known as al-maisan [12:29] hi gmb, can i get a review when you have time? i apologize it is way over our agreed size limit [12:29] bac: Sure. I should be able to take a look at it within the next hour or so. [12:29] thanks gmb [14:19] abentley, hey, hey. Sorry the vet visit toook *much* longer than I expected. [14:19] deryck: that's okay. [14:19] deryck: lemme grab my coffee, and we can chat. [14:19] abentley, let me just get settled in and we can chat briefly for a standup. [14:20] abentley, yeah, give me 10 minutes. [14:21] * beuno hands gmb bug #867529 [14:21] <_mup_> Bug #867529: Dynamic loading comments load on top of page content < https://launchpad.net/bugs/867529 > [14:29] abentley, heading into mumble now. [14:30] beuno: Thanks === fjlacoste is now known as flacoste [14:32] gmb: Would you have time to mentor a review of mine? [14:33] rvba: I've got a large review to do for bac first, so you might be better served finding another reviewer to mentor you on this one. [14:34] gmb: Okay ;) === al-maisan is now known as almaisan-away [14:59] gmb, do you have time to review https://code.launchpad.net/~sinzui/launchpad/dsp-historic-attributes/+merge/78106 [14:59] sinzui: I'm currently reviewing a large branch for bac, but I'll try to get to it this afternoon if I have time. [15:01] * bac hangs head [15:05] oh. damn. I should of claimed that this morning because I read half of it [15:06] jcsackett, do you have time to mumble? [16:11] skaet, ping [16:11] deryck, pong [16:11] sinzui: I'm afraid I won't be able to get to your branch today as I have to get a few other things done before my rapidly-approaching EoD. I believe StevenK is next on the list of reviewers. [16:11] thanks === gmb changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: - | Critical bugs: 255 - 0:[#######=]:256 [16:12] skaet, I'm trying to QA bug 834082. Can you try poking the issue you reported at our qastaging server and see if it's fixed for you? [16:12] <_mup_> Bug #834082: Cannot target a bug to a series from an existing series task < https://launchpad.net/bugs/834082 > [16:12] bac: r=me (with comments). Excellent work, thank you. [16:12] thanks gmb [16:12] * bac didn't do most of it, of course [16:13] deryck, will try. [16:13] skaet, thanks! Here's a starting point, if you're not familiar with qastaging: https://bugs.qastaging.launchpad.net/ubuntu/oneiric/+bugs [16:14] skaet, qastaging can timeout so it's worth a reload or two if you hit a timeout. === beuno is now known as beuno-lunch [16:18] * skaet gets the timeouts.... [16:19] skaet, do you even get to a bug page? [16:19] deryck, get the bugs in oneiric page from the link you gave just fine. However not being able to get to 834082 [16:19] ah, that sucks. [16:21] skaet, will another bug work? [16:22] deryck, can you give me a link to that bug page directly? May be faster than searching. [16:23] skaet, https://bugs.qastaging.launchpad.net/launchpad/+bug/834082 [16:23] <_mup_> Bug #834082: Cannot target a bug to a series from an existing series task < https://launchpad.net/bugs/834082 > [16:26] deryck, that got it. will poke around. [16:26] skaet, thanks! [17:02] sinzui: available to talk for a few? [17:02] okay === beuno-lunch is now known as beuno [17:25] e [17:26] * gmb chuckles at rockstar's response to https://bugs.launchpad.net/launchpad/+bug/867661. [17:26] <_mup_> Bug #867661: Useless Comments on Bug Reports < https://launchpad.net/bugs/867661 > [17:26] gmb, he left it open. [17:27] rockstar: Oh, indeed. In fact, I was half tempted to reply in the same vein until I saw you'd beat me to the punch :) [17:32] jcsackett, https://bugs.launchpad.net/launchpad/+bug/867718 [17:32] <_mup_> Bug #867718: DSP picker entries are redundant < https://launchpad.net/bugs/867718 > [17:33] skaet, any luck checking that out? [17:38] I see txlongpoll is taking 8% of my CPU all the time. That does not bode well. Nothing should preform worse than xorg [17:47] deryck, got pulled into release issues while still trying, will take a pass at it later this afternoon. [17:48] skaet, ok, no problem. Thanks! === Beret is now known as Dean [19:42] gary_poster: bzrlib.branch.Branch* is never security-proxied, but LoomBranch* is security-proxied. I think they should be the same, but I've had trouble figuring out why bzrlib.branch.Branch isn't security-proxied. [19:44] abentley, mwhudson put in some code for that in lib/lp_sitecustomize. I suspect that's what you are looking for. Look for dont_wrap_class_and_subclasses in that module, and its uses. [19:44] gary_poster: thanks. [19:44] welcome [19:50] oh yes, that fun [19:57] oh dear, my ec2 failure mail is so large emacs crashes opening it [20:05] gary_poster, mwhudson: my fix: http://pastebin.ubuntu.com/702418/ [20:06] abentley, interesting. Comments make it good AFAI am concerned. [20:06] abentley: i wonder if moving the code that sets up BZR_PLUGIN_PATH to lp_sitecustomize might be better in some ways? [20:06] * gary_poster defers to mwhudson :-) [20:06] then there are a few random imports of lp.codehosting that can just go away [20:06] gary_poster: i haven't thought about it very hard! [20:07] :-) [20:07] mwhudson: I think I was on crack to make an import have side effects like enabling plugins. [20:08] abentley: i think this crack predates you on the lp team doesn't it? but yes [20:09] there is a slight argument that say, the appservers, should not import lp.codehosting at all and so won't have plugins enabled [20:09] but if that's the way we want to go, they should be separate code bases (hi rob!) [20:11] mwhudson: No, it was basically the first thing I did on the team. [20:11] ah ok [20:12] mwhudson: as long as the appservers are the private xmlrpc servers, they need to support loom branches. [20:13] err how so?> [20:14] mwhudson: Oh, I guess they operate at a lower level, providing transports, so they don't actually need to know about branch formats. [20:14] yeah, just paths on disk [20:15] so my ec2 test run appears to have failed, basically because the db started erroring all the time about half way through [20:17] ah, it's hard_timeout checking [20:27] * jelmer waves to abentley, mwhudson [20:27] * abentley waves at jelmer [20:27] * mwhudson waves back [20:27] oh god everything is broken [20:41] # XXX Julian 2009-05-13, bug=376171 [20:41] # Temporarily disabled because of intermittent failures. [20:41] 2.5 years of temporary [20:42] mwhudson: 2.5 years is nothing compared to what the early Launchpad and Ubuntu specs planned to do in a single cycle [20:42] haha true [20:43] launchpad.canonical.com from about 2006 should be put online as a kind of massive example of how not to do project management [20:46] heh [20:46] http://web.archive.org/web/20060611133645/https://launchpad.net/ [20:48] ploooooooooooooone! [20:48] or at least, it's css [20:49] heh, indeed [21:26] mwhudson: yeah there is a little bootstrap issue with hard timeouts [21:27] mwhudson: will be if/when we make soft ones flagged too [21:27] mwhudson: mmm, perhaps not. Anyhow, hard for sure [21:27] lifeless: yeah, the permit_timeout_from_features flag is now on the request too in my branch [21:28] lifeless: it's not reliably reset between tests in devel currently, so if it gets set (say by a test publication) and a test runs that sets up a feature controller before it gets reset... hilarity ensues [21:29] mwhudson: win [21:29] (and one of the parts of my branch that i'm not 100% sure about is that a lot more tests set up a feature controller now) [21:29] so you asked yesterday about null feature controller and ltr [21:30] IIRC LTR is used in layers that don't have all the bits assembled, was the reason. [21:32] yeah, that makes some kind of sense [21:32] but i bet those tests don't actually access the feature controller [21:32] (bit fragile of course) [21:32] you'll find out, or go mad trying. [21:32] I'm betting on mad. [21:33] i'm hoping ec2 test will find out :-) [21:33] * mwhudson might actually claim for his ec2 expenses this month... [21:34] if its more than the cost of doing expense claims ? :) [23:37] flacoste: http://h30565.www3.hp.com/t5/Feature-Articles/Innovate-or-Suffer-Slow-Brain-Asphyxiation/ba-p/499 is good reading [23:55] haha, if you wiggle things around so that feature flags are active most of the time, a few sql effort tests fail