| BradB | BACK! | 12:05 |
|---|---|---|
| BradB | sabdfl: here's the problem: i'm lazy. i want one screen on which to see everything. | 12:06 |
| BradB | sabdfl: forcing a user to visit two different screens "the bugs" is too much. | 12:07 |
| sabdfl | my report put it all on one screen | 12:07 |
| sabdfl | just in four sections | 12:07 |
| sabdfl | upstream, directly assigned | 12:07 |
| sabdfl | package, directly assigned | 12:07 |
| sabdfl | upstream, maintainer | 12:07 |
| sabdfl | package, maintainer | 12:07 |
| sabdfl | but you made it go away :-/ | 12:08 |
| BradB | sabdfl: that's a heck of a lot to think about. i just want one thing to look at. | 12:08 |
| sabdfl | BradB: it works well actually | 12:08 |
| BradB | sabdfl: and i can't say that four different things to batch is much easier to solve than the problem at hand :) | 12:08 |
| sabdfl | you don't see sections that don't apply | 12:08 |
| sabdfl | i spent a lot of time beating up on myself to try to consolidate these assignments into a single report | 12:09 |
| sabdfl | and failed | 12:09 |
| sabdfl | the reality is, we wear different hats in the FLOSS world | 12:09 |
| BradB | i succeeded, but it's just too slow | 12:09 |
| sabdfl | and malone is modeling different hats | 12:09 |
| sabdfl | so, let's just get it up and running, perhaps somewhat fragmented | 12:10 |
| sabdfl | there are four different groups? show four separately | 12:10 |
| sabdfl | then when we have real users we can revisit that problem | 12:10 |
| BradB | sabdfl: to be honest, i think it'll be (much) easier for me to solve the problem at hand, it would have just taken 15 minutes instead of 2 hours, had their been one thing in the DB i can iterate over to deal with one conceptual entity. | 12:11 |
| sabdfl | maybe | 12:12 |
| sabdfl | we split it up because having one conceptual entity was breaking other things | 12:12 |
| sabdfl | and i didn't want to use postgres inheritance | 12:12 |
| sabdfl | time for me to crash a little, be fresh for the arch guys tomorrow | 12:13 |
| BradB | sabdfl: i haven't heard anyone complain about the bug listing in malone. i think it's great (which isn't to say it's perfect, but rather to say that it's got the right ideas) | 12:13 |
| sabdfl | BradB: there's room for different approaches | 12:13 |
| sabdfl | we are definitely going to need a complex search page for people to make up fun queries and email them around | 12:14 |
| sabdfl | or save as personal queries | 12:14 |
| sabdfl | BUT there is also room to have short, simple, focused context-aware listings | 12:14 |
| BradB | sabdfl: sure...i think having an ultra-super-mega search page is worth creating a separate page for | 12:14 |
| sabdfl | "the bugs on this package" | 12:14 |
| sabdfl | bradb: yes, it is | 12:14 |
| sabdfl | but you keep taking away my simpler things in favour of the mega search page | 12:14 |
| BradB | sabdfl: but, really, the simple searches of which you speak are just links into what is the current bug listing | 12:14 |
| sabdfl | erm... no they are not | 12:15 |
| BradB | sabdfl: and they can all be really, really easily done with code that's already written | 12:15 |
| sabdfl | they are context-aware bug listings | 12:15 |
| BradB | sabdfl: which are context-aware? | 12:15 |
| sabdfl | the simple ones | 12:15 |
| sabdfl | they know which distro, and package you are interested in | 12:15 |
| sabdfl | so they just show you that stuff | 12:15 |
| sabdfl | without knobs and dials to tweak them | 12:15 |
| sabdfl | it's gnome vs kde | 12:15 |
| sabdfl | i understand you want the kde approach, i want the gnome approach, and there's room for them both | 12:16 |
| sabdfl | what i'd rather focus on is workflow stuff | 12:16 |
| sabdfl | mark a bug upstream | 12:16 |
| BradB | we're debating something here that nobody has complained about. | 12:16 |
| sabdfl | remove a bug assignment | 12:16 |
| sabdfl | nobody is USING it | 12:16 |
| BradB | the dogfooders | 12:16 |
| sabdfl | and right now we have a lot of little bits to do | 12:16 |
| sabdfl | i'd rather we worked on the selectors, and the little workflow elements | 12:17 |
| BradB | yes | 12:17 |
| sabdfl | some of the things require you to know the datamodel | 12:17 |
| sabdfl | they should have direct answers - how do you reassign a bug? | 12:17 |
| BradB | "little workflow elements" are a huge, as-yet-unimplemented part of malone :) | 12:17 |
| sabdfl | in practice, you edit the assignment | 12:17 |
| sabdfl | but there should be a "reassign this" sort of link | 12:18 |
| sabdfl | at the moment, it's just auto-generated widgets on the underlying tables | 12:18 |
| sabdfl | we need to get it more process oriented | 12:18 |
| sabdfl | so please dont bang hours on a report | 12:18 |
| sabdfl | not just yet | 12:18 |
| BradB | my next merge will show # bugs, give next and previous links on the nav, and, hopefully be relatively fast for 10,000 bugs | 12:19 |
| sabdfl | cool | 12:19 |
| BradB | it's the last one that's got me tripped up | 12:19 |
| BradB | but anyway, i'll get it working | 12:19 |
| sabdfl | are you starting to add indexes for that performance, or is that without indexes? | 12:19 |
| BradB | sabdfl: no indexes yet. i've got some kinks to iron out. | 12:19 |
| BradB | the slowness that remains may be at the db level, i'm not sure | 12:20 |
| sabdfl | i'm really happy with the work you are doing | 12:21 |
| BradB | thanks | 12:21 |
| sabdfl | during es-conf we'll bring on-stream the debbugs sync engine | 12:22 |
| sabdfl | should really rock | 12:22 |
| sabdfl | you'll be able to surf debbugs in malone | 12:22 |
| sabdfl | updated hourly | 12:22 |
| BradB | sweet | 12:22 |
| sabdfl | night all | 12:23 |
| BradB | see ya tomorrow | 12:23 |
| sabdfl | what's the trick to running *just* the page tests? | 12:43 |
| SteveA | python test.py -f canonical.launchpad | 12:43 |
| sabdfl | i'm still trying to go to bed | 12:43 |
| SteveA | that runs the page tests + a couple other functional testes | 12:43 |
| SteveA | um, tests | 12:43 |
| sabdfl | thanks SteveA | 12:43 |
| SteveA | I hope we all have functional testes | 12:43 |
| sabdfl | and that's faster is it? | 12:43 |
| SteveA | than running make check? yes | 12:43 |
| BradB | python test.py -vvf is a good way of seeing what's going on | 12:47 |
| BradB | and, unfortunately, python test.py -vvf --test "20-some-pt" doesn't reset the db properly currently | 12:47 |
| dilys | Merge to rocketfuel@canonical.com/launchpad--devel--0: added bug # count info and next/prev URLs to batching (patch-845) | 12:50 |
| BradB | SteveA: here's a wild idea: i want to be able to profile how long some tal statements are taking to run. can i do that? | 12:51 |
| BradB | i'm thinking the bottleneck in the 10,000-bugs handling code may be in the TAL itself. hitting the db is murder. | 12:52 |
| Kinnison | kiko: yes? | 12:54 |
| kiko | Kinnison, you rock? :) | 12:57 |
| kiko | I need to run, though! | 12:57 |
| BradB | SteveA: ah, i mentioned to stub yesterday that the new bug may indeed have been to do with the internals of publishing having changed + our custom publisher | 12:57 |
| SteveA | yes, I saw | 12:57 |
| SteveA | I saw from the traceback that it was something to do with layers and view | 12:57 |
| SteveA | but it has taken a while to track down exactly what it is | 12:58 |
| BradB | indeed, that was a tough one :) | 12:58 |
| BradB | glad to hear you've found it | 12:58 |
| dilys | Merge to rocketfuel@canonical.com/launchpad--devel--0: prepare for doap status fields (patch-846) | 01:00 |
| SteveA | BradB: might have a problem though -- I need to think about how to upgrade launchpad so that it will work with either current zope or new zope | 01:06 |
| SteveA | think I can do it with an import trick | 01:07 |
| BradB | hm, i'd like to know more about that, but i have to leave right now unfortunately. i'll catch up with you on the upgrade/backwards compatibility tomorrow(ish...i know you're off to london.) | 01:11 |
| BradB | later all | 01:11 |
| === BradB is now known as BradB|away | ||
| SteveA | BradB|away: I'll be checking in changes soon that will allow lp to work with old and new zope | 01:11 |
| SteveA | yay! it works | 01:11 |
| BradB|away | wow, nice work SteveA | 01:13 |
| SteveA | I'm about to commit it | 01:13 |
| === BradB|away heads off to catch the metro | ||
| dilys | Merge to rocketfuel@canonical.com/launchpad--devel--0: Made launchpad forward-compatible with latest zope3 code (patch-847) | 01:25 |
| SteveA | thanks dilys | 01:26 |
| === SteveA goes to sleep | ||
| Kinnison | Night all | 01:35 |
| === stub [~stub@dsl-246.248.240.220.dsl.comindico.com.au] has joined #launchpad | ||
| stub | lifeless: ping | 03:34 |
| === stub [~stub@dsl-246.248.240.220.dsl.comindico.com.au] has joined #launchpad | ||
| dilys | Merge to rocketfuel@canonical.com/launchpad--devel--0: Sampledata documentation additions and clarifications (patch-848) | 05:58 |
| dilys | New Malone bug #74: "Remove do-not-use-info-imports project", submitted by Stuart Bishop | 07:53 |
| dilys | https://launchpad.ubuntu.com/malone/bugs/74 | 07:53 |
| dilys | New Malone bug #75: "Adding bug takes you to the wrong screen", submitted by Stuart Bishop | 07:55 |
| dilys | https://launchpad.ubuntu.com/malone/bugs/75 | 07:55 |
| lifeless | stub: pong | 09:13 |
| stub | lifeless: I wanted to confirm an arch process regarding branches. If a developer working on launchpad--devel--0 creates a branch using 'baz branch launchpad--mybranch--0', hacks away and commits, can PQM be told to merge in changed directly from launchpad--mybranch--0 into rocketfuel@canonical.com/launchpad--devel--0 ? | 09:15 |
| stub | This is regarding database changes that need to be committed at the same time as code and test updates, so ideally I could checkout someones branch, verify and issue the PQM request. | 09:16 |
| lifeless | fully qualify those branches, and I'll be able to answer | 09:16 |
| stub | lifeless: I wanted to confirm an arch process regarding branches. If a developer working on me@canonical.com/launchpad--devel--0 creates a branch using 'baz branch me@canonical.com/launchpad--mybranch--0', hacks away and commits, can PQM be told to merge in changed directly from me@canonical.com/launchpad--mybranch--0 into rocketfuel@canonical.com/launchpad--devel--0 | 09:17 |
| lifeless | no. | 09:17 |
| lifeless | it may work, some of the time, but its not a star. | 09:17 |
| lifeless | so, it will generate spurious conflicts if the timing is wrong. | 09:17 |
| lifeless | the developer can go baz switch rocketfuel..devel--0; baz branch me...devel--0; baz commit; submit-arch-merge | 09:18 |
| stub | ok. I'll need to come up with a better process. | 09:18 |
| lifeless | so whats the use case ? | 09:19 |
| stub | A launchpad developer is happily hacking away and realize they need a database schema update done. Unfortunately if that schema update cannot be made immediately by me because it would cause breakage and tests to fail. So instead the patch needs to be prepared and committed at the same time as their code changes. | 09:20 |
| === stub wants baz triangle-merge | ||
| lifeless | so, what they need to do is not commit those changes to their main branch. | 09:21 |
| lifeless | hmm | 09:22 |
| lifeless | ok, this will work. | 09:22 |
| lifeless | 1) branch me..devel to me..d-feature | 09:22 |
| lifeless | 2) hack and commit there unti the db stuff is done. | 09:23 |
| lifeless | 3) merge that back to me..devel | 09:23 |
| lifeless | 4) future work there. MUST NOT merge to rf at this point. | 09:23 |
| lifeless | 5) you verify and then merge me..d-feature to rf. | 09:23 |
| lifeless | 5) they merge the lsat stuff from d-feature to me..devel | 09:23 |
| lifeless | oops, missed a step. | 09:24 |
| lifeless | nope, won't. garh. | 09:24 |
| lifeless | yes, you need what we're talking about here with baz and graph merges. sory. | 09:24 |
| stub | We are coping so far. I just look at the patch and say 'ok - commit it as patch-foo.sql' | 09:25 |
| lifeless | yeah. | 09:25 |
| stub | This actually points out a flaw in the multiple trees vs. single tree project arrangement. If a project is made out of 'web--devel--0' and 'backend--devel--0', and there is an interface change in 'backend-devel--0', then a commit would need to be made simultaneously to both trees. | 09:30 |
| lifeless | the spec for that is designed in tla already, and pqm can be easily taught that too. | 09:31 |
| sabdfl | morning all | 09:34 |
| stub | yo | 09:46 |
| SteveA | stub: did you ask lifeless about getting Zope3 into the supermirror? | 09:55 |
| stub | Nope | 09:55 |
| sabdfl | stub: pending/mark-bugtracker-naming.sql is ready from my side | 09:55 |
| stub | lifeless: put Zope3 into the supermirror! | 09:55 |
| stub | :) | 09:55 |
| sabdfl | that's *my* kind of asking ;-) | 09:55 |
| SteveA | our source will now work with the latest zope3 code | 09:56 |
| sabdfl | stub: regarding pending/mark-doap-status.sql i'm not sure that "status" is the right column name | 09:56 |
| sabdfl | i really want to use that to describe whether or not it's been reviewed, and if so whether its active or not | 09:56 |
| sabdfl | this will allow me to generate reports of new ones, and have an admin team go through them and clean out the ones that are pure nonsense | 09:57 |
| sabdfl | also, edit and neaten the descriptions of the projects / products | 09:57 |
| SteveA | "status" is one of those "last resort" names for variables and columns | 09:58 |
| sabdfl | agreed | 09:58 |
| sabdfl | "reviewed"? | 09:58 |
| SteveA | there is almost always a better name, but often it is cumbersome, or hard to think og | 09:58 |
| sabdfl | reviewstate? | 09:58 |
| sabdfl | speak now or forever hold... | 09:59 |
| stub | I havn't looked at the patch yet - just finalizing a commit | 09:59 |
| sabdfl | bugtracker-name isn't urgent, it's behind the scenes and can go whenever you like | 10:00 |
| sabdfl | this is the doap-status pending patch that i need for work this morning | 10:01 |
| stub | I think status is fine, because you are using it to describe a linear workflow (new, reviewed, active). | 10:01 |
| stub | (Unless it can be active without having been reviewed) | 10:02 |
| sabdfl | it will be active without review... | 10:02 |
| sabdfl | NEW and ACTIVE we should treat the same, otherwise people will fel they have to wait for us all the time | 10:02 |
| sabdfl | it's just our way of knowing which one wes we have looked at and which we haven't | 10:02 |
| stub | So we should have a 'reviewed' boolean field (?), because it is indicating an independant binary state | 10:03 |
| stub | And an 'active' one | 10:04 |
| stub | Unless we are planning on having more values than just yes/no | 10:05 |
| sabdfl | you;re right | 10:05 |
| sabdfl | i was hoping to keep it to a single field but you're right | 10:05 |
| sabdfl | let me restructure the patch on that basis | 10:06 |
| === lulu [~lu@host217-37-231-28.in-addr.btopenworld.com] has joined #launchpad | ||
| sabdfl | stub: dilys will announce the merge shortly | 10:16 |
| sabdfl | could you have a look at that and, if it's good, move it to a patch- during the day? | 10:17 |
| stub | night ;) | 10:17 |
| stub | sure | 10:18 |
| stub | I think your patch is fighting with my patch for pqm time, so I can't merge just yet ;) | 10:18 |
| sabdfl | right | 10:19 |
| sabdfl | your timezone adjustment to spain should be easy... you're there already! | 10:19 |
| Kinnison | Morning | 10:20 |
| sabdfl | hey Kinnison | 10:20 |
| stub | lifeless: pqm dead I think | 10:20 |
| Kinnison | hi sabdfl | 10:20 |
| === carlos [~carlos@69.Red-80-33-181.pooles.rima-tde.net] has joined #launchpad | ||
| sabdfl | stub: doh, small mistake in that patch, will send in a new merge | 11:21 |
| === cprov [~cprov@200.158.100.251] has joined #launchpad | ||
| Kinnison | Morning cprov | 11:29 |
| cprov | Kinnison: morning, how was yesterday ? I had an unexpected travel to So Paulo. let me know what you've done and what I can do to help you . | 11:38 |
| Kinnison | cprov: I've been concentrating on gina as you may have seen from the activity list :-) | 11:42 |
| cprov | Kinnison: I've just read you comments/activities, I'll be working on Librarian Wrapper Unittest for today, is it ok for you ? | 11:45 |
| dilys | Merge to rocketfuel@canonical.com/launchpad--devel--0: corrected doap status patch (patch-849) | 11:46 |
| sabdfl | stub: thar she blows | 11:52 |
| Kinnison | cprov: perfect | 11:58 |
| Kinnison | does stub ever sleep? | 11:58 |
| === stub snores loudly | ||
| sabdfl | SteveA: i have moments of exhiliration with z3 | 12:10 |
| sabdfl | no idea how to spell that | 12:10 |
| Kinnison | +++ Whispered to GoogleBot: 'spell exhiliration' | 12:12 |
| Kinnison | GoogleBot >Perhaps you meant 'exhilaration'? | 12:12 |
| Kinnison | there you go ;-) | 12:12 |
| SteveA | jim has started working on a "dead simple" version of zope3. well, not really a version. a very minimal pythonic thing, with no zcml, not necessarily page templates. the kind of thing you'd use for ship-it or supermirror. | 12:13 |
| SteveA | a sort of no lerning curve thing | 12:14 |
| sabdfl | when we get a browser:form directive would you point me at the docs for it? | 12:17 |
| SteveA | I'll be able to point you at the docs for it before we get the directive. | 12:17 |
| dilys | Merge to rocketfuel@canonical.com/launchpad--devel--0: More popups - Person and BinaryPackageName (patch-850) | 12:24 |
| === stub hands pqm a banana | ||
| === SteveA [~steve@adsl-213-190-44-43.takas.lt] has joined #launchpad | ||
| SteveA | x crashed | 01:03 |
| === debonzi [~debonzi@200.158.100.251] has joined #launchpad | ||
| === salgado [~salgado@200-206-134-238.async.com.br] has joined #launchpad | ||
| === SteveA -> plane | ||
| sabdfl | hi salgado | 01:53 |
| sabdfl | how's the karma chameleon coming along | 01:53 |
| salgado | sabdfl, hello. I'm finishing the move of the people bits to foaf, and I'll start on the karma tonight. | 01:55 |
| sabdfl | cool enough | 01:56 |
| salgado | sabdfl, I was thinking about the karma yesterday, and I discussed with kiko if there would be any kind of depreciation of the cached value? | 01:56 |
| sabdfl | depreciation? you mean, it declines over time? | 01:56 |
| salgado | yes | 01:56 |
| sabdfl | or deprecation - we prefer not to use the field? | 01:56 |
| salgado | the former | 01:57 |
| sabdfl | ok | 01:57 |
| sabdfl | kiko and i discussed a karmaactivity table, where you would store a list of the karma-earning actions a person had taken | 01:57 |
| sabdfl | so each time the person does something karma-worthy, we throw a row in the table to reflect it | 01:57 |
| sabdfl | it would include a datecreated | 01:57 |
| sabdfl | and the Person.karma value would be calculated from that table | 01:58 |
| sabdfl | and yes, i think it makes sense to calculate it over the past month only | 01:58 |
| sabdfl | or, if you want to be fancy, give actions in the last month full weight, the month before that half weight, and before that one third weight | 01:58 |
| sabdfl | for the moment, let's just get the hooks in place to put rows in the table and have a very simple aggregation formula | 01:59 |
| sabdfl | we can tweak it once we have richer data to work with | 01:59 |
| salgado | ok, but then we'll have to calculate Person.karma periodicaly (apart from updating it everytime someone calls Person.assing_karma()), right? | 02:00 |
| salgado | I was thinking about a daily (or weekly or montlhy) depreciation, to avoid having to recalculate the Person.karma. | 02:02 |
| === Kinnison asks gina nicely if she'd mind importing d-i too now | ||
| salgado | sabdfl, ? | 02:25 |
| sabdfl | yes? | 02:25 |
| sabdfl | salgado: let's get the core framework working first | 02:26 |
| salgado | sabdfl, sure. the depreciation is something that can be discussed later | 02:27 |
| Kinnison | \o/ /\o/\ /o_ /o\ | 02:38 |
| Kinnison | gina has imported with d-i now | 02:38 |
| === Kinnison just has a little more to go before unleashing her on hoary | ||
| sabdfl | we love gina! | 02:48 |
| Kinnison | She's a babe | 02:48 |
| sabdfl | cprov: where can i find the sourceforge / freshmeat access functions? | 02:53 |
| Kinnison | Is this channel registered? | 03:20 |
| bob2 | 00:42:32 kent | bob2, do ubuntu keep track of strings they have changed, and if they are accepted upstreams? if accepted upstream, i guess they will be | 03:42 |
| bob2 | translated in time.. | 03:43 |
| bob2 | that's a good idea! | 03:43 |
| dilys | Merge to rocketfuel@canonical.com/launchpad--devel--0: Database schema patches for Carlos and Mark (patch-851) | 03:46 |
| carlos | thanks | 03:46 |
| === salgado -> lunch and then classes. come back at night | ||
| sabdfl | elmo: around? | 03:49 |
| (elmo/#launchpad) sabdfl: yes | 03:49 | |
| sabdfl | hiya | 03:49 |
| carlos | sabdfl: yesterday, I detected an intrusion in one of my servers. Today seems like another one (the new) has the same problem. Is ok for you If I move my today work to Saturday? | 03:50 |
| sabdfl | can we shuffle the current launchpad.ubuntu.com to dogfood.canonical.com, and make launchpad.ubuntu.com point at macquarie's production launchpad server? | 03:50 |
| sabdfl | elmo: ^ | 03:50 |
| sabdfl | carlos: yes | 03:50 |
| carlos | sabdfl: thanks | 03:50 |
| (elmo/#launchpad) sabdfl: when? | 03:50 | |
| sabdfl | elmo: this week | 03:50 |
| carlos | daf: I will be online, if you need anything from me, just ping me | 03:51 |
| sabdfl | carlos: is there any chance that your compsomise could affect chinstrap? | 03:51 |
| (elmo/#launchpad) sabdfl: sure - is it ready on your end? | 03:51 | |
| carlos | sabdfl: no way | 03:51 |
| sabdfl | elmo: yes, I think the production code gets updated regularly by lifeless and stub | 03:51 |
| (elmo/#launchpad) carlos: you were compromised? | 03:51 | |
| sabdfl | carlos: so you haven't ever ssh'd to a canonical box from those machines? | 03:52 |
| carlos | elmo: not my personal server directly but a gforge server I admin | 03:52 |
| (elmo/#launchpad) sabdfl: should anyone be around when I do it, or can I Just Do It? | 03:52 | |
| carlos | sabdfl: no, I only ssh to canonical machines from my local machines | 03:52 |
| sabdfl | elmo: we cover enough timezones to be able to fix any issues, so Just Do It | 03:52 |
| sabdfl | daf: if you are around, this might affect the rosetta testers | 03:52 |
| sabdfl | but i don't think so since rosetta.shuttleworthfoundation.org will still point at the same ip address on mawson | 03:53 |
| carlos | I have different passwords and the ssh private certificate is not there, so don't think it's a problem | 03:53 |
| sabdfl | carlos: ok, good luck cleaning up | 03:53 |
| carlos | sabdfl: thanks | 03:53 |
| carlos | sabdfl: so rosetta.shuttleworthfoundation.org will be the production server now? | 03:54 |
| sabdfl | carlos: no, it will still point at the dogfood server for a while | 03:55 |
| carlos | ok | 03:55 |
| sabdfl | carlos: later on, we can point it at the production server for most users | 03:56 |
| sabdfl | then the advanced rosetta users can use dogfood.canonical.com for testing pre-released features in rosetta, before they move to production | 03:56 |
| carlos | ok | 03:59 |
| (elmo/#launchpad) sabdfl: are we still client cert protecting both sites? | 04:00 | |
| sabdfl | elmo: yes please | 04:01 |
| === BradB|away is now known as BradB | ||
| cprov | sabdfl: they are under lib/canonical/launchpad/scripts/nicole/, to be precise in sourceforge.py | 05:03 |
| bob2 | minor nit: you can enter random shit in the arch "version" field for a new rcs and it won't complain | 05:20 |
| bob2 | er, for a source | 05:22 |
| === debonzi [~debonzi@200.158.100.251] has joined #launchpad | ||
| lifeless | bob2: yeah, because we don't trust that form. | 05:46 |
| === BradB wishes Zope 3 worked with profiling tools | ||
| BradB | Is there any easy way to turn on debugging in SQLOS? I want to have SQL statements printed out somewhere, to perhaps get an idea of what's making the bug listing take 1m 30s for 7,000 bugs. | 06:16 |
| Kinnison | initialise it with debug=1 ? | 06:17 |
| Kinnison | Where 'it' is something I'm not certain of yet | 06:18 |
| Kinnison | The sqlobject documentation refers to initialising the 'connection' with debug=1 | 06:18 |
| BradB | yeah, i know about that :) i wasn't sure where this is done though. | 06:18 |
| === BradB hunts around for something looking like our db connection | ||
| sabdfl | BradB: log_statement = true | 06:19 |
| sabdfl | in /etc/posgresql/postgresql.conf | 06:19 |
| sabdfl | then restart postgres | 06:19 |
| sabdfl | and tail the log | 06:19 |
| BradB | ROCK | 06:21 |
| BradB | that in combination with log_duration rocks my world | 06:22 |
| BradB | 45 seconds of it is our vocabs, eesh | 06:36 |
| BradB | all the more reason that we really want to upgrade Z3 | 06:37 |
| (elmo/#launchpad) postgres has stats stuff to tell you about index usage etc. too | 07:01 | |
| dilys | Merge to rocketfuel@canonical.com/launchpad--devel--0: Soyuz sourcepackage translation portlet fixed. (patch-852) | 07:13 |
| BradB | lulu: I added the RSS feeds for freshmeat and lwn, and shortened all feeds to five each. I think Simon'll be the right one to respond re: the question specific to ZWiki. | 07:16 |
| BradB | I put anymore optimization work on hold, since the work on the selection widgets will make at least half the problem magically disappear (since the hack of using normal vocabs will be no more.) | 07:19 |
| BradB | lifeless: ping | 07:22 |
| dilys | Malone bug #19 fixed for package malone: Bug listing needs paging | 07:22 |
| dilys | https://launchpad.ubuntu.com/malone/bugs/19 | 07:22 |
| BradB | sabdfl: ping | 07:24 |
| dilys | Malone bug #18 fixed for package malone: Bug workflow needs to make it easy to resolve bugs | 07:29 |
| dilys | https://launchpad.ubuntu.com/malone/bugs/18 | 07:29 |
| === salgado [~salgado@200-206-134-238.async.com.br] has joined #launchpad | ||
| dilys | Malone bug #68 fixed for product Malone: Bug assignments search needs Next and Prev nav options | 07:33 |
| dilys | https://launchpad.ubuntu.com/malone/bugs/68 | 07:33 |
| === BradB is now known as BradB|lunch | ||
| bob2 | I've got a sqlobject, which is not being commited | 07:55 |
| bob2 | commit is called | 07:55 |
| bob2 | no exceptions thrown | 07:55 |
| bob2 | but nada in the db | 07:55 |
| lifeless | BradB|lunch: pong | 07:57 |
| sabdfl | BradB|lunch: pong | 07:58 |
| === Kinnison kicks gina in the unmentionables | ||
| sabdfl | Kinnison: with the beeeatches you got to do the slappin', not the kickin' | 07:59 |
| Kinnison | sabdfl: the way gina is behaving I'm beginning to wonder if she's "All Woman" | 07:59 |
| Kinnison | I have to fix these FMO things or else decide how to cleanly work around them for publishing purposes | 08:00 |
| sabdfl | FMO things? | 08:01 |
| (elmo/#launchpad) fuck me over | 08:01 | |
| (elmo/#launchpad) err, that's what it means | 08:02 | |
| (elmo/#launchpad) it's a kiko-ism | 08:02 | |
| Kinnison | if not srcpkg: | 08:03 |
| Kinnison | print "\t** FMO courtesy of TROUP & TROUT inc. on %s (%s)" \ | 08:03 |
| Kinnison | % (bin.source, bin.source_version) | 08:03 |
| Kinnison | elmo: kiko really loves and admires you, doesn't he? | 08:03 |
| lulu | night all :o) | 08:03 |
| Kinnison | night lu | 08:04 |
| === Kinnison hugs lu | ||
| === lulu hug back! | ||
| === lulu [~lu@host217-37-231-28.in-addr.btopenworld.com] has left #launchpad [] | ||
| dilys | Merge to rocketfuel@canonical.com/launchpad--devel--0: Fixing on Librarian Wrapper and soyuz/people moved to FOAF from salgado (patch-853) | 08:13 |
| Kinnison | cprov: thanks for your efforts on the librarian wrapper today | 08:15 |
| === BradB|lunch is now known as BradB | ||
| BradB | lifeless: stub mentioned something he wanted to get you to do so that it would be easy for us LPers to upgrade Z3 without requiring anything from you...is there something you can think of doing that would make it easy for easy to upgrade Z3 relatively painlessly whenever we decide we need to? | 08:20 |
| BradB | sabdfl: do you have an idea in mind for the shortest distance to assigning a bug? i wanted to fix #47, which refers to that. | 08:22 |
| dilys | Merge to rocketfuel@canonical.com/launchpad--devel--0: doap workflow, manifest work, product portlet cleanup (patch-854) | 08:23 |
| sabdfl | BradB: shortest distance to assigning a bug? | 08:32 |
| BradB | sabdfl: in the collector issue you said: | 08:33 |
| BradB | The idea is that bugs are New until the assignee "accepts" them, at which time they become Open. We really need a fast way to accept bug work, rather than changing the initial state. | 08:33 |
| BradB | Do you know what the fast way to accept bug work is? | 08:33 |
| sabdfl | ok... "changing state" is just an HTTP call, right? so imagine we had a report that had two images - "accept" and "reject" | 08:34 |
| BradB | I can imagine a UI down the road that allows one-click bug acceptance, but i think that's pushing it a bit right now | 08:34 |
| sabdfl | clicking on them gets JS to send that HTTP call | 08:34 |
| sabdfl | and changes the state in the report | 08:35 |
| sabdfl | click click click down the list and you've done it | 08:35 |
| sabdfl | got to go.. back later | 08:35 |
| BradB | ok | 08:35 |
| === dafydd [daf@muse.19inch.net] has joined #launchpad | ||
| Kinnison | daf! | 09:43 |
| dilys | Merge to rocketfuel@canonical.com/launchpad--devel--0: Zope 3 compatibility fix, Carlos' upload database code (patch-855) | 09:50 |
| sabdfl | hey daf | 10:22 |
| BradB | I expect there to be an easy way to fetch a URL in javascript. It appears that I expected wrong. | 11:02 |
| === Kinnison decides that working from 9am to 10pm has got to be enough | ||
| === Kinnison goes to have some dinner and to read his library book | ||
| === BradB tries something | ||
| BradB | kickass | 11:19 |
| BradB | iframe's rock | 11:20 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!