[01:05] StevenK: is only workaround to downgrade convoy? ImportError: No module named convoy.meta [01:06] sudo apt-get install convoy/precise [01:06] should do it [01:06] so pkg has been updated in repos? [01:06] No, downgraded. [01:06] That should still downgrade it [01:07] ok,will try thanks [01:07] all good [01:16] wallyworld_: I'm working on it. [01:20] np. i downgraded to the previous version [01:35] wgrant: I don't think I need Provides: convoy, right? [01:35] StevenK: Hopefully only launchpad-developer-dependencies depends on it, indeed. [01:35] So just C/R [01:45] sinzui: I see your progressive-enhancement-ftw branch touches the inline-picker.pt, which has a div inside a span, which is illegal. Any chance you could look at fixing that? [01:46] Not sure what it's doing there, but it's probably simple to eliminate. [01:46] I hope. [03:02] Woo [03:02] * StevenK rips out five self.assertEquals() and replaces it with MatchesStructure() [03:05] wgrant: is it preferred to use a CTE or subsquery to force a distinct to be evaluated before a sort? [03:07] wallyworld_: trick question, there's no point evaluating distinct right before a sort [03:07] wallyworld_: as doing distinct requires sorted data [03:07] You also have to be careful about doing that with resultsets, as Storm will apply the limit to the outside. [03:08] You need to play around to see what performs well. [03:08] wallyworld_: whats the big picture ? [03:08] such an optimisation was done for a query on the accesspolocygrantflat table already though [03:09] lifeless: i am looking at a query which returns a number of rows which when distinct is applied will be far less [03:09] and i need the result to be ordered on one of the columns which distinct will operate with [03:09] Need to know specifics. [03:11] lifeless: wgrant: https://pastebin.canonical.com/64992/ [03:11] i'm experimenting atm with a couple of approaches [03:12] a single query and a bit of python to loop over the result set vs 2 queries [03:12] https://pastebin.canonical.com/64993/ [03:12] the sql pasted would be for the single query approach. the will be many rows with SOME and these need to be reduced down to 1 per grantee [03:13] your current query conflats distinct columns and calculate results [03:13] yes it does, i hadn't finished it yet, just threw up something quickly cause you asked :-) [03:14] indeed, so the thing is you asked about forcing an operaiton order; but that sort of optimisation always happens after you can express what you want basically :) [03:14] so, without the distinct, the result set might be largish. and order by is done first right? [03:14] no [03:14] order by is done depending on the plan [03:14] it may use an index [03:15] it may sort in memory [03:16] ok. there was a bit of sql already refactored and the comment was that we wanted to force the distinct to be done first since the sort by time dominated the query time [03:16] it may be different on each execution depending on the params [03:16] so a sub query was used [03:16] You need to test with both Ubuntu and Launchpad. [03:16] as targets [03:16] wallyworld_: for this case or another case? Tuning is a vicious cycle of iteration and experimentation [03:16] lifeless: another case [03:16] in which case, ignore it. Optimise this separately. [03:17] ok. i wasn't sure if we were dealing with a postgres quirk or not [03:17] s/quirk/generalisation [03:17] postgres quirks are completely situation-dependent. [03:17] You have to test. [03:17] I have a couple of thoughts [03:18] what do you want to show when both an artifact and non-artifact grant are present ? [03:18] or do we prevent that ? [03:18] we show ALL [03:18] but i now need to know of there are SOME also [03:18] whereas before we didn't need to know that [03:20] so previously the query i pasted used MIN(COALESCE(artifact, 0)) and a group by [03:20] if i keep that i need a second query [03:21] or i remove the MIN and have one query with a distinct and order by and a bit of python logic [03:24] lifeless: actually, i take it back. i don't need the 'distinct on', just plain old distinct. [03:25] for my use case [03:26] You also don't care about order there, do you? [03:27] wgrant: it makes the post processing easier but is not strictly necessary. if the distinct is run first, the order by is trivial [03:27] what about https://pastebin.canonical.com/64994/ [03:27] hence my wanting to run distinct first [03:28] you'll get up to two rows for any grantee,policy pair [03:28] one with the min null and True [03:28] one with a min value and False [03:29] it's missing the group by but perhaps [03:29] why would it need one ? [03:30] We need to know (person, person, artifact grant?, policy grant?) [03:30] s/person, person/person, policy/ [03:30] well, this gives you that but not folded into one row [03:31] if you are paginating, you might need the fold [03:31] but if you are paginating, you might want to avoid entire-context processing, which group by will need [03:31] This is post-pagination [03:31] lifeless: the group by is needed because there's a min() in the select [03:31] wallyworld_: oh duh, of course. [03:32] my original query works. wgrant, could you possibly run https://pastebin.canonical.com/64992/ on dogfood, adjusting ids for ubuntu? [03:34] 90ms for me + ubuntu-crashes-universe [03:34] So very slow [03:35] wgrant: how does mine run ? [03:35] Buggily [03:35] wgrant: with an appropriate group by [03:36] wgrant: perhaps https://pastebin.canonical.com/64995/ [03:36] wgrant: does qas have appropriate data ? [03:36] qas has appropriate data [03:36] lifeless: Your thing has no chance of running without a rewrite [03:36] It uses artifact in both an aggregate and a non-aggregate. [03:37] what are the right constants for you + u-c-u ? [03:37] wallyworld_: 120ms [03:37] so even worse :-( [03:37] lifeless: SELECT id FROM accesspolicy WHERE distribution = 1 [03:38] And (21997, 1324721) [03:38] wgrant: maybe a subselect? [03:38] Well [03:38] 72ms [03:39] wgrant: all specific grants atm right ? [03:39] For those constraints, yes. [03:39] Ah [03:39] SELECT DISTINCT grantee, policy, min(artifact), artifact is NULL FROM AccessPolicyGrantFlat [03:39] WHERE AccessPolicyGrantFlat.grantee IN (21997, 1324721) AND AccessPolicyGrantFlat.policy IN (65,66) [03:39] The old query is 80ms for the same data on DF, so the 90ms before wasn't too bad. [03:39] GROUP BY AccessPolicyGrantFlat.grantee, AccessPolicyGrantFlat.policy, artifact is NULL [03:40] ORDER BY AccessPolicyGrantFlat.grantee, AccessPolicyGrantFlat.policy; [03:41] so what's the concensus? [03:42] one was run on dogfood, the other qas so can't really compare [03:43] SELECT AccessPolicyGrantFlat.grantee, AccessPolicyGrantFlat.policy, NOT bool_and(artifact IS NOT NULL), bool_or(artifact IS NOT NULL) [03:43] FROM AccessPolicyGrantFlat WHERE AccessPolicyGrantFlat.grantee IN (21997, 1324721) AND AccessPolicyGrantFlat.policy IN (130423, 130464) GROUP BY AccessPolicyGrantFlat.grantee, AccessPolicyGrantFlat.policy === jtv1 is now known as jtv [03:44] SELECT AccessPolicyGrantFlat.grantee, AccessPolicyGrantFlat.policy, bool_or(artifact IS NULL), bool_or(artifact IS NOT NULL) [03:44] FROM AccessPolicyGrantFlat WHERE AccessPolicyGrantFlat.grantee IN (21997, 1324721) AND AccessPolicyGrantFlat.policy IN (130423, 130464) GROUP BY AccessPolicyGrantFlat.grantee, AccessPolicyGrantFlat.policy [03:44] better [03:44] 78ms on DF [03:44] i haven't seen bool_or before [03:45] I've never had cause to use it before, either. [03:45] But I think it fits well here. [03:45] what's it do? [03:45] It's an aggregate function that computes the boolean OR. [03:45] ah right, nice [03:45] Which is, I think, exactly what we want here. [03:46] well, before the queru produced column values 'ALL' or 'SOME' not true or false [03:46] Yeah [03:46] But that doesn't really make sense any more [03:46] so i could CASE it [03:46] Since we may need to return both. [03:46] sure [03:47] wgrant: so there's so order by there. that would make post processing easier [03:47] but if it adds too much overhead [03:48] You can just stick an ORDER BY on the end [03:48] Doesn't affect performance in this case. [03:48] Since it has to do the hashagg first. [03:48] rightio [03:49] wgrant: seems to work ok locally too. thanks. updating code now.... [03:50] Great. [04:01] Hm [04:02] So it looks like tag searching becomes much faster if I remove all the INTERSECT crap [04:02] wgrant: the bool_or is redundant there [04:02] lifeless: How? [04:03] foo is null is boolean already [04:03] ditto is not null [04:03] I use them for the aggregateness [04:03] Not the boolness [04:04] Hm. I guess since we paginate before this, we could possibly just get DISTINCT AccessPolicyGrantFlat.grantee, AccessPolicyGrantFlat.policy, artifact IS NULL. [04:04] Since we don't need a single row per person [04:04] wgrant: huh, please enlarge [04:04] (on the aggregateness) [04:05] lifeless: I want the aggregate [04:05] Directly requesting a non-distinct bool is not an aggregate. [04:05] oh right, I see [04:05] handy [04:05] But a distinct bool is probably sufficient here, since we don't care about pagination in this query [04:06] EXPLAIN ANALYZE SELECT DISTINCT AccessPolicyGrantFlat.grantee, AccessPolicyGrantFlat.policy, artifact IS NULL [04:06] FROM AccessPolicyGrantFlat WHERE AccessPolicyGrantFlat.grantee IN (21997, 1324721) AND AccessPolicyGrantFlat.policy IN (130423, 130464) ORDER BY AccessPolicyGrantFlat.grantee, AccessPolicyGrantFlat.policy; [04:06] is pretty much the same speed and less ugly, but will return up to two rows per person [04:06] And is sort of the obvious way to go. [04:06] wallyworld_: ^^ [04:06] indeed [04:06] its roughly, except cleaner, what I originally suggested. [04:07] And working :) [04:07] lifeless: Have you reworked the tag searching stuff at all? [04:07] no [04:07] wgrant: i really want one row per person. the query with bool_or is better [04:07] k [04:07] plans are identical [04:07] So just query prettiness, really [04:08] wgrant: and the order by is done outside this bit by the batching stuff i realised [04:08] Well, yeah, (person.id, policy.id) is hardly going to be a user-friendly sort. I assumed it simplified your code somehow. [04:09] it would have but now we have one row per person so it doesn't matter [04:09] ah never mind, forget my comment about batching - different query [04:10] lifeless: https://pastebin.canonical.com/64996/ is what ALL tag search queries look like now [04:10] lifeless: Replacing the EXISTS ( ... INTERSECT ... ) with EXISTS ( ... ) AND EXISTS ( ... ) is about 30 times faster. [04:10] I guess it plans better from the tag counts. [04:11] I guess I'll do it behind a flag and see what happens. [04:11] Because it, like, makes Ubuntu multi-tag searches not take 10s. [04:11] (although it was 20s in the old schema) [04:20] wgrant: I tweaked it for the old schema at one point [04:20] wgrant: I'm glad you can get it better [04:26] wgrant: did you end up making an array for tags ? [04:26] lifeless: Not in this round. [07:07] good mornin [07:42] Grrr... lifeless stole my namespace with lazr.postgresql. [07:45] What do we have besides lazr? Need to package a Python library containing PG helpers. [07:45] lazr.postgresql, maybe? :) [07:46] :-P [07:48] Lot of renaming to move that db patch buildout application [07:59] stub: huh, shove your stuff in there. [07:59] stub: its what its there for [07:59] And the obvious name for lazr.postgresql application has now been taken - might be interesting. http://pypi.python.org/pypi/pgmigrate2/1.2.2 [08:00] hah [08:00] stub: so seriously, put your helpers in lazr.postgresql; theres plenty of namespace within that [08:00] stub: I just hadn't bothered moving stuff it didn't need. [08:00] (into it) [08:00] lifeless: Merging the buildout driven application and my helper library looks like a packaging mess [08:00] stub: how so? [08:01] stub: which helper library ? [08:01] One I'm going to assemble so I can get common CLI, helpers like ConnectionString etc. available for our various scripts (backups, database report) without pulling in a Launchpad tree or cargo culting. [08:02] Been cargo culting so far and finally got sick of it. [08:02] stub: great; buildout should be fine for that. [08:02] stub: its got a very small dep footprint [08:02] stub: and will play nice with e.g. pip or virtualenv (which btw we probably want to do a mass migration to) [08:03] I'm thinking a .deb [08:03] stub: still no problem, I wanted lazr.postgresql to end up deb'd too with a primarily CLI interface. [08:04] Python packages into .deb seem not hard if you are using setup tools. Buildout? [08:04] stub: its still setuptools [08:04] stub: don't overthink it :> [08:04] stub: buildout is for local dev mode; you can totally ignore it as far as delivery of debs is concerned. [08:04] I'm used to using buildout assembing a tree [08:04] separate problems. [08:04] buildout will give you the dev environment. [08:04] The deb stuff will be a separate packaging tree anyhow. [08:05] Yer, just as long as I can get 'python setup.py install' to install mystuff my limited packaging skills should suffice. [08:06] which buildout doesn't affect ;) [08:06] also you might like to use pkgme for deb stuff [08:07] stub: all that said, the -ops are good at getting buildout trees onto machines via deploymgr, so you might be good to go just as-is, with no packaging effort. [08:08] It will end up being used by stuff like lp:losa-db-scripts. Getting helpers on the standard PYTHONPATH seems best to me. [08:08] While you're here, I think there is an issue with your assignees-must-have-visibility policy. [08:08] lifeless: ^^ [08:08] stub: sure [08:08] wgrant: whats issue ? [08:08] lifeless: I've fixed lots of bugs in my company's private project. [08:08] stub: we should do a catchup; after wgrant grills me ? [08:08] lifeless: But I've just left the company :( [08:08] And the extracted database report, which is what I actually want to be working on. [08:09] lifeless: Sure, or tomorrow if it is late for you. [08:09] wgrant: clearly none of the bugs are your responsibility any more [08:09] lifeless: Now all these historical bugs have to be molested, since I no longer have accss. [08:09] stub: it is late, but today is better. [08:09] k [08:10] lifeless: That argument might apply to an In Progress bug. [08:10] wgrant: I don't see a conceptual problem: open bugs *should* be updated. Closed bugs the assignee is just vanity, and its in the changelog for the bug. [08:10] But it probably doesn't apply to a Fix Released one. [08:10] if you consider assignee a next-actor field its clearly irrelevant for F-R bugs [08:11] arguably it should not permit being set there anyhow. [08:11] That's not how the field is defined at present. [08:11] And it has never been used that way. [08:11] (not something we could do today, but if we were starting from scratch...) [08:11] wgrant: actually, it has been used that way. [08:11] Some Ubuntu process bugs use it that way. [08:11] use/used [08:11] But nothing widespread. [08:12] wgrant: I forget which team, but there is/was one that religiously updates it that way. [08:16] wgrant: so I admit its a little awkward, but it is, I think, the best of a bunch of bad options. [08:19] wgrant: allowing data that is inconsistent means we have to have safeguards and doublechecks throughout the system; having assignee imply notification means having it imply visibility (by definition) [08:19] wgrant: if we take any one piece out, the system gets harder to explain and use. [08:20] wgrant: I find it implausible that users will be functionally affected if the assignee is cleared when someone leaves; consider the following identical cases: [08:20] - the user deletes their LP account [08:20] - the user merges their LP account [08:22] wgrant: another way of thinking about it is that having a single identity for interacting with multiple partitioned visibility areas has an inbuilt tension. [08:23] wgrant: if you left canonical, for instance, your google docs would be migrated and the account and all its track record nuked. [08:24] stub: so, skype? [08:24] sure [08:25] lifeless: Assignee doesn't have to imply notification any more than structural subscription does. [09:26] danhg: O hai! [09:26] hey stevenk [09:26] danhg: I'd like to get a text review if you have a moment? [09:26] yeah sure [09:30] * StevenK stabs gpg for being difficult [11:16] hey === jml` is now known as jml [11:17] the bug listing page seems to have no favicon [11:35] never mind. [13:04] Morning, everyone. [13:06] morning [13:06] deryck: morning. [13:06] rick_h_: morning. [13:06] rick_h_: Did you see I fixed convoy? [13:06] StevenK: no, didn't see it. thanks!!! [13:06] StevenK: I'll pull/check it out and reply to the -dev email then [13:07] rick_h_: It's also on asuka at least [13:07] StevenK: awesome [13:07] rick_h_: And we set caching on asuka for +combo [13:07] * rick_h_ assumes asuka is a dev server [13:07] or something [13:07] asuka is staging/qastaging's asppserver [13:07] cool [13:07] *appserver [13:08] rick_h_: We might be in a position to turn on the feature flag on qas and see how much breaks [13:08] StevenK: very cool then === rick_h_ changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: rick_h* | Firefighting: - | Critical bugs: 3.47*10^2 === jcsackett changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: jcsackett, rick_h* | Firefighting: - | Critical bugs: 3.47*10^2 === sagaci_ is now known as sagaci [14:13] Is there a statechart of the Launchpad bug statuses ; I have the list of states, but not the transitions. Or is there a particular piece of the source I can look at to work it out? [15:20] awilkins, not sure what you mean by the transitions. [15:21] awilkins, what are you wanting to understand? [15:21] deryck, Which state leads to which other state : I got an answer in the non-dev channel, apparently you can move to any state if you have the privileges [15:21] I just want to compare it to Bugzilla, etc [15:22] awilkins, ah, ok. yeah, there's no set order. [15:26] looking at MPs now [15:55] * deryck lunches === salgado is now known as salgado-lunch [16:28] benji, bac: have replied to MPs. am available for the next hour to chat. === salgado-lunch is now known as salgado [16:43] rick_h_, jcsackett: do you have time to review https://code.launchpad.net/~sinzui/launchpad/progressive-enhancement-ftw/+merge/103733 [16:44] sinzui: sure thing [17:17] sinzui: ping, ? for you [17:17] hi rick_h_ [17:17] sinzui: so you've wrapped the contents with invisible-link css for many cases [17:18] in a non-js browser situation then, is there any method for these to show up not hidden? [17:18] since this is to replace no-script use cases [17:18] ah [17:19] invisible-link exists the Zope testbrowser, not humans [17:19] the sprite class instead renders an icon instead of text for the human [17:19] ok, ic [17:20] rick_h_, there is a nuance we need to consider [17:21] linx is non-js and non-graphical, so crucial cases of reporting a bug must work without graphics or script. +filebug is such as case. We really want users to see those extra options. There are not edit icons on them [17:22] ah, gotcha [17:23] yea, it's the eternal debate of JS flash to hide things vs hiding by default [17:24] sinzui: so with my icon fonts I've used this: http://pictos.cc/articles/using-icon-fonts/ [17:24] which helps make sure if you don't get the font you get the text [17:24] I wonder if this could be adapted for a pure css solution [17:25] ah [17:25] I tried something like that a few years ago [17:25] yea, I think part of this works because it's a font vs a sprite, but haven't tried it out [17:25] it was rejected as a programmer hack. I think we could get it accepted on the grounds that we care about accessibility. [17:26] yea, it works pretty well ime in my side project and if we can praise it for accessability and lack of JS driven flashing UI it's a win [17:27] Anything that properly sites in the uncode ranges and that we can add beauty too via a web font would be grand [17:27] s/sites/sits [17:28] yea, unfortunately I think most icon fonts aren't sticking to unicode land because of unidoce issues people end up with [17:34] rick_h_: Could you please review https://code.launchpad.net/~abentley/launchpad/celery-everywhere-9/+merge/103723 ? [17:36] abentley: will do [17:38] sinzui: ok, commented, also wanted to bring up alt vs title text for these links since again we're really targeting accessability here [17:39] thank you. [17:40] thank you, look forward to noscript dying [17:49] rick_h_, I already know that we cannot change the broken span in a div markup easilly [17:49] We tried this 18 months ago :( [17:49] sinzui: ok, it looked like it might be a much bigger task, but wanted to note it [17:49] It is quite complicated. I can be done, but that is not the issue that needs to be solved in this branch [17:50] gary_poster: ISTM that Storm does not maintain a mapping of table names to classes. Does that seem correct to you? [17:50] sinzui: understand [17:50] rick_h_. we stopped adding inline editing to the project page because th divs did bad things in element that had to be inline [17:51] abentley, it's been a long time since I looked at that code, but I believe you are correct. [17:51] sinzui: can the reverse happen though, can the spans be turned to divs with inline or inline-block styles? [17:52] No. [17:52] sinzui: ok [17:52] Lp and HTML in general wants form elements to work in line [17:52] gary_poster: I had always assumed there would be one. I also thought having two classes with the same table would be impossible. But if Storm can't tell that there are two classes with the same table, it shouldn't care, either. [17:52] heh [17:52] rick_h_, consider that div can never go in a paragraph [17:53] sinzui: ah right ok. [17:53] rick_h_, you are right about the title, I see I was not consistent [17:53] I will work on this now [17:54] sinzui: np, I'll be around laterish today and can ok any time. Thanks for looking into it. [17:54] abentley, it must reliably be able to determine what class to use to instantiate records from the db; looking for a sec; suspect that this is configuration [17:55] gary_poster: There's a complicated derivation dance used in most Jobs classes; but if BranchScanJob, BranchUpgradeJob etc all were ORM objects with the same table, life would be simpler. [17:55] gary_poster: I think that it relies on the caller of Store.fine to specify what class to use, and class specifies table. [17:56] s/Store.fine/Store.find [17:57] abentley, yes, I think you are right! A very interesting idea [17:58] Crazy idea abentley: you could maybe even pass a (single) factory, depending on how loose the contract is for the first argument to store.find [17:59] if it just has to be a callable with a __storm_table__ ... [18:00] you could create different objects depending on one or more columns [18:00] May or may not be a horrible hack :-) [18:01] __new__ might also lead down interesting, horrible paths [18:02] if the contract is tighter than "callable + __storm_table__" [18:02] gary_poster: So, Store.find does appear to defer to the caller: http://pastebin.ubuntu.com/947827/ [18:03] cool [18:05] gary_poster: Unfortunately, my current work kinda assumed that I could serialize an IRunnableJob by writing out its table and id. [18:05] ah [18:31] jcsackett or rick_h_ -- I've got a branch killing doctests for review. [18:31] deryck: cool, almost done with abentley's stuff and I can get right onto that [18:32] rick_h_, cool, thanks! It's at: https://code.launchpad.net/~deryck/launchpad/refactor-editemail-doctest-363916/+merge/103718 [18:35] deryck: ok, loading up now. Man, where's that achievement system from jono. I want a reviews badge for today lol [18:35] heh [18:55] deryck: #2 is just for my own curiosity as searching for doc gets me a ton of stuff [18:57] rick_h_, so #1 -- I can underbar the create methods. I only did the assert one differently, so it wouldn't be mistaken for any self.assertXXX methods provided by the test case classes.... [18:58] rick_h_, #2 is due to the error message being an instance in one case, and unicode in all the others. [18:58] rick_h_, #2 cont. I think some of the form magic calls doc on the widget to get the error string. [18:58] * deryck is re-reading #3 now :) [18:59] deryck: ok yea wasn't sure what .doc came from that seemed to imply it converted the input to unicode [18:59] deryck: I've been confused on #1 before as usually personally I'd _private things that weren't tests but were used but then again things like setUp/tearDown and all that aren't as well so I guess it goes either way [19:00] deryck: #3 just says that each unit test should start with a comment about what's being tested according to the testing style guidelines [19:00] tearDown shouldn't be used :) [19:00] rick_h_, yeah, that's why I don't normally underbar something unless I need to signal it is somehow different. [19:00] and wasn't in this case for the record, just comparing the names of non test_methods [19:00] rick_h_, but if you want me to change either for consistency, I don't mind. [19:01] hi lifeless :) [19:01] right, this only struct me because it did both, I see your point though now deryck. Up to you there [19:01] deryck: o/ [19:02] rick_h_, so can you point me at a line in that wiki your referring to. We're inconsistent about comments in unit tests, and I followed the example of the other tests in that file. [19:03] deryck: under "Python test cases" #3 [19:03] rick_h_, ah, see it now thanks. I can update the other tests in this file then too. [19:04] rick_h_, and you know you're a new reviewer. ;) That's a lot of wiki doc to read thoroughly. :) [19:04] I think that line is too proscriptive; 'test intent should be understandable' is a much better rule [19:04] deryck: so jcsackett says I'm going to be set free for tues [19:04] lifeless: come on, I'm a fan of the comment string for a nice readable line in the error reporting :P [19:04] don't rain on my parade [19:05] rick_h_: in the runner output? All my runners disable that as an antifeature [19:05] lifeless: yea [19:05] I feel like we should have something akin to "You might be a redneck" jokes sometimes.... [19:05] "You might have a crazy test system if...." [19:05] hah [19:06] it requires multiple huge wiki docs to explain how to write good tests. [19:06] :) [19:06] well test names can be a bit shorter if you have a nice sentence on wtf just blew up in that first comment line. I like that as someone that blows up other peoples testes a lot lol [19:06] I really don't mind adding a comment. Just kidding around. [19:08] I'm just sticking up for my anti features :) [19:28] rick_h_, I replied and pushed a change to verify that widget-position-ext is not needed: https://code.launchpad.net/~sinzui/launchpad/progressive-enhancement-ftw/+merge/103733 [19:29] sinzui: saw that, so the two items are the alt tags and the hidden by default text of the links right? [19:29] did you want to worry about the hidden text bits as a seperate branch/item? [19:29] and I can approve it as is with the understanding the alt text can get added in? [19:30] rick_h_, I updated my reply. alt tags never EVER worked on anchors [19:32] rick_h_, title is universal and the only true mechanism to use in the 2000's [19:34] sinzui: ah ok, sorry I was looking at examples at the start wich are tests anyway [19:35] :) That is my trick [19:35] sinzui: thanks for the updated comment. Marked ok [19:35] fab. [19:36] * sinzui reports bug to remove widget-position-ext source-dep === rick_h_ changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: jcsackett | Firefighting: - | Critical bugs: 3.47*10^2 [20:10] rick_h_, the http://pictos.cc/font/ is really great. I want to build something with it [20:28] jcsackett: Could you please review https://code.launchpad.net/~abentley/launchpad/efficient-universal-source/+merge/103768 ? [20:28]