| lifeless | \o/ | 02:08 |
|---|---|---|
| lifeless | 10000 OOPS-fb8c41fc98e9a541a1175a570450f288 Unknown | 02:08 |
| StevenK | wgrant, wallyworld_: https://code.launchpad.net/~stevenk/launchpad/auditor-on-packageupload-reject/+merge/119291 | 02:08 |
| lifeless | StevenK: how goes auditor ? | 02:08 |
| StevenK | lifeless: Still wondering what the next step is. | 02:09 |
| lifeless | go on | 02:09 |
| StevenK | lifeless: So we have auditor, its fixture, its client and now two callsites in LP | 02:11 |
| lifeless | is there a staging auditord yet ? | 02:12 |
| StevenK | Nope | 02:12 |
| StevenK | lifeless: So I guess we need to plan to deploy auditor for staging/qas and then slap it into an RT. | 02:15 |
| lifeless | yes. | 02:15 |
| lifeless | this might be a good time to do the refactoring I blathered on about | 02:15 |
| StevenK | Oh? :-) | 02:16 |
| lifeless | voice? | 02:16 |
| StevenK | Skynet? Mumble? | 02:17 |
| lifeless | the robots are coming! | 02:17 |
| lifeless | (skype) | 02:19 |
| StevenK | Right, let me get that set up | 02:20 |
| StevenK | lifeless: Apparently, you're red | 02:29 |
| StevenK | lifeless: Firebug is making Firefox do the crash-restart-crash loop | 05:12 |
| nigelb | StevenK: use in-built dev tools | 05:15 |
| StevenK | Oh, is that what Mozilla is trying to tell me? | 05:15 |
| StevenK | And now it's lost my session details | 05:15 |
| StevenK | I guess it got too embarrased | 05:15 |
| nigelb | lol | 05:16 |
| StevenK | Maybe I'll just switch to Chrome | 05:16 |
| * lifeless thought firebug *was* the built in dev tool | 05:18 | |
| StevenK | Haha | 05:19 |
| nigelb | There's been built-in dev tools for ages in Firefox now. And it's been getting really good. | 05:19 |
| nigelb | Whoosh. Missed the irony. | 05:19 |
| micahg | StevenK: bug 1025011 | 05:34 |
| _mup_ | Bug #1025011: Firebug extension causes firefox to crash (can be triggered by opening HUD) <verification-done> <verification-needed> <Mozilla Firefox:Confirmed> <Global menubar extension:Fix Committed> <firefox (Ubuntu):Fix Released> <firefox (Ubuntu Natty):Fix Committed> <firefox (Ubuntu Oneiric):Fix Committed> <firefox (Ubuntu Precise):Fix Committed> <firefox (Ubuntu Quantal):Fix Released> < https://launchpad.net/bugs/1025011 > | 05:34 |
| StevenK | Handy | 05:35 |
| micahg | so basically, Chris fixed it, but the next firebug update discovered another latent bug in the code | 05:35 |
| StevenK | wgrant: I don't understand the remaining 5 failures. :-( | 05:36 |
| micahg | StevenK: so, either use 1.14.0 with Firefox 14 in the release pocket, 1.14.1 with firefox in -proposed, 1.14.2 and you're on your own | 05:36 |
| wgrant | StevenK: 'sup? | 05:36 |
| wgrant | StevenK: This is the testbrowser upgrade? | 05:37 |
| StevenK | micahg: Or switch to Chromium in anger. | 05:37 |
| StevenK | Which I did. | 05:37 |
| StevenK | wgrant: Yah. | 05:37 |
| micahg | StevenK: and be open to lots of CVEs, have fun :) | 05:37 |
| wgrant | StevenK: What are the failures? | 05:37 |
| StevenK | wgrant: http://pastebin.ubuntu.com/1144330/ | 05:37 |
| StevenK | I've fixed the third failure in xx-person-subscriptions.txt, but I'm not sure about the first two. | 05:38 |
| wgrant | StevenK: goBack | 05:38 |
| StevenK | wgrant: Which is only in two of them | 05:39 |
| wgrant | :( | 05:40 |
| wgrant | goForward? :) | 05:40 |
| StevenK | None of them :-P | 05:40 |
| wgrant | logging-in.txt is pretty obvious | 05:41 |
| lifeless | micahg: which code is at fault ? | 05:41 |
| micahg | lifeless: globalmenu-extension | 05:42 |
| wgrant | xx-person-subscriptions.txt is odd | 05:42 |
| StevenK | Hm, Chromium doesn't want / for search :-( | 05:42 |
| lifeless | micahg: ah well, we knew it was hairy. | 05:42 |
| micahg | that's the other option, disable the globalmenu :) | 05:42 |
| wgrant | StevenK: Oh | 05:42 |
| wgrant | StevenK: Try to think through the xx-person-subscriptions.txt failure | 05:42 |
| wgrant | The first one, that is | 05:43 |
| StevenK | wgrant: I'm still trying to work out why you say logging-in.txt is obvious | 05:43 |
| lifeless | wow | 05:43 |
| lifeless | postgresql schema patch downtime -> the dev wiki page on live patching is 5th in google. | 05:44 |
| wgrant | StevenK: It's not using normal browser methods | 05:44 |
| wgrant | StevenK: It uses some OpenID thing | 05:44 |
| wgrant | lifeless: Indeed, we seem to have #5 and #6, from a couple of hopefully unbiased browsers. | 05:45 |
| wgrant | StevenK: So, the first xx-person-subscriptions.txt failure is because it's now sending a sensible Referer | 05:46 |
| wgrant | StevenK: The view uses Referer to set cancel_url | 05:46 |
| wgrant | So it now ends up on the right page | 05:46 |
| wgrant | Not the one it expects. | 05:46 |
| StevenK | Which I thought I removed in anger | 05:46 |
| lifeless | http://postgresql.1045698.n5.nabble.com/ChronicDB-Live-database-schema-updates-with-zero-downtime-td1901036.html | 05:47 |
| lifeless | also lol - 'ChronicDB is currently a private technology' | 05:48 |
| lifeless | moving right along | 05:48 |
| lifeless | have we done a second schema patch without slony now ? | 05:48 |
| wgrant | lifeless: No | 05:48 |
| wgrant | lifeless: Hopefully Colin will have one for us tomorrow. | 05:48 |
| StevenK | wgrant: logging-in.txt is making use of testbrowser to do stuff, it just uses the extra methods to parse what came back | 05:50 |
| lifeless | anyone remember the statistic from flacoste about velocity improvement from FDT ? | 05:52 |
| wgrant | StevenK: It passes the URL into consumer.complete, which looks a bit sus to me. | 05:52 |
| StevenK | wgrant: It does? Where? | 06:03 |
| wgrant | StevenK: In complete_from_browser | 06:04 |
| StevenK | Ah | 06:05 |
| StevenK | wgrant: So I guess xx-person-subscriptions.txt is the test expecting behaviour which is now fixed | 06:08 |
| wgrant | StevenK: The first failure, yes. | 06:09 |
| wgrant | The others I haven't looked at. | 06:09 |
| StevenK | wgrant: How does goBack break the other two? | 06:19 |
| wgrant | StevenK: I don't know. | 06:20 |
| wgrant | I don't even know if it does. | 06:21 |
| wgrant | But it seems very likely. | 06:21 |
| * StevenK sigh | 06:21 | |
| StevenK | I broke buildbot | 06:21 |
| wgrant | That's not very nice of you. | 06:26 |
| wgrant | Oh | 06:26 |
| wgrant | I assumed that was local breakage | 06:26 |
| wgrant | My build just failed the same way | 06:26 |
| StevenK | I'm just about to land a testfix | 06:26 |
| StevenK | As soon as bzr push completes | 06:26 |
| wallyworld_ | StevenK: wgrant: either of you guys adding the new Embargoed information type to the enum? i'll do it if no-one else is | 06:36 |
| wgrant | I'm not. | 06:37 |
| wgrant | Not sure it's worth adding yet, but maybe :) | 06:38 |
| StevenK | I'm swearing at testbrowser and buildbot | 06:38 |
| wallyworld_ | i figured we'd need it done first so things could use it | 06:38 |
| wgrant | Well | 06:38 |
| wgrant | We should be sure it's going to work first | 06:38 |
| StevenK | We are still discussing it, so I'm not sure it's worth leaping yet | 06:39 |
| wgrant | I'm currently finishing off sharing policies for Proprietary. | 06:39 |
| wgrant | StevenK: Right. | 06:39 |
| wallyworld_ | ok, i'll hold off. i thought we had agreed to do it | 06:39 |
| StevenK | wallyworld_: Do you also do "Ready, fire, aim" ? | 06:39 |
| wallyworld_ | huh? | 06:39 |
| StevenK | As opposed to 'Ready, aim, fire' | 06:40 |
| wallyworld_ | i must be slow today, don't get the reference? | 06:40 |
| lifeless | its slightly whacky humour | 06:50 |
| lifeless | the instructions called out by WWI officers - ready (guns loaded etc), aim - aim at the folk running across no mans land, fire - pull the trigger. | 06:51 |
| lifeless | StevenK is suggesting that you are doing (firing) before aiming (finishing the discussion). | 06:51 |
| lifeless | Personally, I think its a little harsh. | 06:51 |
| wallyworld_ | especially since i thought we had converged on a solution, but anyway | 06:59 |
| wgrant | wallyworld_: We hopefully have, but eg. mrevell was still unclear about it on Friday | 07:01 |
| wgrant | And it probably needs to be confirmed with PES | 07:01 |
| wgrant | The solution evolved on the Friday call, and Curtis was away on his Friday, so it hasn't had much chance to settle. | 07:01 |
| lifeless | should I put my nose in a little? | 07:01 |
| wgrant | No. | 07:01 |
| wallyworld_ | if you want | 07:02 |
| wallyworld_ | wgrant: there was a card on the board in the next column, hence my thinking we had agreed to it also | 07:02 |
| wallyworld_ | if it's not final, we shouldn't put the card up yet :-) | 07:03 |
| wgrant | wallyworld_: Bah | 07:03 |
| wgrant | True | 07:03 |
| wgrant | I put that there :) | 07:03 |
| wgrant | It's agreed, but not final. | 07:03 |
| wallyworld_ | np, glad we could clarify | 07:03 |
| wgrant | And mrevell appears concerned | 07:03 |
| wallyworld_ | oh? is there an email i missed? | 07:04 |
| * wallyworld_ has to go to soccer, back later | 07:05 | |
| wgrant | Well, just the steps to sharing beta one. It seems nobody outside the team is clear on what's happening. | 07:06 |
| wgrant | we'll see over the next couple of days, I expect | 07:06 |
| * StevenK stabs Unity | 07:16 | |
| StevenK | Firefox crashes, and brings up a crash dialog, so you click Restart and then Unity loses track of the main Firefox window until you fiddle with the dock | 07:16 |
| adeuring | good morning | 07:23 |
| StevenK | lifeless: You missed a failure -- we tickled a bug in Slony when we dropped a column, so the sequence was killed and Slony got very unhappy with the world. | 07:40 |
| StevenK | lifeless: Unless that's what you meant with two tables at once? We didn't drop the tables, we dropped their id columns. | 07:41 |
| === almaisan-away is now known as al-maisan | ||
| wgrant | I believe that's the failure to which he referred in his reply | 07:46 |
| wgrant | Although misstating it, as you say. | 07:46 |
| lifeless | StevenK: bah, you are right. | 08:17 |
| StevenK | lifeless: Now you can edit your blog post and thank me. Or something. | 08:18 |
| wgrant | Oh, there's a blog post? | 08:24 |
| wgrant | Ah, there | 08:24 |
| czajkowski | where.. | 08:25 |
| wgrant | http://rbtcollins.wordpress.com/2012/08/13/minimising-downtime-for-schema-changes-with-postgresql/ | 08:25 |
| czajkowski | ahh | 08:25 |
| lifeless | StevenK: or I can let it stand wrongly vague :P | 08:54 |
| StevenK | lifeless: "Or something." | 08:54 |
| lifeless | :) | 08:54 |
| czajkowski | lifeless: StevenK wgrant anyone any thoughts on https://lists.launchpad.net/launchpad-dev/msg09565.html | 09:01 |
| StevenK | Yes. None are printable. | 09:05 |
| cjwatson | wgrant: Thanks. | 09:05 |
| lifeless | czajkowski: blueprints are for summit basically | 09:25 |
| lifeless | czajkowski: so 'just for summit' is sufficient as an answer | 09:26 |
| lifeless | czajkowski: though there may be a deeper question that isn't clear yet | 09:26 |
| lifeless | StevenK: wgrant: so we dropped the id column from one or two tables ? | 09:28 |
| czajkowski | lifeless: I suspect cjohnston is working on summit stuff and wants to make a change, but hasn't explained what besides wording | 09:28 |
| lifeless | czajkowski: I share your suspicion. | 09:32 |
| czajkowski | lifeless: which doesnt help get him an answer either :/ | 09:33 |
| lifeless | czajkowski: and thus noone has answered ;) | 09:33 |
| ev | Presumably I should be using ETags and gzip when communicating with Launchpad from another webservice, right? Anyone know if a thread-safe alternative to httplib2 for that? | 09:33 |
| lifeless | httplib2 is threadsafe with the patch jml did, we think. | 09:34 |
| ev | oh awesome | 09:34 |
| czajkowski | lifeless: true, I'm just following up on stuff from my week off | 09:34 |
| lifeless | s/thread/concurrency/ | 09:34 |
| jml | ISTR someone pushing for a release and getting it into 12.04 | 09:35 |
| cjwatson | I was asking for one | 09:36 |
| cjwatson | But wasn't that lazr.restfulclient not httplib2? | 09:36 |
| wgrant | lifeless: We dropped an ID column from two tables. | 09:39 |
| lifeless | wgrant: replacing it with some natural PK ? | 09:40 |
| lifeless | s/it/them/ | 09:40 |
| wgrant | lifeless: Right | 09:40 |
| wgrant | Dropping a serial column automatically drops the underlying sequence | 09:40 |
| wgrant | Slony automatically polls sequence values | 09:40 |
| wgrant | => slony broke | 09:40 |
| wgrant | The only ID columns we've dropped in recent history are BranchRevision.id and OAuthNonce.id | 09:41 |
| wgrant | And the latter wasn't replicated | 09:41 |
| wgrant | and I don't remember when we did BR.id | 09:41 |
| wgrant | So it's possible that this isn't a regression | 09:41 |
| lifeless | fark HUD. | 09:43 |
| lifeless | DIAF. | 09:43 |
| wgrant | What's it doing now? | 09:43 |
| lifeless | killing FF | 09:43 |
| wgrant | Ah | 09:44 |
| wgrant | Disable the globalmenu extension? :) | 09:44 |
| * cjwatson looks at database/schema/comments.sql and wonders how he's supposed to "keep [it] alphabetical by table" | 09:45 | |
| wgrant | lalalalal | 09:45 |
| cjwatson | Should the first part of my branch be to sort it? :-P | 09:45 |
| wgrant | Well | 09:45 |
| wgrant | comments.sql is sort of dead to us now | 09:45 |
| cjwatson | https://dev.launchpad.net/PolicyAndProcess/DatabaseSchemaChangesProcess | 09:45 |
| cjwatson | Just saying | 09:46 |
| wgrant | Whether it should continue to exist at all is not exactly clear | 09:46 |
| cjwatson | "If you have removed or renamed a table or column, update database/schema/comments.sql." | 09:46 |
| lifeless | so, comments.sql is no longer applied in production. | 09:46 |
| wgrant | Right, comments.sql needs updating in that case or make schema will fail | 09:46 |
| wgrant | It doesn't say anything about adding new ones :) | 09:46 |
| lifeless | We need to move: | 09:46 |
| lifeless | - comments.sql | 09:47 |
| lifeless | - fti | 09:47 |
| lifeless | - sampledata | 09:47 |
| cjwatson | wgrant: "Comments on new tables and columns need to be added to database/schema/comments.sql. " | 09:47 |
| lifeless | into the lazr.postgresql patch system | 09:47 |
| wgrant | Curses. | 09:47 |
| lifeless | and drop the LP one entirely. | 09:47 |
| lifeless | cjwatson: don't stress on the alphabetical, please do add comments until we transition. | 09:47 |
| cjwatson | In the short term should I just put COMMENT statements in the patch itself? | 09:47 |
| lifeless | no, comments.sql. | 09:48 |
| lifeless | it won't apply in prod, but we don't care. | 09:48 |
| wgrant | There was some discussion a while back about moving them to patches | 09:48 |
| wgrant | As we did with trusted.sql | 09:48 |
| wgrant | Have you dropped that idea? | 09:48 |
| lifeless | wgrant: not at all, just we haven't actually done it AFAICR, and unlike trusted.sql its not functional. | 09:49 |
| wgrant | Yeah | 09:50 |
| lifeless | StevenK: thanks for pointing that out. Updated. | 09:50 |
| mgz | what is this a symptom of does anyone know? can't get launchpad.dev to respond this morning... | 09:56 |
| mgz | 2012-08-13T09:55:34 INFO root Startup time: 9.164 sec real, 9.110 sec CPU | 09:56 |
| mgz | channel 3: open failed: connect failed: Connection refused | 09:56 |
| mgz | channel 4: open failed: connect failed: Connection refused | 09:56 |
| lifeless | could be rabbitmq not running ? | 09:57 |
| cjwatson | That's an error message from ssh | 09:57 |
| cjwatson | If that helps | 09:57 |
| mgz | ah, so I borked my ssh forwarding perhaps | 09:58 |
| mgz | will also poke the rabbit. | 09:58 |
| mgz | okay, so it seems nothing is actually listening on 8080, zope.server.http came up on 8085, not sure if that's normal, haven't got a log from when it was working earlier to compare against | 10:11 |
| mgz | ...or have I | 10:11 |
| mgz | hm, did that last time as well. | 10:12 |
| mgz | but 8080 is what used to work... | 10:12 |
| * mgz looks at apache setup | 10:14 | |
| wgrant | mgz: The normal launchpad.dev Apache config listens on 80 | 10:14 |
| wgrant | (and 443) | 10:15 |
| wgrant | 8080 is usually unused | 10:15 |
| mgz | well, apache is not running... >_< | 10:18 |
| mgz | what changed... | 10:18 |
| mgz | manually starting it and all is well | 10:19 |
| mgz | so close to not having to interveen, but need manual fixup too often, half the time it's me being dumb but this is too much of a pain | 10:20 |
| mgz | so, I think apache doesn't get added to the things that should be run on startup perhaps? install, use launchpad is fine, didn't come back after reboot... | 10:21 |
| cjwatson | lifeless: https://code.launchpad.net/~cjwatson/launchpad/queue-filter-source/+merge/119225 - I'd be happy to try running this on dogfood. Is there a sensible way to extract a compiled version of the query there (some kind of profile mode or something) or do I have to work it out by hand? | 10:23 |
| wgrant | cjwatson: bzr merge lp:~cjwatson/launchpad/queue-filter-source | 10:26 |
| wgrant | make initscript-stop initscript-start | 10:26 |
| wgrant | Browse :) | 10:26 |
| wgrant | Ah, but you won't get in-page query logs unless you're in ~launchpad... | 10:27 |
| cjwatson | And look at dogfood-nohup.out or something? | 10:27 |
| wgrant | You could change the feature flag to allow you too :) | 10:27 |
| cjwatson | Oh right. I could add myself to ~launchpad on DF :P | 10:27 |
| wgrant | The visible_render_time flag shows a partial query log at the end of the page | 10:27 |
| wgrant | Or that, yes | 10:27 |
| cjwatson | How about API queries? | 10:27 |
| wgrant | Good luck with that :) | 10:28 |
| wgrant | Can't even use ++oops++ with the API | 10:28 |
| wgrant | Perhaps use LP_DEBUG_SQL=1 bin/harness? | 10:28 |
| cjwatson | Actually I guess DistroSeries:+queue lets me do basically the same query, so not necessary in this case | 10:28 |
| wgrant | Yeah | 10:28 |
| wgrant | That's what I assumed you'd test | 10:28 |
| Ergo^ | morning | 10:39 |
| czajkowski | blue - jam jelmer mgz vila https://bugs.launchpad.net/launchpad/+bug/1035338 | 12:04 |
| _mup_ | Bug #1035338: An unexpected error has occurred while updating a Launchpad branch <Launchpad itself:New> < https://launchpad.net/bugs/1035338 > | 12:04 |
| mgz | just jam/mgz czajkowski :) | 12:05 |
| czajkowski | ah ok | 12:05 |
| czajkowski | thanks | 12:05 |
| mgz | czajkowski: that oops won't load for me, just spinns during lookup, but have responded on the bug | 12:16 |
| === al-maisan is now known as almaisan-away | ||
| Ergo^ | morning | 12:24 |
| cjwatson | Hmm. Upgrading dogfood says: | 12:43 |
| cjwatson | lazr.config.interfaces.ConfigErrors: ConfigErrors: database does not have a auth_master key. | 12:43 |
| cjwatson | database does not have a auth_slave key. | 12:43 |
| cjwatson | Something to do with r15782 I guess | 12:46 |
| cjwatson | ah, the dogfood config needs to be updated | 12:47 |
| * cjwatson will sort it out | 12:48 | |
| === benji changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: benji | Firefighting: - | Critical bugs: 4.0*10^2 | ||
| jam | mgz: I did eventually get the oops to load, though I did it by going to oops.canonical.com directly and then doing a search from there (still took a while) | 12:56 |
| jam | interestingly, the content there is an XMLRPC Fault that contains yet-another OOPS | 12:56 |
| jam | xmlrpclib.Fault: <Fault -1: 'OOPS-394216d625e87559cda9d8b92d70b90f'> | 12:56 |
| jam | look at that one: https://oops.canonical.com/?oopsid=OOPS-394216d625e87559cda9d8b92d70b90f | 12:56 |
| jam | It ends up as RequestExpired. | 12:56 |
| jam | I wonder if they hit downtime while he was trying to commit? | 12:57 |
| wgrant | jam: No, planned DB downtime does not result in timeouts. | 13:00 |
| jam | wgrant: even for bzr codehosting? | 13:00 |
| wgrant | The underlying OOPS (the RequestExpired) is from the appservers, not codehosting. | 13:01 |
| jam | this is a Request timeout in the Storm layer | 13:01 |
| wgrant | But yes, even for codehosting. | 13:01 |
| jam | now, it does seem to say that it was taking 7s to get a Feature flag looked up... | 13:01 |
| jam | which seems very odd | 13:01 |
| wgrant | Note also the 4s lookup for a person by ID | 13:02 |
| jam | yeah | 13:02 |
| wgrant | It's probably GIL contention or similar. | 13:02 |
| wgrant | The appservers are single-threaded, except not. | 13:02 |
| jam | Isn't that SQL time? | 13:02 |
| jam | Or the timing code has enough python in it to cause some time to be in python-land | 13:03 |
| wgrant | It's "SQL time" | 13:03 |
| wgrant | But measured by Python | 13:03 |
| wgrant | So if the interpreter doesn't run for 4s, it'll appear to have taken 4s longer. | 13:03 |
| wgrant | It's possible that it's connection latency or firewall breakage. | 13:03 |
| wgrant | But it's very similar to the behaviour we saw more frequently before we went to single-threaded* appservers | 13:03 |
| wgrant | (* each instance actually has two threads, one to serve webapp requests and the other to serve xmlrpc-private (this is xmlrpc-private), so there can still be contention) | 13:04 |
| wgrant | The only theory we have that does not involve persistent network flakiness is threading contention | 13:04 |
| wgrant | So threading contention is the going assumption. | 13:04 |
| wgrant | It's supported by the fact that we mostly see these on xmlrpc-private requests | 13:05 |
| wgrant | And xmlrpc-private requests are rarely CPU-intensive on the appserver. | 13:06 |
| wgrant | (so webapp requests have a smaller chance of being starved) | 13:06 |
| wgrant | Now | 13:06 |
| wgrant | 7s is pretty huge | 13:06 |
| wgrant | Bordering on implausibility, really | 13:06 |
| wgrant | But the 4s query afterwards means it wasn't just a momentary disruption | 13:07 |
| wgrant | We often just see the slow first query | 13:07 |
| cjwatson | benji: Could I have a review of https://code.launchpad.net/~cjwatson/launchpad/report-pcj-oops-2/+merge/119209 ? I'd like to unstick the chain of work that's part of | 13:23 |
| benji | cjwatson: sure, but I'm on an interview call at the moment; it may be an hour | 13:24 |
| cjwatson | OK, thanks - I probably need to head to a more congenial network environment anyway | 13:25 |
| benji | cjwatson: review done | 14:35 |
| rick_h_ | deryck: left the file as a .odg file and uploaded with images/set up. | 14:53 |
| rick_h_ | deryck: let me know if you don't see it in the shared U1 folder | 14:53 |
| deryck | rick_h_, ok, will check here shortly | 14:59 |
| cjwatson | benji: thanks | 15:11 |
| rick_h_ | congrats frankban | 15:12 |
| frankban | thanks rick_h_ | 15:17 |
| mgz | how do I set a feature flag to default to on? | 15:17 |
| mgz | doc says should always use "enabled", but the current state is that enabled should be True | 15:18 |
| sinzui | mgz: feature flags are not truly bools | 15:18 |
| sinzui | We set the scope to "default" and add the string "on" to indicate we want everyone to get the feature | 15:19 |
| mgz | but the codebase must have some idea of which ones are on at present | 15:19 |
| sinzui | mgz we remove "on" to disable it. Any string will evaluate to True in that position | 15:19 |
| mgz | or all tests, and the testing config, set flags as needed? | 15:19 |
| sinzui | sure, we have a page for that | 15:19 |
| sinzui | https://launchpad.net/+feature-rules | 15:20 |
| sinzui | mgz: tests must set flags to use them. They are off in the test suite | 15:20 |
| mgz | ...so landing this will inevitably change the current state till someone sets the new flag on production? | 15:21 |
| mgz | and everyone's local test setups will also change? | 15:22 |
| mgz | (not that anyone will mind, I'd think, in this case) | 15:22 |
| sinzui | mgz: no one setup changes with the addition of a flad, nor does production. That is why we know bugs.dynamic_bug_listings is not finished. I have to enable it to see in in dev, and it must be on in production to see it. People only see the new feature because we enable it for them, or we remove the flags from the code | 15:24 |
| mgz | okay, so it's a bit of a hack using a feature flag for this then, but I'll trust that it's the most sensible option | 15:25 |
| sinzui | mgz, So reading back to what you first asked...the answer is feature flags cannot be default on because by their nature, they are incomplete. | 15:25 |
| mgz | thanks for explaining the details for me sinzui :) | 15:26 |
| mgz | hm, seems it's not possible to do boolean logic in a tal expression | 15:39 |
| mgz | | relates to path lookup, not evaulation of the objects found | 15:40 |
| sinzui | mgz: we use tales adapters to create bools. We also use "|Nothing" to safely adapt to false when an exception is raised | 15:49 |
| sinzui | mgz: what path do you want to know is true or false? | 15:51 |
| mgz | ...darn disconnects >_< | 16:30 |
| mgz | sinzui: basically I want to change not:view/user into not:view/user||not:features/app.root_blog.enabled | 16:31 |
| cjwatson | use python:? | 16:31 |
| sinzui | No | 16:31 |
| mgz | I think the shortest path to that is adding an attribute to the python class that contains that combination | 16:31 |
| sinzui | We do not want logic in the templates. | 16:31 |
| mgz | python: is bad because it makes everything after it python | 16:32 |
| cjwatson | fair enough, I'll shut up :) | 16:32 |
| mgz | can't just use it to do the boolean logic correctly on path lookups | 16:32 |
| sinzui | mgz, move the logic into the view so that we can write a unit test | 16:32 |
| mgz | right, that's pretty much where I'd arrived at. the test I've written is just looking at the html output | 16:33 |
| sinzui | mgz: tales makes testing hard, trying to make it support logic ultimately leads to more hours spent trying to test it | 16:33 |
| mgz | is there somewhere else I can do this that doesn't involve the databasefunctionallayer? | 16:33 |
| sinzui | mgz: I use view = create_initialized_view() then test the bool value of view.show_root_blob | 16:34 |
| mgz | I'll grep for some examples, thanks | 16:35 |
| sinzui | mgz, given the logic you tried to write, I think you want to add tests to LaunchpadRootIndexViewTestCase | 16:36 |
| mgz | that's where I've got 'em | 16:36 |
| mgz | still painful for tdd, with multi-second setup time for the layers | 16:36 |
| sinzui | mgz, You can try to write the test on the FunctionalLayer, but that wont be must faster | 16:37 |
| sinzui | ./bin/test -vvc -t LaunchpadRootIndexViewTestCase lp.app.browser.tests.test_launchpadroot | 16:39 |
| sinzui | will be the fastest command | 16:39 |
| mgz | oo, and colourful. | 16:40 |
| mgz | I've been using -m... apparently that's the same as just giving an arg? | 16:41 |
| sinzui | mgz, gary_poster told me no, passing the module path as the last arg is different and faster | 16:41 |
| === skaet_ is now known as skaet | ||
| mgz | ehehe | 16:42 |
| === almaisan-away is now known as al-maisan | ||
| mgz | okay, this all looks workable | 16:51 |
| jml | sinzui: './bin/test -vvc lp.app.browser.tests.test_launchpadroot LaunchpadRootIndexViewTestCase' might be faster still | 17:07 |
| === deryck is now known as deryck[lunch] | ||
| sinzui | oh | 17:07 |
| sinzui | I look forward to faster tests | 17:07 |
| mgz | when layer setup takes nearly 10 seconds, it's hard to see a difference... | 17:08 |
| sinzui | mgz :( | 17:08 |
| mgz | is there any distinction between `with anonymous_logged_in() as user: view = create_initialized_view(..., principle=user)` and just `create_initialized_view(...)`? | 17:09 |
| sinzui | mgz yes :( | 17:09 |
| sinzui | barry wrote the helper to ignore the user we alreay placed in the interaction with login... | 17:09 |
| mgz | if I want to test what someone sees if they arrive at launchpad.net with no cookies, which do I use? | 17:10 |
| sinzui | principal is rarely needed though. Generally principal is only needed when we render the view and the page renders the "logged in as" portlet | 17:11 |
| mgz | hm. hard to tell what's needed and what's cargo culting when using other tests as templates. | 17:11 |
| mgz | just using the minimum that works is tempting, but sometimes that ends up asserting useless things. | 17:12 |
| sinzui | mgz, you need to construct the request manually I think. The helper accepts an optional request object (which you may have already setup for the login user. Otherwise, the help will create it's own user and request | 17:13 |
| sinzui | mgz, actually, the default request has no cookies, so you do not need to create it | 17:16 |
| sinzui | mgz, if the method you wrote is looking at the self.request, pass the logged in user at the principal | 17:17 |
| mgz | hm, nope, test method I'm working from just goes getUtility, makePerson, login_person, create_intialized_view, call view to get result | 17:21 |
| jcsackett | sinzui: free to chat? | 17:55 |
| sinzui | yes | 17:55 |
| jcsackett | excellent. | 17:55 |
| jcsackett | invite sent. | 17:56 |
| sinzui | phone is being odd | 17:58 |
| sinzui | It know I got the invite, but says I am not logged in. | 17:58 |
| sinzui | something needs a whack upside the head | 17:58 |
| sinzui | jcsackett: hold on a moment | 17:59 |
| sinzui | Google doubts that I exist | 18:00 |
| jcsackett | sinzui: sure. i've cancelled the hangout so i can resend whenever. | 18:00 |
| === deryck[lunch] is now known as deryck | ||
| lifeless | cjwatson: you can export LP_SQL_DEBUG (IIRC) to get queries logged to stdout, and then interactively fiddle around till you see the one yo want | 18:16 |
| lifeless | cjwatson: or you use ++oops++ if its a regular view to trigger an oops and get timing data; if you're in the right group (~launchpad) you'll get timing data on the initial queries in web views by default | 18:17 |
| rick_h_ | deryck: ping, how we doing? I'm coming up on EOD in 30 and wanted to check in | 18:38 |
| rick_h_ | benji: have a sec to look over https://code.launchpad.net/~rharding/launchpad/yuiv5/+merge/119406 sometime? | 18:39 |
| rick_h_ | lifeless: this is per our conversation, if you know of a better way to do it via makefile magic appreciate feedback/tweaks. ^^ | 18:39 |
| deryck | rick_h_, on call, just a minute sorry | 18:44 |
| rick_h_ | deryck: np, knew it would be tough to get time today. | 18:44 |
| lifeless | deryck: o/ Did I miss our call ? | 18:45 |
| lifeless | deryck: oh no, its later today. Cool. | 18:45 |
| === al-maisan is now known as almaisan-away | ||
| rick_h_ | lifeless: once I get code review/approved I'll run through ec2 and see what goes boom (hopefully nothing) | 18:56 |
| lifeless | rick_h_: so that would be now ;> | 18:56 |
| rick_h_ | lifeless: ah, missed you approved, just saw the comment | 18:56 |
| rick_h_ | sinzui: ping, UI question for you. | 18:58 |
| sinzui | hi rick_h_ | 18:58 |
| rick_h_ | sinzui: just used the updated bug linking picker and the difference struck me a bit and wondered what you thought | 18:59 |
| rick_h_ | most pickers have always been a find, click on it to select experience | 18:59 |
| rick_h_ | when I just did that I ended up with my bug opened in a new tab, had to go back and look and notice a new "Link" button | 18:59 |
| sinzui | yes, that is odd | 18:59 |
| rick_h_ | twisted me up, intentional? | 18:59 |
| rick_h_ | or should I file a bug on the updated UI? | 18:59 |
| sinzui | wallyworld_: has been migrating the old widget to act like a picker, then actually be a picker | 19:00 |
| rick_h_ | yea, why I wasn't sure what discussions might have gone on before I declare it a 'bug' | 19:00 |
| sinzui | I think the selecting the item as you suggest is correct | 19:00 |
| sinzui | rick_h_: I agree we want to fix the behaviour | 19:01 |
| rick_h_ | sinzui: ok, will file a bug and try to ping wallyworld_ on it in case it's just a staged update/etc perhaps. | 19:01 |
| sinzui | rick_h_: I think that was planned for actual searching...bug I have also not committed to searching since that is definitely beyond our need to have the choice secure | 19:02 |
| sinzui | thanks rick_h_ | 19:02 |
| rick_h_ | sinzui: sorry, not following on searching/choice secure? | 19:02 |
| sinzui | There is a request to let you search for the bug instead of enter a number | 19:03 |
| rick_h_ | sinzui: ah gotcha. | 19:03 |
| sinzui | We are only changing the feature so users do not accidentally link the wrong bug. | 19:04 |
| rick_h_ | ic, so I can understand the desire for a way to say "search bugs for something like this" and then want to open and make sure it's the bug you're thinking. | 19:04 |
| deryck | lifeless, yeah, I've got our call scheduled in about 2 hours. Still good for you? | 19:10 |
| lifeless | yup | 19:12 |
| cjohnston | deryck, sinzui, gary_poster, lifeless... Could you guys take a look at https://lists.launchpad.net/launchpad-dev/msg09569.html please and provide some feedback? I'm trying to make the interaction and expectations for the user more clear between Summit and LP. | 19:14 |
| deryck | hi cjohnston. I saw it and marked it to reply. But was hoping lifeless or flacoste would reply first. :) | 19:16 |
| cjohnston | lol | 19:16 |
| === almaisan-away is now known as al-maisan | ||
| deryck | cjohnston, quick look at code and I don't see any use for us. It's just a boolean flag basically, and likely only used by the summit system. | 19:19 |
| cjohnston | That's what I suspect, I just want to verify first. :-) | 19:20 |
| lifeless | cjohnston: it was added to let the predecessor to summit be told to not accept conflicts with other sessions for that (session,person) | 19:20 |
| === al-maisan is now known as almaisan-away | ||
| cjohnston | So that also sounds like there shouldn't be anything that would block me from making text changes. | 19:22 |
| deryck | I think you're fine. It's the sort of special casing we try to avoid these days, but since it's only the summit app using it anyway, I don't see the harm. | 19:23 |
| deryck | lifeless, do you feel strongly about it? | 19:24 |
| lifeless | about what? | 19:24 |
| lifeless | I don't know what cjohnston plans to do :) | 19:24 |
| gary_poster | the text change that cjohnston wants to make. | 19:24 |
| cjohnston | Just changing the text to better represent how Summit uses it | 19:24 |
| gary_poster | "I would like to change | 19:24 |
| gary_poster | the wording for the Participation Essential check box to something that | 19:24 |
| gary_poster | better explains a "very interested in this topic" instead of saying that | 19:24 |
| gary_poster | someone is essential for this topic." | 19:24 |
| lifeless | ah | 19:25 |
| lifeless | so AIUI that conflicts with how Canonical /uses/ it. | 19:25 |
| lifeless | If you're changing how summit uses it, that will need somewhat wider discussion - Launchpad doesn't care, but UDS / ODS / Linaro Connect organisers may. | 19:26 |
| deryck | I believe cjohnston is saying Canonical is changing how we use it. | 19:26 |
| cjohnston | How does Canonical use it? or does 'Canonical' mean UDS? | 19:26 |
| czajkowski | lifeless: cjohnston is developing for linaro/uds he is one of the developers on summit | 19:27 |
| lifeless | czajkowski: I know cjohnston :P | 19:27 |
| lifeless | cjohnston: bit of column A, bit of column B. | 19:27 |
| lifeless | cjohnston: its used as I said - to guarantee that if person A is so listed for session S, that they won't have any conflict with any other session for which they are also listed as essential. | 19:28 |
| czajkowski | lifeless: :) | 19:28 |
| cjohnston | lifeless: but only with Summit, nothing else, correct? | 19:28 |
| lifeless | cjohnston: thats then used to arrange private meetings, to arrange topic thought leaders for particular sessions etc. | 19:28 |
| lifeless | cjohnston: yes, LP does not care about this flag. We would happily delete it entirely. | 19:28 |
| cjohnston | I actually am not opposed to that and just having it all inside of Summit ;-) | 19:29 |
| flacoste | cjohnston, lifeless: +1 | 19:29 |
| * cjohnston wants to remove the LP requirement from Summit and just require SSO | 19:29 | |
| cjohnston | We actually could remove the LP requirement in probably 2 weeks, but there is alot of fight from some people in Canonical for that | 19:30 |
| lifeless | cjohnston: what are their concerns? | 19:30 |
| cjohnston | lifeless: because blueprints are such an integral part of how things are done, they want to continue to use blueprints to create meetings instead of creating meetings in Summit and then creating a blueprint as needed | 19:31 |
| lifeless | why not have summit create the bp for them ? | 19:34 |
| cjohnston | is there an API to allow that? | 19:34 |
| lifeless | if there isn't there can be | 19:36 |
| cjohnston | I *thought* the last time that it was asked there wasn't, but I'm not positive.. but I'd be more than happy to use that if it was created. I don't have time to do the work tho | 19:36 |
| cjohnston | I could make it work on Summit tho | 19:37 |
| lifeless | cjohnston: it's not a lot of work to do. | 19:42 |
| lifeless | cjohnston: but the LP team is equally flat out; I suggest doing it yourself will avoid handofs and queueing, so its much better to do it than not to. | 19:43 |
| cjohnston | ya.. one day someone will add a few more hours to the day, then we can all do things to catch up | 19:43 |
| lifeless | cjohnston: mmm, what I mean is, if you're estimating 2 weeks to do this thing, and you can find the time to do that, your estimate is low because of the desire to use blueprints being unsatisfied. | 19:45 |
| lifeless | cjohnston: you need to allow (say) 2 days to add the API on the LP end to your estimate of the work involved. | 19:45 |
| lifeless | cjohnston: if that changes it from 'can do' to 'can't do' - fine. But its not a separate bit of work that can be ignored. | 19:45 |
| cjohnston | right... I could remove the LP requirement in 2 weeks... but yes, to make Summit create BPs it would take more time. | 19:46 |
| lifeless | flacoste: shall we ? | 19:52 |
| === RoelV is now known as Roel|bbs | ||
| === Roel|bbs is now known as Roel | ||
| deryck | lifeless, hey. Shall I start a hangout? | 21:00 |
| lifeless | sure, or skype - eithe ris good | 21:03 |
| deryck | lifeless, use: http://tinyurl.com/orange-standup | 21:06 |
| deryck | I invited too | 21:06 |
| === benji changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: - | Firefighting: - | Critical bugs: 4.0*10^2 | ||
| === Ursinha` is now known as Ursinha | ||
| wallyworld_ | rick_h_: the new bug picker behaviour is currently "as designed". the bug link is blue (meaning a new page is opened) rather than green and there's also a "new window" icon, so it behaves like the regular picker in that sense if you were to open the details expander and click the blue person link | 22:04 |
| lifeless | gary_poster: thanks for the extra detail before, I had not see cjohnston's reply to the thread. | 22:09 |
| cjohnston | :-) | 22:10 |
| rick_h_droid | wallyworld ok but do we have any other pickers working like that? | 22:26 |
| rick_h_droid | if it's not a new inconsistency then cool but it struck me as something I'd not hit befire | 22:26 |
| rick_h_droid | bah | 22:26 |
| wallyworld_ | rick_h_: no other picker only presents a single result. but the person picker has a blue "new window" link in each result | 22:26 |
| rick_h_droid | right but to pick a person I click on the results not the submit button right? | 22:27 |
| wallyworld_ | rick_h_: it serves its purpose for disclosure, which is to allow to user a better chance of not accidentally choosing the wrong bug. any other work will have to be part of bug linking if we get to do that at some stage | 22:28 |
| wallyworld_ | rick_h_: yes, for a person, you click the person. but here there is only one result so it's not a list as such | 22:28 |
| rick_h_droid | ok, well that was part of my asking. to understand the reasoning | 22:28 |
| wallyworld_ | it's more a "did you really mean this one" type scenario | 22:28 |
| wallyworld_ | rick_h_droid: i understand the question, it's perfectly reasonable | 22:29 |
| rick_h_droid | I just noticed a new 'interaction' unable and the UX side of me went off | 22:29 |
| wallyworld_ | scope and time constraints prevent it being made "perfect" up front | 22:29 |
| rick_h_droid | np cool. thanks for the background | 22:30 |
| wallyworld_ | rick_h_droid: that's ok, i also share the concern about inconsistency, but we are unable to address it right now | 22:30 |
| rick_h_droid | ok maybe I'll get time to have some you I have fun during our feature work | 22:31 |
| rick_h_droid | ui that is | 22:32 |
| wallyworld_ | maybe :-) | 22:32 |
| rick_h_droid | Don't hold my breath you're saying huh | 22:32 |
| wallyworld_ | one never knows how these things will play out; best laid plans and all that :-) | 22:33 |
| wallyworld_ | wgrant: any reason distros don't have bug/branch sharing policies? | 23:36 |
| StevenK | wallyworld_: http://pastebin.ubuntu.com/1145896/ | 23:37 |
| wgrant | wallyworld_: They should eventually, but they don't have BVPs/private_bugs at present, so it's not important for the migration or clear exactly how it would work. | 23:38 |
| wgrant | The UI will probably be identical. | 23:38 |
| wallyworld_ | wgrant: cool, just wanted to confirm before i update the ui | 23:38 |
| wgrant | Yup | 23:39 |
| wallyworld_ | StevenK: looks ok | 23:39 |
| StevenK | wallyworld_: Yes, reason I'm asking you is the comment and other ff tests | 23:40 |
| wallyworld_ | StevenK: i don't think the doc tests check the include_description parameter | 23:41 |
| wallyworld_ | the doc tests probably should be migrated to join the other unit tests at some point | 23:42 |
| StevenK | Right, I'm wondering if I care ... | 23:42 |
| wallyworld_ | always good to delete doc tests :-) | 23:44 |
| StevenK | wallyworld_: I can't see ChoiceEdit in lazr-js-widgets.txt | 23:47 |
| wallyworld_ | i think it's the vocab, let me check | 23:47 |
| wallyworld_ | StevenK: look for EnumChoiceWidget | 23:48 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!