lifeless | -> pet store and stuff | 00:23 |
---|---|---|
lifeless | gary-lunch: look at rev 12564 in devel to see how to do a with query with my patched storm | 00:24 |
wgrant | I tried to create a packageupload(archive, distroseries, status) index on DF. It works for queries like archive=534, distroseries=X, status=Y. But when archive=1 it refuses to use the index. I guess it thinks its stats know better. | 00:37 |
lifeless | do you have a sample query ? | 00:38 |
wgrant | EXPLAIN ANALYZE SELECT PackageUpload.archive, PackageUpload.changesfile, PackageUpload.date_created, PackageUpload.distroseries, PackageUpload.id, PackageUpload.pocket, PackageUpload.signing_key, PackageUpload.status FROM PackageUpload WHERE packageupload.distroseries = 103 AND packageupload.archive = 534 AND packageupload.status IN (0) ORDER BY PackageUpload.id DESC LIMIT 31 OFFSET 0; | 00:39 |
wgrant | That uses the index. | 00:39 |
wgrant | And is fast. | 00:39 |
wgrant | s/534/1/, no index, slow. | 00:39 |
lifeless | gotta run, bbiab | 00:39 |
wgrant | Oh. Now that is interesting. | 00:50 |
wgrant | It uses the index if distroseries=102 | 00:51 |
wgrant | But not 103. | 00:51 |
mwhudson | is it the usual thing where it thinks it's going to be looking at most of the table anyway? | 00:53 |
wgrant | I presume so. | 00:53 |
wgrant | 103 does show up in pg_stats, so that may be it. But other archives that show up there don't see the same issue, so I might have to check out pg_statistics to see what it's doing. | 00:54 |
wgrant | Or harass stub. | 00:54 |
=== Ursinha is now known as Ursinha-afk | ||
gary-lunch | cool thanks lifeless | 01:17 |
* gary-lunch wonders how he became gary-lunch | 01:17 | |
StevenK | gary-lunch: It's a bit late for lunch, isn't it? | 01:18 |
=== gary-lunch is now known as gary_poster | ||
gary_poster | yes indeed | 01:18 |
StevenK | Almost lunch time here, in fact. | 01:18 |
wgrant | Ah. | 01:19 |
wgrant | It will happily use packageupload(archive, distroseries, status, id). | 01:19 |
wgrant | I guess it must have decided that archive=1, distroseries=103 meant the final sort would be too expensive. | 01:20 |
wgrant | Despite the fact that there are actually 0 rows. | 01:20 |
lifeless | wgrant: Limit (cost=0.00..954.05 rows=31 width=36) (actual time=263.988..31328.809 rows=1 loops=1) | 01:25 |
lifeless | -> Index Scan Backward using distroreleasequeue_pkey on packageupload (cost=0.00..93404.35 rows=3035 width=36) (actual time=263.985..31328.804 rows=1 loops=1) | 01:25 |
lifeless | Filter: ((distroseries = 103) AND (archive = 1) AND (status = 0)) | 01:25 |
lifeless | Total runtime: 31328.871 ms | 01:25 |
lifeless | (4 rows) | 01:25 |
lifeless | 1.5 seconds hot | 01:25 |
lifeless | wgrant: thats qastaging | 01:25 |
wgrant | lifeless: Right, that's about what I see on mawson. | 01:26 |
wgrant | Except about 25% faster. | 01:26 |
wgrant | I'll talk to stub about unbreaking the indices tonight. | 01:26 |
wgrant | Since the current ones were designed before archives were introduced... | 01:27 |
lifeless | you're adding an index to match the critera more closely | 01:27 |
lifeless | whats the explain analyze of the query that (isn't using) the new index look like | 01:27 |
lifeless | wgrant: can you drop the order by ? | 01:28 |
lifeless | Time: 37.729 ms | 01:28 |
wgrant | lifeless: The current indices are not reasonable. | 01:28 |
wgrant | We need the order by. | 01:28 |
lifeless | wgrant: why? | 01:28 |
wgrant | packageupload(distroseries, status) does not make sense any more. | 01:28 |
wgrant | Since you never query PUs by series outside an archive. | 01:28 |
lifeless | wgrant: sure, I'm not debating that, just looking at whats going on | 01:29 |
lifeless | wgrant: I meant 'why do we need the order by' | 01:29 |
wgrant | lifeless: So we don't show them in arbitrary order on DistroSeries:+queue | 01:29 |
lifeless | wgrant: why would that matter ? | 01:30 |
wgrant | Because that would make batching sort of bad. | 01:30 |
lifeless | wgrant: SELECT PackageUpload.archive, PackageUpload.changesfile, PackageUpload.date_created, PackageUpload.distroseries, PackageUpload.id, PackageUpload.pocket, PackageUpload.signing_key, PackageUpload.status FROM | 01:32 |
lifeless | PackageUpload WHERE packageupload.distroseries = 103 AND packageupload.archive = 1 AND packageupload.status IN (0) ORDER BY packageupload.distroseries, packageupload.status, PackageUpload.date_created desc LIMIT 31 OFFSET 0; | 01:32 |
wgrant | lifeless: That is cheating. | 01:33 |
lifeless | wgrant: so is life | 01:33 |
wgrant | There's no index on PackageUpload.date_created, so it has no choice. | 01:33 |
wgrant | It will be slow if it returns lots of results. | 01:33 |
lifeless | wgrant: right, so we would not want to do that for every query | 01:34 |
lifeless | wgrant: but the queue isn't unlimited | 01:34 |
lifeless | wgrant: and lots could be a few thousand without perf worries | 01:34 |
lifeless | wgrant: I agree we need to improve the indices | 01:34 |
wgrant | lifeless: https://launchpad.net/ubuntu/lucid/+queue?queue_state=3&queue_text= | 01:35 |
wgrant | 130000 | 01:35 |
lifeless | wgrant: whats 3 | 01:36 |
wgrant | lifeless: Done. | 01:36 |
lifeless | we should delete them | 01:36 |
wgrant | You could argue that. | 01:36 |
lifeless | s/c/sh/ | 01:36 |
wgrant | It requires reworking lots of Soyuz. We should probably do that, but that is a *huge* *huge* thing. | 01:37 |
wgrant | We need to develop a strategy. | 01:37 |
LPCIBot | Project windmill build #37: STILL FAILING in 1 hr 9 min: https://hudson.wedontsleep.org/job/windmill/37/ | 01:37 |
wgrant | On how we handle history like this. | 01:37 |
wgrant | And apply it everywhere. | 01:38 |
StevenK | Windmill, you make me very sad. | 01:38 |
wgrant | StevenK: It's right, though. | 01:39 |
lifeless | wgrant: so, does the queue *post* need new indices to be fixed? | 01:40 |
lifeless | wgrant: or would my hack give breathing space? | 01:40 |
wgrant | lifeless: I personally think that some of this data is useful. The table is small, and it's extremely fast to query with the right indices. | 01:40 |
wgrant | lifeless: I don't think that hack is useful. | 01:40 |
wgrant | It would work. | 01:40 |
lifeless | ok | 01:40 |
wgrant | But an index is less of a hack, and works everywhere. | 01:40 |
lifeless | 455 Time Outs | 01:56 |
lifeless | nice | 01:56 |
lifeless | bugger | 01:57 |
lifeless | 23 / 22 POFile:+translate | 01:57 |
lifeless | 20 / 0 LanguageSet:CollectionResource:#languages | 01:57 |
wgrant | Wow. | 01:58 |
lifeless | ah | 01:58 |
wgrant | Bugger? | 01:58 |
lifeless | wgrant: things we had fixed | 01:58 |
wgrant | They weren't deployed yet, were they? | 01:58 |
lifeless | but yeah | 01:58 |
lifeless | 9 hours of them | 01:58 |
wgrant | They are now. | 01:58 |
lifeless | tomorrow will give better results again | 01:58 |
wgrant | Yep. | 01:58 |
wgrant | This is why I want 12-hourly ones :( | 01:59 |
lifeless | wgrant: I want a sliding window | 01:59 |
wgrant | Right. | 01:59 |
lifeless | plus per-deploy | 01:59 |
wgrant | But that needs oops-repository. | 01:59 |
wgrant | (I suspect) | 01:59 |
lifeless | well, can be done in the current code, just a matter of effort | 01:59 |
wgrant | Right. | 02:00 |
lifeless | I'm going to look into hbase as an alternative to cassandra | 02:00 |
wgrant | Oh? | 02:00 |
lifeless | need to send a raft of emails around | 02:00 |
wgrant | I haven't heard much about hbase... | 02:00 |
wgrant | But it's Apache too, right? | 02:00 |
lifeless | that aspect is fine | 02:00 |
lifeless | the issue with cassandra is lack of range queries | 02:01 |
wgrant | :( | 02:01 |
wgrant | lifeless: Do we expect daemons to survive DB restarts? I know eg. librarian doesn't. | 02:10 |
lifeless | wgrant: yes | 02:11 |
lifeless | wgrant: exact implementation to be figured out later | 02:11 |
wgrant | So that's a no? | 02:11 |
lifeless | today, restarting the db may wed daemons. If so thats a bug. | 02:12 |
wgrant | I'm tempted to leave poppy broken in that situation, given that most other daemons will have the same issue. | 02:12 |
wgrant | Can you see any problem with that? | 02:14 |
wgrant | It's not going to try to hold transactions open forever any more, so it shouldn't get killed :) | 02:15 |
lifeless | if you know of a specific defect, please make sure there is a high bug about it | 02:15 |
wgrant | I think it's a general defect in all daemons... | 02:16 |
lifeless | wgrant: I wouldn't assume that | 02:16 |
wgrant | Anyway, lunch, double poppy cowboy fixing, and then +copy-packages UI optimisations. | 02:18 |
wgrant | Because the actual copy operation is now fast :( | 02:18 |
lifeless | \o/ | 02:18 |
StevenK | wgrant: That timeout was due to UI? | 02:19 |
LPCIBot | Project windmill build #38: STILL FAILING in 46 min: https://hudson.wedontsleep.org/job/windmill/38/ | 02:24 |
wgrant | StevenK: Yes ;( | 02:26 |
wgrant | At least I think so. | 02:28 |
wgrant | It's a bit hard to tell exactly what's what. | 02:29 |
wgrant | Because the UI stuff generates a lot of queries. | 02:29 |
wgrant | It's also not copying binaries, which is a case that is less optimised. But it doesn't seem to get to the actual copies. | 02:30 |
wgrant | Erm. | 02:30 |
wgrant | "I get a timeout error when trying to copy a few (5+) packages from a ppa" | 02:30 |
wgrant | But field.selected_sources has at least 15... | 02:30 |
wgrant | I suppose that is technically still 5+... | 02:31 |
lifeless | :> | 02:31 |
lifeless | wow | 02:32 |
lifeless | Aggregate (cost=7238627.72..7238627.73 | 02:32 |
wgrant | Which query's that? | 02:32 |
lifeless | https://lp-oops.canonical.com/oops.py/?oopsid=1895B1870 | 02:33 |
wgrant | Ah. | 02:33 |
lifeless | partitioning the query into two unioned on each fti column gets | 02:35 |
lifeless | Aggregate (cost=291.55..291.56 rows=1 width=0) | 02:35 |
lifeless | I've been dreading this | 02:36 |
lifeless | but its time to bite the bullet and do it | 02:36 |
lifeless | I'll do my administrivia stuff monday | 02:36 |
wgrant | Heh | 02:37 |
lifeless | I wonder | 02:37 |
lifeless | maybe I'll just ditch the bugtask fti column | 02:37 |
wgrant | Does that just index targetnamecache? | 02:37 |
lifeless | 16 more hits | 02:40 |
lifeless | for synaptics touchpad | 02:40 |
lifeless | targetnamecache and statusexplanation | 02:40 |
lifeless | -wtf- | 02:40 |
wgrant | I thought statusexplanation was actually dead now. | 02:41 |
wgrant | Apparently not :/ | 02:41 |
lifeless | COMMENT ON COLUMN BugTask.statusexplanation IS 'A place to store bug task specific information as free text'; | 02:42 |
wgrant | You know what it is, right? | 02:42 |
lifeless | no idea | 02:42 |
wgrant | You know how the old task edit form had a comment field? | 02:43 |
wgrant | That adds a comment and sets statusexplanation. | 02:43 |
wgrant | Those changes are also logged in bugactivity. | 02:43 |
lifeless | lib/lp/bugs/scripts/bugzilla.py uses it | 02:43 |
wgrant | If that's what I think it is, it will die. | 02:43 |
wgrant | I wonder if it still works. | 02:44 |
lifeless | the task edit form still exists | 02:44 |
lifeless | browser/bugtask.py has | 02:44 |
wgrant | Yes, but it doesn't need to set statusexplanation. | 02:44 |
lifeless | if comment_on_change: | 02:44 |
lifeless | bugtask.statusexplanation = comment_on_change | 02:44 |
lifeless | select count(*) from bugtask where statusexplanation is null or statusexplanation=''; | 02:45 |
lifeless | count | 02:45 |
lifeless | -------- | 02:45 |
lifeless | 531321 | 02:45 |
lifeless | select count(*) from bugtask where statusexplanation is not null; | 02:45 |
lifeless | count | 02:45 |
lifeless | -------- | 02:45 |
lifeless | 480008 | 02:45 |
lifeless | bah | 02:45 |
wgrant | Hmmm? | 02:45 |
lifeless | select count(*) from bugtask where statusexplanation is not null and statusexplanation != ''; | 02:45 |
lifeless | count | 02:45 |
lifeless | -------- | 02:45 |
lifeless | so 300K set, 530K unset | 02:45 |
lifeless | 300198 | 02:45 |
wgrant | Right. Kill it. | 02:45 |
wgrant | It has been thoroughly deprecated for more than 5 years. | 02:46 |
wgrant | We have these wonderful things called comments to store that information now :) | 02:46 |
lifeless | bug/88545 | 02:49 |
lifeless | bug 88545 | 02:50 |
lifeless | no mup? | 02:50 |
thumper | statusexplanation? | 02:52 |
lifeless | a discarded idea | 02:52 |
StevenK | Is it actually used in the codebase at all? | 02:57 |
lifeless | grep ftw | 02:58 |
wgrant | The only place I've seen it exposed is BugTask:+activity | 02:58 |
StevenK | lifeless: Isn't there another clean up you wanted to do with BugComment and Bug<name escapes me currently> | 02:59 |
lifeless | jcsackett is on that | 02:59 |
lifeless | or at least on nearby stuff | 02:59 |
wgrant | BugMessage.visible was moved this morning. | 02:59 |
StevenK | Ah yes BugComment versus BugMessage | 03:00 |
lifeless | there is a completely redundant python class constructed from bugmessage+message | 03:00 |
lifeless | if we had separation of concerns - a persistence layer - it would make sense | 03:00 |
lifeless | but its purely a Data Object at the moment, valueless. | 03:00 |
StevenK | libwebkitgtk-1.0.0-dbg DIALCF! | 03:01 |
wgrant | StevenK: Why? | 03:02 |
StevenK | 240MiB debug packages make me cranky. | 03:02 |
wgrant | Hah. | 03:02 |
StevenK | And it's Webkit, which I have other issues with. | 03:03 |
lifeless | like, it existing? | 03:06 |
StevenK | lifeless: Is that your issue with it? | 03:07 |
lifeless | no | 03:07 |
lifeless | bundled libraries | 03:07 |
lifeless | bugs | 03:07 |
lifeless | footprint | 03:07 |
StevenK | That's one of my issues -- my major gripe of it is just how much crap is in it | 03:07 |
wgrant | I prefer WebKit to Gecko... at least once it has been deGoogled. | 03:07 |
lifeless | its a whole desktop | 03:08 |
wgrant | ie. had the hundred external libraries excised. | 03:08 |
lifeless | what could be wrong | 03:08 |
StevenK | Which gives us wonderful things like the aforementioned 240MiB debug packages. | 03:08 |
StevenK | wgrant: Oh, Gecko is no better | 03:08 |
StevenK | From the same people who gave us building UIs from XML | 03:08 |
StevenK | Oh crap, now I need to review my lunch. | 03:08 |
wgrant | Um, most GTK apps now build UIs from XML :) | 03:08 |
lifeless | wgrant: exactly | 03:09 |
StevenK | Didn't XUL start that madness? | 03:09 |
wgrant | It is unclear that it is madness. | 03:09 |
lifeless | wgrant: you saw https://code.launchpad.net/~lifeless/storm/with-without-datetime right ? | 03:10 |
StevenK | Anyway, yay for feeping creaturism | 03:10 |
wgrant | lifeless: I never looked at the code. | 03:10 |
lifeless | wgrant: thats fine | 03:10 |
lifeless | whats the script that gives committer frequencies in lp | 03:11 |
wgrant | What do you mean? Number of commits by person for a particular branch? | 03:12 |
lifeless | within a timeframe, or per month, or whatever. | 03:12 |
lifeless | yes | 03:12 |
lifeless | I can has review? https://code.launchpad.net/~lifeless/launchpad/bug-716774/+merge/52966 | 03:13 |
wgrant | I don't know of anything beyond bzr-stats... | 03:13 |
lifeless | wgrant: does PoppyFileWriter's validateGPG affect sftp uploads? | 03:14 |
wgrant | lifeless: No. | 03:14 |
wgrant | It's only used in FTP for now. | 03:14 |
wgrant | (WTF, I know, but convenient) | 03:14 |
lifeless | thanks | 03:15 |
wgrant | I guess I should start that IR at some point. | 03:15 |
lifeless | or ask me to do it | 03:16 |
lifeless | but don't sit on it | 03:16 |
wgrant | I'm sure you have better things to do. I'll do it. | 03:16 |
StevenK | wgrant: Julian says he couldn't work out how to do it for SFTP uploads. Which made me sad. :_( | 03:20 |
wgrant | :( | 03:20 |
StevenK | I'm hoping poppy-{s,}ftp now get a good hard refactoring | 03:24 |
StevenK | $DEITY knows they deserve it. | 03:24 |
wgrant | A renaming wouldn't go astray either. | 03:24 |
StevenK | Oh, and death to zope ftp would be nice, too. | 03:26 |
wgrant | lifeless: An advertised feature is no longer working. Not Critical? | 03:26 |
lifeless | wgrant: we've never had it live | 03:28 |
lifeless | wgrant: we tried and it went boom | 03:28 |
wgrant | It was working fine for like an hour :P | 03:28 |
lifeless | wgrant: that doesn't count | 03:28 |
wgrant | :( | 03:29 |
lifeless | julian blogging about it was great enthusiasm, but we probably want to wait for things to be stable before announcing | 03:29 |
wgrant | Indeed. | 03:29 |
lifeless | wgrant: point is, if we stopped work on the improvement right now, we haven't actually gone back on anything folk could have started depending on. | 03:30 |
lifeless | that said, I think we should push forward and get it going | 03:30 |
lifeless | it will make a huge difference to usability. | 03:30 |
lifeless | and that will mean happier and less confused users | 03:31 |
lifeless | lower support overhead and easier training for new ubuntu devs | 03:31 |
wgrant | thumper: Hi. | 03:36 |
thumper | wgrant: hi | 03:36 |
wgrant | thumper: Could you mentor https://code.launchpad.net/~lifeless/launchpad/bug-716774/+merge/52966? | 03:36 |
* thumper looks | 03:37 | |
wgrant | Anyone want to review https://code.launchpad.net/~wgrant/launchpad/poppy-transaction-unbreakage/+merge/52967? | 03:37 |
StevenK | wgrant: Done. thumper ^ | 03:39 |
thumper | OMG | 03:40 |
thumper | my recursive query worked | 03:40 |
thumper | http://pastebin.ubuntu.com/578642/ | 03:40 |
StevenK | According to the postgres docs it's iteration, not recursion :_) | 03:41 |
thumper | does postgres have stored procs? | 03:41 |
StevenK | From memory, yes | 03:42 |
thumper | hmm | 03:43 |
StevenK | wgrant: Wait. Are you sure you ran bzr add? | 03:43 |
thumper | doing the blueprint dependencies in the db has to be better than doing X queries | 03:43 |
lifeless | thumper: yes | 03:47 |
lifeless | thumper: you can do that with the storm we have in trunk | 03:47 |
thumper | lifeless: how? | 03:47 |
lifeless | store.with(SQL('RECURSIVE dependencies(id, name, depth) AS ( | 03:47 |
lifeless | SELECT s.id, s.name, 1 | 03:47 |
lifeless | FROM specification s | 03:47 |
lifeless | where s.id = 20428 | 03:47 |
lifeless | UNION ALL | 03:47 |
lifeless | SELECT s.id, s.name, d.depth + 1 | 03:48 |
lifeless | FROM specificationdependency sd, dependencies d, specification s | 03:48 |
lifeless | WHERE sd.specification = d.id | 03:48 |
lifeless | AND s.id = sd.dependency | 03:48 |
lifeless | )') | 03:48 |
lifeless | bah | 03:48 |
lifeless | store.with_ | 03:48 |
lifeless | so store.with_(clause).find(Specification) | 03:48 |
lifeless | or whatever | 03:48 |
lifeless | probably | 03:48 |
lifeless | so store.with_(clause).find(Specification, SQL('Specification.id in (select id from dependencies))') | 03:49 |
lifeless | thumper: care to review https://code.launchpad.net/~lifeless/launchpad/bug-716774/+merge/52966 ? | 03:51 |
thumper | lifeless: I have | 03:52 |
lifeless | oh sweet | 03:52 |
lifeless | thanks | 03:52 |
lifeless | sorry I hadn't noticed | 03:52 |
* lifeless ec2inates | 03:52 | |
StevenK | Which just sounds ... wrong. | 03:52 |
wgrant | StevenK: What did I miss? | 03:55 |
StevenK | wgrant: It looks to me that you moved all the imports but not the actual method itself? | 03:55 |
wgrant | 211=== renamed file 'lib/lp/bugs/externalbugtracker/isolation.py' => 'lib/lp/services/database/isolation.py' | 03:55 |
wgrant | 212=== renamed file 'lib/lp/bugs/externalbugtracker/tests/test_isolation.py' => 'lib/lp/services/database/tests/test_isolation.py' | 03:55 |
StevenK | Ah ha. Objection withdrawn, the MP is still approved. | 03:56 |
thumper | I'm actually pretty stoked about that blueprint dependency query | 03:58 |
thumper | now to squeeze it into the code somehow | 03:58 |
wgrant | Let's hope we don't have to revert to pg 8.3 :) | 03:59 |
StevenK | Haha | 03:59 |
thumper | wgrant: recursive queries were added in 8.3 | 04:00 |
thumper | at least I thought so | 04:01 |
StevenK | WITH RECURSIVE was added in 8.4 | 04:01 |
wgrant | I thought WITH was added in 8.4. | 04:01 |
thumper | ah... | 04:01 |
wgrant | Right. | 04:01 |
thumper | I wonder what the likelyhood of that is then... | 04:01 |
wgrant | 0 | 04:01 |
thumper | \o/ | 04:01 |
StevenK | thumper: Can haz mentor? :-) | 04:08 |
wgrant | thumper: Could you mentor https://code.launchpad.net/~wgrant/launchpad/poppy-transaction-unbreakage/+merge/52967? | 04:08 |
StevenK | Haha | 04:08 |
* thumper looks | 04:08 | |
wgrant | Thanks. | 04:09 |
thumper | 'tis past wine o'clock on a Friday | 04:09 |
thumper | you're lucky :0 | 04:09 |
lifeless | we're not reverting | 04:09 |
lifeless | not to 8.3 | 04:09 |
lifeless | that goose has flown | 04:09 |
StevenK | Can we revert to 9.0? That sounds like FUN. | 04:10 |
thumper | done | 04:11 |
wgrant | 9.0 already? Well done. | 04:11 |
StevenK | Damn it, I just missed a devel build on buildbot | 04:12 |
StevenK | ... by about 30 seconds. :-( | 04:12 |
wgrant | We can't roll out until Tuesday, either :( | 04:12 |
lifeless | tuesday? | 04:12 |
wgrant | ACT public holiday on Monday, and no mthaddon next week. | 04:13 |
StevenK | Haha, awesome | 04:13 |
* thumper wines a little | 04:15 | |
* thumper AFK | 04:15 | |
StevenK | s/w/wh/ | 04:15 |
* thumper pokes StevenK in the eye | 04:16 | |
StevenK | Ow! | 04:16 |
wgrant | :( | 04:50 |
wgrant | Does BugTask.status serve any useful purpose? | 04:51 |
lifeless | uhm | 05:09 |
lifeless | its where we store triaged etc | 05:09 |
wgrant | Opinion/Invalid/Won'tFix aren't usefully separated, New is implicit, Confirmed is implied by affects, In Progress is effectively implied by assignee, Fix Committed and Fix Released are implied by MP status. | 05:11 |
wgrant | So we can replace them all with "valid" and "incomplete" flags. | 05:11 |
cody-somerville | or customizable bug statuses. \o/ | 05:12 |
StevenK | wgrant: Right, which works for *us*, but may not work for other projects. | 05:12 |
wgrant | StevenK: They work for anyone that uses MPs. | 05:13 |
wgrant | Unless they are abusing statuses, in which case they are wrong :) | 05:13 |
cody-somerville | no | 05:13 |
cody-somerville | its not 'wrong'. its the system speaking to you. | 05:13 |
StevenK | cody-somerville: What possible need do you have for customizing bug statuses? | 05:14 |
cody-somerville | Oh, OEM Services has tons since we abuse bugs for other things. | 05:14 |
huwshimi | wgrant: Take a look at the statuses proposed on this page: https://dev.launchpad.net/IssueTracker | 05:14 |
wgrant | huwshimi: Mmm. Better, but still not optimal. | 05:15 |
cody-somerville | ugh. not better IMHO. | 05:16 |
StevenK | What, two statuses? Fixed and Unfixed? :-P | 05:16 |
wgrant | cody-somerville: Why? | 05:17 |
wgrant | The only significant change is merging Fix Committed and Fix Released. | 05:17 |
StevenK | I think cody-somerville wants *more* statuses, not less. | 05:17 |
lifeless | so workflow around bugs is a fascinating topic | 05:20 |
cody-somerville | indeed | 05:23 |
StevenK | OH FER. libwebkitgtk-1.0-0-dbg isn't enough, libwebkitgtk-3.0-0-dbg exists too | 05:25 |
wgrant | StevenK: Why are you dealing with them? | 05:26 |
StevenK | Local mirror sync | 05:26 |
wgrant | Ah. | 05:27 |
wgrant | :( | 05:28 |
wgrant | DF doesn't have memcached installed. | 05:28 |
cody-somerville | but for what its worth... I think the current set of bug statuses are alright. I'm much more interested and would get much more value (professionally and personally) from things like build-from-branch and derivative distributions. :) | 05:29 |
StevenK | cody-somerville: You know recipe builds are "done", right? | 05:30 |
wgrant | Recipes != BFB | 05:30 |
StevenK | Oh, right. | 05:30 |
StevenK | That saddens me. | 05:30 |
StevenK | lol. OO.o is in NBS | 05:31 |
cody-somerville | cause although tweaking the bug statuses might make LP better to some degree, it isn't going to make it more competitive against say github or OBS. | 05:33 |
cody-somerville | Anyhow, I should try and get some sleep. :) *waves* | 05:34 |
* wgrant murders get(Build)StatusSummar(y|ies)(For(Builds|Source(Publication|IdsAndArchive))) | 05:49 | |
StevenK | wgrant: Seriously? | 05:52 |
LPCIBot | Project windmill build #39: STILL FAILING in 1 hr 9 min: https://hudson.wedontsleep.org/job/windmill/39/ | 05:53 |
wgrant | StevenK: Well, bits of them at least. | 05:59 |
StevenK | Aww | 06:00 |
wgrant | SourceForge's new platform is interesting. | 06:00 |
wgrant | Rather GitHubish. | 06:00 |
wgrant | And far less awful than their old one, at first glance. | 06:01 |
huwshimi | wgrant: They've just open sourced their backend too | 06:07 |
wgrant | Yeah, that's the new one. | 06:07 |
wgrant | Currently grabbing it... | 06:07 |
StevenK | Haha, of course you are. | 06:08 |
wallyworld | wgrant: i can't seem to run any windmill tests locally (to fix the breakage). is there a config item i need to tweak do you know? | 06:11 |
wgrant | wallyworld: --layer=WindmillLayer | 06:14 |
wgrant | It defaults to --layer=!(MailmanLayer|WindmillLayer) | 06:15 |
wallyworld | wgrant: thanks | 06:15 |
wallyworld | was that what you changed to stop the tests by default? | 06:16 |
wgrant | Yeah. It was previously just !MailmanLayer | 06:16 |
wgrant | (see buildout-templates/bin/test.in) | 06:17 |
wgrant | wallyworld: I considered just changing the vocab keys to series.name, but I'm not sure how much the form machinery will like that. | 06:32 |
wgrant | Evening stub. | 06:33 |
wallyworld | wgrant: you mean to fix the test? i'm still considering how to fix it. shouldn't be too hard | 06:34 |
wgrant | wallyworld: The test isn't broken. | 06:34 |
wgrant | wallyworld: The code is. | 06:34 |
stub | yo | 06:34 |
wallyworld | wgrant: yeah, can see that :-( | 06:35 |
wgrant | stub: mawson's garbo-hourly is a bit unhappy. Do I have to manually apply session.sql? | 06:35 |
lifeless | stub: how hard is it to update fti ? | 06:36 |
stub | Parts of launchpad_session.sql | 06:36 |
stub | wgrant: What bit is it barfing on? | 06:36 |
wgrant | -> http://librarian.dogfood.launchpad.net/57720639/nqvma824KMUojGISQIkXotVXlmD.txt (function cursor_fetch(unknown, integer) does not exist | 06:36 |
stub | lifeless: Just edit the data structure at the top of fti.py - it handles creating all the triggers, columns, indexes etc. automatically | 06:36 |
lifeless | stub: can we update it live? | 06:37 |
stub | lifeless: No. Adding or changing the triggers requires a table lock. | 06:37 |
lifeless | k | 06:37 |
lifeless | was thinking of sneaking up on https://code.launchpad.net/bugs/88545 | 06:39 |
stub | wgrant: So from database/schema/launchpad_session.sql you want CREATE OR REPLACE FUNCTION cursor_fetch and the GRANT EXECUTE ON FUNCTION cursor_fetch | 06:39 |
stub | (I'd applied this manually to staging and production systems before the code landed but forgot about mawson) | 06:40 |
stub | wgrant: That needs to be applied to the session database on mawson of course | 06:41 |
wgrant | Right. | 06:41 |
wgrant | Thanks. | 06:41 |
wgrant | Much happier, thanks. | 06:42 |
wgrant | stub: I also have some concerns about PackageUpload's indices. | 06:43 |
stub | wgrant: ? | 06:46 |
wgrant | stub: See the last comment in bug #276950 | 06:47 |
wgrant | I don't think packageupload(distroseries, status) has been very useful in the last ~4 years. | 06:47 |
stub | wgrant: It seems to be used, but for what I can't tell: http://paste.ubuntu.com/578697/ | 06:53 |
stub | Looks like we haven't deleted any GPG keys for a while though | 06:54 |
wgrant | stub: I guess it might try to use that if there's no order, even if the archive is constrained. | 06:55 |
wgrant | It avoids (archive, distroseries, status) for some values if it has to order by ID. | 06:55 |
wgrant | But will use it for others. | 06:55 |
StevenK | stub: Does that mean the signing_key index is unused? | 06:55 |
stub | StevenK: It means no lookups are done using signingkey. That index exists to support deleting a row from the gpgkey table (which needs to locate any referencing rows). | 06:56 |
StevenK | stub: Ah right, which also explains your deletion of GPG keys comment. | 06:57 |
StevenK | I'm pondering a new key, my current one is 7.5 years old | 06:58 |
stub | wgrant: Do you have a problem with the table, such as really slow restore times, disk space utilization, or slow insert times? | 06:59 |
lifeless | slow queries | 06:59 |
wgrant | stub: Just slow queries. | 06:59 |
wgrant | I think the existing index is pointless. | 06:59 |
wgrant | And should be replaced. | 06:59 |
wgrant | There's an example query in the bug I referenced. | 06:59 |
stub | It might make sense to replace it. | 06:59 |
stub | poke mup | 07:00 |
wgrant | It's been dead most of the day. | 07:00 |
wgrant | https://bugs.launchpad.net/launchpad/+bug/276950 | 07:00 |
stub | wgrant: Your suggestion sounds sane. I wouldn't normally make such a specific index without knowing for sure it will be used, but you have already done that research. | 07:02 |
wgrant | (archive, distroseries, status) queries are done extensively. | 07:02 |
stub | We don't have to drop the existing index though - if it becomes unused I'll pick it up next time I do a scan. It will slow down inserts, but won't slow down selects. | 07:03 |
stub | Right. I don't think they used to, because we didn't used to have ppas etc. | 07:03 |
wgrant | Exactly. | 07:03 |
wgrant | I think this index is just a few years out of date. | 07:03 |
stub | Back from when the table was called DistroReleaseQueue it seems | 07:04 |
stub | (maybe I can rename primary key indexes without pain now in 8.4?) | 07:04 |
lifeless | stub: does postgresql have a log-slow-queries facility ? | 07:04 |
wgrant | (I initially tried without id, but the slow view's queries sort by id, and in some conditions it reverts back to the plain id index) | 07:04 |
stub | lifeless: yes | 07:04 |
lifeless | stub: can we turn that on, set to 15000ms, and get some reports around it ? Ideally we'd tie it back to the request/script | 07:05 |
lifeless | stub: I'm thinking with all the improvements we've done, we're at the point where starting to track slow queries isn't just insane | 07:05 |
wgrant | lifeless: You clearly haven't seen the scripts lately. | 07:05 |
lifeless | wgrant: I'm very worried about script performance | 07:06 |
stub | log_min_duration_statement. We should enable it for limited users though, perhaps just one appserver, to keep the logs sane. | 07:07 |
lifeless | stub: by sane, do you mean 'not overwhelming' ? | 07:07 |
stub | Yes | 07:07 |
lifeless | stub: rather than do it for limited users, lets set a higher minimum | 07:08 |
lifeless | stub: that way we don't have to keep updating it as more users are added | 07:08 |
stub | lifeless: So it will be full of garbo queries then. | 07:08 |
stub | We expect some longer queries for the batch jobs - that is why they are batch jobs. | 07:09 |
lifeless | stub: I want the backend tasks to be fast too | 07:09 |
lifeless | stub: for a few reasons - latency, total overhead, mvcc garbage overhead | 07:10 |
lifeless | stub: so I'm just as interested in garbo, rosetta etc as I am in appservers | 07:10 |
stub | So you won't see any appserver queries then, because I'd need to set the timeout to something nuts like 10seconds. | 07:10 |
lifeless | stub: I was suggesting an initial setting of 15 seconds | 07:10 |
lifeless | stub: we see 15 second queries on appservers at the moment | 07:10 |
lifeless | well, 13 now - cause they hit the timeout | 07:11 |
stub | I'll turn it on at 15s and see how our logs survive. | 07:11 |
lifeless | and expire on the server - but we still have a couple of overrides | 07:12 |
lifeless | cool | 07:12 |
stub | We already get the statements killed by timeout btw. They show up as errors in the logs. | 07:13 |
lifeless | cool | 07:13 |
stub | parsing the logs sucks though. The format is bogus. | 07:14 |
lifeless | the oops reporting system should be telling us about all of the expired ones | 07:14 |
lifeless | and i see this pattern a lot: | 07:14 |
lifeless | a few cheap queries | 07:14 |
lifeless | a mammoth query | 07:14 |
lifeless | a few cheap queries | 07:14 |
lifeless | an expired query | 07:14 |
stub | pgfouine might make a reasonable report even if we don't feed it full logs. | 07:15 |
wgrant | lifeless: Bugzilla integration? You mean the one-off script that imported Ubuntu Bugzilla? | 07:18 |
lifeless | wgrant: poppy could run in autocommit mode perhaps | 07:19 |
lifeless | wgrant: grep for the field, you tell me | 07:19 |
stub | I'm not seeing any log spam at 15s | 07:21 |
wgrant | Wait 'til the publisher runs :) | 07:21 |
stub | <update-pkg-cache@launchpad_prod_3:31495> 2011-03-11 07:22:14 UTC LOG: duration: 88923.523 ms statement: SELECT COUNT(*) FROM (SELECT DISTINCT BinaryPackageName.id, BinaryPackageName.name FROM BinaryPackageName, BinaryPackagePublishingHistory, BinaryPackageRelease, DistroArchSeries WHERE | 07:22 |
stub | BinaryPackagePublishingHistory.binarypackagerelease = | 07:22 |
stub | BinaryPackageRelease.id AND | 07:22 |
stub | BinaryPackageRelease.binarypackagename = | 07:22 |
stub | BinaryPackageName.id AND | 07:22 |
stub | BinaryPackagePublishingHistory.status IN (1, 2) AND | 07:22 |
stub | BinaryPackagePublishingHistory.pocket = 0 AND | 07:22 |
stub | BinaryPackagePublishingHistory.distroarchseries = | 07:22 |
stub | DistroArchSeries.id AND | 07:22 |
stub | DistroArchSeries.distroseries = 103 AND | 07:22 |
stub | BinaryPackagePublishingHistory.archive IN (1, 534) | 07:22 |
stub | AND (1=1)) AS "_tmp" | 07:23 |
stub | So its working. | 07:23 |
stub | And hopefully the publisher doesn't have any queries that evil ;) | 07:23 |
wgrant | Well, some of its queries take 10 minutes on mawson... they're not quite that bad on prod, though. | 07:23 |
lifeless | stub: I'd leave it for a day | 07:23 |
lifeless | review on monday | 07:24 |
stub | I'm about to poke the GSAs to twiddle logrotate to guard against this taking us down. | 07:24 |
lifeless | stub: awesome, thanks | 07:24 |
adeuring | good morning | 08:23 |
henninge | Hi adeuring! | 08:41 |
adeuring | moin henninge | 08:41 |
henninge | adeuring: I am almost done with the check list. | 08:44 |
adeuring | great | 08:45 |
=== adeuring changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | firefighting: - | On call reviewer: adeuring | https://code.launchpad.net/launchpad-project/+activereviews | ||
=== almaisan-away is now known as al-maisan | ||
henninge | adeuring: pulled, merged, pushed | 09:03 |
adeuring | cool | 09:03 |
henninge | And it looks really cool, too. | 09:03 |
henninge | and works well for most items because the views I am linking to use "ReturnToReferrerMixin", so I mostly get back to the details page. | 09:04 |
henninge | only the last one doesn't | 09:04 |
henninge | adeuring: I have to run an errand, be back later. | 09:05 |
=== henninge is now known as henninge-bbl | ||
jam | lifeless: can you ec2land https://code.launchpad.net/~jameinel/launchpad/loggerhead-732481/+merge/52902 | 09:19 |
jam | or maybe adeuring ^^ | 09:19 |
adeuring | jam: yes, I'll land it. | 09:20 |
jam | adeuring: thanks. | 09:20 |
LPCIBot | Project windmill build #40: STILL FAILING in 1 hr 8 min: https://hudson.wedontsleep.org/job/windmill/40/ | 10:07 |
=== henninge-bbl is now known as henninge | ||
lifeless | jam: something that would be nice: a patch to the loggerhead Makefile so that 'make check' runs the test suite with the loggerhead tree from . | 11:08 |
=== henninge_ is now known as henninge | ||
=== al-maisan is now known as almaisan-away | ||
deryck | Morning, all. | 12:02 |
allenap | deryck: Good morning :) | 12:08 |
allenap | deryck: I have a branch that does some work on Javascript building. As an expert in this area, would you have time to review it? | 12:09 |
deryck | allenap, sure. | 12:09 |
allenap | deryck: https://code.launchpad.net/~allenap/launchpad/alt-javascript-build/+merge/53006 | 12:09 |
allenap | Thank you :) | 12:09 |
deryck | np | 12:10 |
deryck | looking now.... | 12:10 |
jtv | Anyone here really familiar with feature flags? I just can't figure out what the proper way to handle an "enabled" setting is. Should I set true/false, or on/off? Should I evaluate its value as boolean, or compare to my chosen "on" string? How do I clear the flag in a test, and how in production? | 12:20 |
jtv | The existing code seems divided on the subject. | 12:20 |
wgrant | jtv: I standardised it a few weeks back... | 12:20 |
wgrant | It should be pretty standard, except for memcache. | 12:20 |
wgrant | if getFeatureFlag('foo'): | 12:20 |
jtv | And then what are appropriate values for that flag? | 12:20 |
wgrant | It's not optimal ('' = False, everything else True), but it's simple and easy to use in TAL. | 12:21 |
wgrant | We agreed that it was the least evil solution for now. | 12:21 |
jtv | Can we set a feature flag to the empty string> | 12:21 |
jtv | ? | 12:21 |
wgrant | Yes. | 12:21 |
deryck | allenap, looks great, thanks for doing this! r=me | 12:22 |
allenap | deryck: Woohoo :) Thank you. | 12:22 |
deryck | np :-) | 12:22 |
jtv | wgrant: oh well, it seems to satisfy my tests. Thanks. | 12:25 |
jtv | And then I guess I can use any string whatsoever to indicate "on": yes, true, enable, on, or even off, disable, die, nothanks, samovar, … | 12:25 |
wgrant | Yes :( | 12:26 |
jtv | Is the data still entered as a tab-separated text field? Because that gives extra juice to the whole "blank" thing. | 12:27 |
wgrant | The separator can be any whitespace. | 12:27 |
allenap | Is it me, or is Launchpad very slow right now? | 12:31 |
bigjools | allenap: I don't know, are you slow? | 12:32 |
allenap | bigjools: Fairly slow, yes. | 12:32 |
wgrant | It's slow, but not slower than usual AFAICT. | 12:32 |
allenap | Okay, thanks. It's not doing anything at all for me now. | 12:33 |
bigjools | might be a bad appserver | 12:34 |
allenap | bigjools: Sounds about right... it's okay again now. | 12:37 |
jtv | wgrant: the feature flags documentation still uses "off" as an example. | 12:37 |
wgrant | jtv: Where? | 12:40 |
wgrant | jtv: The docs on /+feature-info should be up to date. | 12:40 |
jtv | wgrant: https://dev.launchpad.net/FeatureFlags | 12:40 |
wgrant | jtv: Fixed. | 12:41 |
jtv | great, thanks | 12:41 |
jtv | And the "on|off" bit as well, I see. | 12:42 |
jtv | adeuring: got a review for you! https://code.launchpad.net/~jtv/launchpad/bug-733132/+merge/53009 | 12:47 |
adeuring | jtv: I'll look | 12:47 |
jtv | dankeschön | 12:47 |
=== almaisan-away is now known as al-maisan | ||
adeuring | jtv: the branch looks good. only one detail: FEATURE_FLAG as a variable name does not tell what the feature is about. Could you rename it to something like ENABLE_DERIVED_SERIES_JOBS ? | 13:12 |
jtv | adeuring: I'm in two minds about that… doesn't the module it's in do enough to disambiguate it? | 13:12 |
jtv | I could import it into the test as distroseriesdifferencejob.FEATURE_FLAG | 13:12 |
adeuring | jtv: well, we could have two feature flags in this module | 13:13 |
jtv | That way the name is always disambiguated. | 13:13 |
jtv | Ah I see what you mean. | 13:13 |
adeuring | I prefer names which tell what is done over how things are done | 13:14 |
jtv | Okay, then how about ENABLING_FEATURE_FLAG? | 13:15 |
jtv | Because it is important to my mind that it is the feature flag, not e.g. a boolean that controls the feature. | 13:15 |
jtv | If the test refers to it as distroseriesdifferencejob.ENABLING_FEATURE_FLAG, I think that'd be about as clear as it could be. | 13:15 |
adeuring | jtv: what about FEATURE_FLAG_ENABLE_DERIVED_JOBS? | 13:16 |
jtv | Gets a bit long, and basically for the purpose of repeating the module name. | 13:16 |
adeuring | without say what is enabled, it looks to me still like a label on an electrial switch just saying "SWITCH" ;) | 13:16 |
jtv | Well that would make sense in the context of a little circuit board when you know what the board is for, just not what outside part should be attached to the particular piece of wire you're looking at. | 13:18 |
adeuring | jtv, ok, so... ENABLE_MODULE? or FLAG_ENALBE_MODULE? | 13:18 |
jtv | It would have to say "flag," but I don't see why it should say "module." | 13:19 |
adeuring | well, I still think that its good to indicate what is enabled | 13:19 |
jtv | Yes, but I'm relying on the "distroseriesdifferencejob" to imply that it's DistroSeriesDifferenceJob that's being enabled. | 13:21 |
jtv | I don't think it'll confuse anyone, especially since it's not even being exported—it's just the test that refers to it from the outside. | 13:22 |
adeuring | jtv: ok, for the test distroseriesdifferencejob.WHAETEVER is more or less fine, but _inside_ the module something like FEATURE_FLAG_ENABLE_MODULE would still make more sense to me | 13:23 |
jtv | OK, I can't say I like it much but you have the advantage of a fresh outside look. I'll use that. | 13:25 |
adeuring | jtv: thanks :) | 13:26 |
adeuring | so, r=me | 13:26 |
jtv | Thanks | 13:26 |
bigjools | gary_poster: another quick buildout question - if we have sourcecode deps in the dists tree but not mentioned in versions.cfg, are they used somewhere else or are they safe to remove? | 13:35 |
gary_poster | maybe used somewhere else bigjools. sadly, sourcecode is a separate mechanism | 13:36 |
gary_poster | (and on call :-) ) | 13:36 |
bigjools | gary_poster: darn :/ ok thanks | 13:36 |
allenap | adeuring: Hi Abel. Could you review a tiny branch for me please? https://code.launchpad.net/~allenap/launchpad/fix-librarian-startup-warnings/+merge/53018 | 13:46 |
adeuring | allenap: sure, I'll look | 13:48 |
allenap | Thanks. | 13:48 |
adeuring | allenap: r=me | 13:53 |
allenap | adeuring: Cheers. | 13:53 |
wgrant | le | 13:57 |
wgrant | sinzui: Hi. | 13:58 |
sinzui | hi wgrant | 13:58 |
wgrant | sinzui: You upgraded lazr.restful to 0.17.4 a couple of days ago, right? | 13:58 |
sinzui | I did | 13:58 |
wgrant | 0.17.2 has a regression in exception handling. | 13:58 |
wgrant | See #launchpad. | 13:58 |
sinzui | was that fixed in 17.3 by leonardr | 13:59 |
wgrant | No. | 13:59 |
wgrant | It's still broken in 0.17.4 (which is on prod now) | 13:59 |
wgrant | OOPS-1896STAGING128 | 14:00 |
sinzui | Well I am not going to fix that regression by restoring another regression | 14:00 |
sinzui | I will need to talk to leonardr | 14:00 |
wgrant | Indeed, that's what I was going to suggest. | 14:00 |
wgrant | I haven't filed a bug, since it is 1am. | 14:01 |
wgrant | Can you poke leonard about this when he appears? | 14:01 |
sinzui | My change was to revert the xhtml-in-json because it was being injected into pages without being escaped | 14:01 |
wgrant | Right. | 14:01 |
wgrant | It just pulled in the exception handling changes too. | 14:02 |
sinzui | 0.17.3 does something interesting with exception handling. It fixed some broken tests I saw in 0.17.2 | 14:02 |
wgrant | Ahhh. | 14:02 |
wgrant | I think I see what's going on, maybe. | 14:02 |
sinzui | Reverting that change breaks the test suite :) | 14:03 |
wgrant | Hmm, no, I don't see it. | 14:03 |
sinzui | Which was also why I was not going to land my work...I hand never seen my tests run successfully. | 14:03 |
wgrant | But the 0.17.2 diff looks like a hack :/ | 14:03 |
wgrant | It also looks like it should be using .response_code, not .status... | 14:05 |
LPCIBot | Project windmill build #41: STILL FAILING in 1 hr 8 min: https://hudson.wedontsleep.org/job/windmill/41/ | 14:06 |
sinzui | wgrant: I recall "status" reappeared in response output when I added this version to Lp. I assumed it was because of my change, not leonardr's | 14:07 |
wgrant | Anyway, leonardr will save the world. | 14:08 |
sinzui | wgrant: are you certain 0.17.2 was live? the expose(exception, code) signature was very new. like late last week | 14:09 |
wgrant | sinzui: We rolled out your change (with 0.17.4) this morning, AFAIK. | 14:10 |
sinzui | I had to update my deps to resolve the sugnature change | 14:10 |
sinzui | right, and 0.17.3 was never released. But was 0.17.2 really the version in production. 0.17.1 looks like the version I have last week | 14:11 |
wgrant | Hmm? It broke in 0.17.2, and is still broken in 0.17.4 | 14:11 |
wgrant | Timeouts OOPS like that staging OOPS I gave above. | 14:12 |
wgrant | 0.17.4 was introduced in r12565, and r12568 is now on production. | 14:13 |
abentley | deryck: bzr+ssh://bazaar.launchpad.net/~abentley/launchpad/js-translation | 14:14 |
wgrant | Anyway, night. | 14:16 |
abentley | deryck: http://pastebin.ubuntu.com/578842/ | 14:17 |
deryck | abentley, ci = new CheckItem({identifier: 'id1'}) | 14:20 |
jml | how do I search for bugs that don't have certain tags? | 14:49 |
james_w | jml, https://bugs.launchpad.net/launchpad/+bug/81575 | 14:51 |
_mup_ | Bug #81575: no way to search for absence of a tag <bugtag> <lp-bugs> <oem-services> <ubuntu-qa> <Launchpad itself:Fix Released by allenap> < https://launchpad.net/bugs/81575 > | 14:51 |
jml | james_w: ta | 14:54 |
jcsackett | is it bad that i'm excited a db patch i landed took under 10 minutes? | 15:02 |
* jcsackett figures it probably is. | 15:03 | |
sinzui | Not bad | 15:03 |
sinzui | will your patch break everything? | 15:03 |
* jml trying out new battery. | 15:05 | |
jcsackett | sinzui: no, my patch fixes messages. | 15:10 |
jcsackett | sinzui: it was the visibility db patch. | 15:10 |
jcsackett | sinzui: real question is how long it takes on the weekend super-rebuild. | 15:11 |
=== al-maisan is now known as almaisan-away | ||
rvba | jcsackett: quick question: how did you know how long your patch took to be applied? | 15:51 |
rvba | sinzui: thanks for your review ... I think I misunderstood the word 'resubmit' and did put a red mark on my own proposal ;-). | 15:55 |
jcsackett | does staging have different timeout thresholds from production? | 16:05 |
sinzui | rvba: I'll follow up the review when the diff completes its update | 16:06 |
=== matsubara is now known as matsubara-lunch | ||
=== bdmurray_ is now known as bdmurray | ||
deryck | henninge, still around? | 16:16 |
henninge | deryck: yes, for the moment | 16:17 |
deryck | henninge, need just a quick ack that this looks sane for displaying "not translated" -- http://people.canonical.com/~deryck/in-upstream-msg.png | 16:17 |
deryck | henninge, in your opinion. not asking for a formal ui review ;) | 16:17 |
henninge | that looks good, although we use "(not translated yet)" in other places AFAIR | 16:18 |
deryck | henninge, ok, I'll match that. thanks. | 16:21 |
bac | you still around adeuring? | 16:21 |
=== bac changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | firefighting: - | On call reviewer: adeuring, bac | https://code.launchpad.net/launchpad-project/+activereviews | ||
adeuring | bac: yes | 16:21 |
sinzui | rvba: r=me for code and tests | 16:22 |
bac | adeuring: sorry it took me so long to show up today | 16:22 |
adeuring | well, for an hour or so | 16:22 |
adeuring | bac: no problem :) | 16:22 |
bac | adeuring: i'll take wallyworld's branch | 16:23 |
adeuring | bac: cool, thanks | 16:23 |
adeuring | bac; I must admit that I simply cducked out from looking at the loggerhead stuff -- I have no real clue about it... | 16:24 |
bac | adeuring: you're the best judge of what you can do a good job reviewing | 16:24 |
rvba | sinzui: nice. thx for the careful review. It's precious to me because I can find many layers of different ways to do the same things in the code. | 16:25 |
sinzui | rvba: yes. We are very bad to removing code/test styles that we decide were bad | 16:26 |
rvba | sinzui: I'll have to correct my own changes from last week. | 16:27 |
=== bac` is now known as bac | ||
=== beuno is now known as beuno-lunch | ||
=== matsubara-lunch is now known as matsubara | ||
=== m4n1sh_ is now known as m4n1sh | ||
deryck | adeuring, you still open for reviews? | 17:22 |
adeuring | derycksure | 17:22 |
deryck | adeuring, https://code.launchpad.net/~deryck/launchpad/upstream-empty-display-707825/+merge/53050 thanks! | 17:22 |
deryck | adeuring, I was thinking of taking lunch now, too, but if you want me to hang around for interactive chatter, I can. | 17:22 |
adeuring | deryck: na, I don't want you to become unnecessarily hungry ;) | 17:23 |
deryck | heh, thanks! | 17:23 |
=== deryck is now known as deryck[lunch] | ||
=== beuno-lunch is now known as beuno | ||
adeuring | deryck[lunch]: r=me | 17:41 |
LPCIBot | Project windmill build #42: STILL FAILING in 1 hr 9 min: https://hudson.wedontsleep.org/job/windmill/42/ | 18:07 |
=== Ursinha-afk is now known as Ursinha | ||
=== adeuring changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | firefighting: - | On call reviewer: bac | https://code.launchpad.net/launchpad-project/+activereviews | ||
=== deryck[lunch] is now known as deryck | ||
abentley | deryck: I've written a stub html file to use until henninge and abel's work is ready, but it says "YUI id not defined": http://pastebin.ubuntu.com/578968/ | 19:36 |
abentley | s/id/is | 19:37 |
* deryck looks | 19:37 | |
deryck | abentley, paths are wrong in the script links. Did you copy from the test file? If so, you're now up one "../" level from before. | 19:39 |
abentley | deryck: ah. Yes, I did. mutter. | 19:39 |
allenap | maxb, jam: Did you get reject messages from launchpad-bugs-owner or launchpad-reviews-owner? | 20:17 |
maxb | oh dear, I deleted them without paying attention. Let me oscillate the status of a MP to send some more | 20:17 |
allenap | Thanks. | 20:17 |
maxb | Received: from loganberry.canonical.com (localhost [127.0.0.1]) for <launchpad-bugs@lists.ubuntu.com>; Fri, 11 Mar 2011 20:19:54 +0000 (UTC) | 20:21 |
maxb | X-Launchpad-Message-Rationale: Reviewer @loggerhead-team | 20:21 |
maxb | allenap: ^ | 20:22 |
allenap | maxb: Cool, thanks. | 20:22 |
sinzui | I worry for the 4 kittens in my house. These old bug views are evil. I sense the Monkey god will seek vengeance :( | 20:25 |
allenap | maxb: I've deactivated the membership of ~launchpad from ~loggerhead-reviewers. I'll reply to the thread on launchpad-dev too. I think it's happened because ~launchpad was automatically made a member of ~loggerhead-reviewers when I set it as the owner. | 20:26 |
maxb | allenap: The X-Launchpad-Message-Rationale: Reviewer @loggerhead-team makes me doubt this will fix the issue? | 20:26 |
allenap | maxb: Was that on a new mp? Perhaps the branch reviewer is copied at mp creation. | 20:27 |
maxb | oh, I see your point. | 20:27 |
=== pjdc_ is now known as pjdc | ||
lifeless | matsubara: hi | 20:52 |
matsubara | lifeless, hi | 20:52 |
lifeless | matsubara: how do I land https://code.launchpad.net/~lifeless/oops-tools/limits/+merge/52348 ? | 20:53 |
lifeless | matsubara: or were you going to check it passes tests etc? [it may now] | 20:53 |
matsubara | lifeless, I checked. all tests pass. to land it just set a commit message and set the MP to approved. tarmac will take care of running the test suite and merging on trunk | 20:54 |
matsubara | I'll deploy afterwards | 20:54 |
lifeless | doing now | 20:54 |
matsubara | cool. thanks | 20:54 |
lifeless | done | 20:55 |
matsubara | lifeless, looks like the postgresql instance in the tarmac chroot is not working | 20:58 |
lifeless | matsubara: why the change to vcs-imports/registry ? | 21:34 |
matsubara | lifeless, what change? | 21:34 |
lifeless | matsubara: you removed ~registry from ~vcs-imports | 21:34 |
matsubara | lifeless, did I? I deleted ~launchpad-chr but that shouldn't be related | 21:35 |
lifeless | forwarded to you | 21:36 |
matsubara | lifeless, don't know what happened there, but I suspect it was because I deleted ~launchpad-chr today | 21:40 |
lifeless | might be worth checking that maxb etc can still admin imports | 21:41 |
maxb | I believe I was/am a direct member of ~vcs-imports | 21:41 |
maxb | yes, I still seem to have the access | 21:42 |
lifeless | kk | 21:42 |
LPCIBot | Project windmill build #43: STILL FAILING in 1 hr 12 min: https://hudson.wedontsleep.org/job/windmill/43/ | 22:26 |
=== matsubara is now known as matsubara-afk |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!