[00:10] thumper: you have an answer for that bzr packaging question? [00:17] bzr packaging question? [00:26] maxb: + [00:26] maxb: the version of bzr shipped with lp is 2.2.0 [00:26] sorry, just back from lunch [00:26] hmm. probably time to get to 2.2.1 [00:26] we need to upgrade to either 2.2.1 or 2.2.2 and there's a timing issue that thumper needs to have input on [00:27] Isn't there a 2a conversion bug fix we really really want in 2.2.1? [00:27] wallyworld: lets get 2.2.1 in now [00:27] yes. but there's also a spin wait issue fixed in 2.2.2 [00:27] we can get 2.2.2 when it is released [00:27] ok 2.2.1 it is [00:34] back [00:34] thumper: the oops was new, it should have synced now [00:35] leonardr: A thought on web performance [00:35] leonardr: if its easy to use an API badly, people will use it badly. [00:36] leonardr: group based entry and exit signatures for high latency RPC is a way to make it easy to use an API efficiently and hard to use it poorly. [00:37] lifeless, can you spell out "group based entry and exit signatures for high latency RPC"? are you talking about setting up batch operations and callbacks? [00:38] lifeless: oops still not matching [00:40] thumper: :( [00:40] leonardr: batch operations is one way of thinking about it [00:41] leonardr: less-than-one-roundtrip per object returned from lookups, a powerful query language, changes to multiple objects in <3 round trips - that sort of thing. [00:42] leonardr: but also simply moving away from 'an object is retrieved by reading a location' as an idiom. [00:43] lifeless: do locations now designate sets of objects, or something else? [00:47] leonardr: Perhaps API functions. I don't know - I was replying to your comment about streamlining being orthogonalish to making performance fast [00:47] leonardr: the key points I wanted to note are: [00:47] - if its easy to use in a poor way, people will (and then blame us) [00:48] - for high latency environments (e.g. SQL, let alone internet ops) operations on group with decomposition for single cases work better than operations on atoms with composition to talk about many things. [00:48] leonardr: I'd be delighted to help frame the problem, satisfying criteria, and brainstorm with you on what changes we should do. [00:49] thumper: ignore that mp email - typo in branch name. will redo [00:49] leonardr: I don't want to suggest specific solutions [at least, not without really focusing on it - its nontrivial] [00:49] wallyworld: ack [00:50] lifeless: sure. my main concern is that although "difficult to use poorly" is possible, it doesn't go very well with "easy to use on an absolute level" [00:51] leonardr: so, 'easy to use in a slow way' is different to 'easy to use in a fast way' [00:51] i can imagine systems like the one you're imagining, but i see users regarding them as further from their expected "web api" experience than what we have now [00:51] leonardr: the slow way case is something to avoid, because users are dissatisified and we pay more. [00:53] i'm certainly not arguing *for* anything being slow, but i think the price of making it really easy to get started may be that the thing you create when you get started is slow [00:53] leonardr: All - as far as I know without exception - of our current users complain about performance. And the usability angle seems, to me, to be tied into OAuth (which we need) as well as documentation (which is IMO poor compared to (for instance) the AWS web API docs) [00:54] leonardr: now, much of the performance issues may be request completion times, not latency - we don't really know [yet]. [00:54] maybe by making the web service uniform we can "free up" some complexity that we can then use on a more complex, but faster, usage model [00:54] leonardr: and thats why I'm not personally planning on focusing on the API until we have a 1 second 99% completion time with no pages that violate that. [00:55] leonardr: thats an interesting angle [00:56] lifeless: that kind of bank shot is the only way i think that usability has much to do with performance right now [00:56] i think we're in a good position to massively improve usability without affecting performance at all, while making it easier for us to optimize specific cases [00:56] but as i told gary, i don't see any deep connection [00:56] when you talk usability, I think object serialisation, URL routing and documentation. [00:56] What are you thinking about when you talk usability ? [00:56] lifeless: same kind of thing [00:57] especially documentation [00:57] so, I guess I'd say that right now. [00:57] We should - based on jml's strategic goals - just focus on performance. [00:57] for the API [00:59] (riffing) [00:59] lifeless: that's legitimate, but my gut feeling is that we'll either be not changing the framework at all, or adding complexity [00:59] there are I think two broad aspects to API performance [00:59] *) implementation of specific calls [00:59] *) structure of the API [01:00] in the current structure the implementation of specific calls is multiplied by latency because we have a chatty model [01:01] so we can improve performance in two broad ways: address the structural issue, at which point specific call implementations will have a diminished but still significant impact (less calls), or we can polish the implementation of specific calls up, so that we can accurately assess the [01:01] overall balance between latency and service time [01:02] lifeless: my general belief is that the current model, chatty as it is, is the one that makes most sense to python programmers because it comes the closest to letting them pretend they're working with local python objects (this was our original goal) [01:02] obviously, pretending that the network boundary isn't there is going to cause problems [01:02] leonardr: We chatted about this on-list. [01:02] leonardr: I'm of the considered opinion that that goal is a problem. [01:03] that's fine, but there's a price to be paid: the alternate system will only be "easy to use well" in the sense that it's easier to use well than poorly [01:03] leonardr: our us of an ORM in launchpad with similar goals (make it look like regular POPO code) is a direct cause of the performance quagmire we're in. [01:04] leonardr: ec2's API has /massive/ adoption and it has paid that price. [01:04] FWIW, I share the view that pretending that remote objects are like local objects isn't good, because they aren't in terms of performance, concurrent users, connection reliability, etc. [01:04] apples and oranges to be sure. [01:04] i'm fine with the direction this is going but i feel very uncomfortable putting the "easy" description anywhere near it [01:05] sure [01:05] strip that out, its pretty subjective. [01:05] ok [01:05] vision: the default way of using Launchpad APIs will be: [01:05] - fast [01:05] - correct [01:05] - obvious [01:05] I don't think lifeless meant "easy" in the sense of a DWIM API, just that the APIs should be high on the rusty scale. [01:06] right [01:06] 10 please [01:06] spiv: does not compute, is rusty a person or an adjective? [01:07] http://sourcefrog.net/weblog/software/aesthetics/interface-levels.html http://ozlabs.org/~rusty/index.cgi/tech/2008-03-30.html http://ozlabs.org/~rusty/index.cgi/tech/2008-04-01.html [01:07] (I like the first link's pithy one-page summary, but the second and third are from Rusty himself and go into a little more detail) [01:07] ok [01:08] (And add a couple more levels?) [01:08] "getting it wrong" here meaning "taking a long time" or "requiring a lot of round trips" [01:09] three things I think [01:09] the two you specify [01:10] and thirdly doing something not obvious right - like squashing someone elses change to a bug without warning, adding a comment to the wrong bug, etc. [01:10] lifeless: if i may sum up my pov from a planning perspective, if we are going to go ahead and do a totally new web service, it's worth investigating a this-ish way to do it. but this morning i heard that our work wasn't to be coupled with the internal api work -- not that things can't change within a day [01:10] I know you've been extremely careful about that, I add it here so that when we talk with *other people* there is no confusion [01:11] ok [01:11] actually and a fourth thing [01:11] what we're talking about is a new web service, possibly with a new custom client, possibly not. if we leave the old web service intact, people will use it instead and get bad performance [01:11] the 'obvious' that I mentioned a page or so up. [01:12] yeah, i meant to click on that to expand [01:12] Even if its not like POPO, it should be obvious how to achieve something. [01:12] (plain old python objects) [01:13] lifeless: so, like the way that mapreduce is obvious? [01:13] leonardr: rotfl [01:13] uhm [01:13] * leonardr semi-serious [01:13] we give you two simple concepts that may not be what you've encountered before, and the system is built from those, and it's incredibly scalable [01:14] here is a definition of obvious that I like: Once I've read the overview docs and played with a hello-world equivalent, I should be able to guess at the right place to look for the details on achieving something. [01:14] leonardr: yes, in that regard mapreduce very much meets the definition of obvious I'm giving. [01:15] leonardr: finding good axioms (like mapreduce) can be a great way to have a very clean very fast system [01:15] lifeless: in that case i'd like to reiterate that we may have to deliberately break backwards compatibility to stop tempting users with popos [01:15] leonardr: so, separation of concerns here [01:16] *) We need a revamped API that /can/ be fast, correct, obvious all at once [01:16] *) We need to transition users to this revamped API [01:16] ok [01:16] *) We need to keep supporting the older API in *some* fashion for *some time* [01:16] *) We need to keep meeting the web UI's ajax needs. [01:17] (This may be a non-API problem. Or it might be something we do simultaneously. It would be nice to keep the current 2-birds 1-stone approach) [01:17] leonardr: on the in-process API stuff [01:18] lifeless: after what i've seen this year, if we have a specialized ajax service, i would not put it past our users to hack into it just so they can keep using pops [01:18] popos [01:18] leonardr: I wouldn't couple them together. The in-process stuff has a much lower churn cost and will involve experimentation. Lots of it. [01:18] leonardr: I think the revamping of APIs needs room to experiment and breath too [01:18] leonardr: but there's no reason why it should try the same things at the same time. [01:19] leonardr: if we decide later on that the things are just so darn similar, we can focus on harmonising them at that point. [01:19] lifeless: see if this interests you [01:19] let's stipulate that right now the web service is a big bushy mess [01:20] so stipulated [01:20] the thing i planned out last year, but haven't been able to tackle just yet, will comb its hair and make it look presentable, without actually getting rid of any of the hair [01:21] but, once the hair is in the appropriate place (and this is the place where the analogy falls apart), it may resemble something within spitting distance of a "sets and ways of operating on sets" type idea [01:22] ok [01:22] so I've no particular preconception about implementation or route-to-get-there. [01:22] improvements to what we have are still improvements. [01:23] at that point we may be able to go from 100,000 hairs all perfectly arranged to a single smooth piece of plastic (to bring back the analogy despite it still not working) [01:23] as i get back into the stuff i wrote last year, i will keep this alternate design in mind, and see whether we can really get there incrementally [01:24] awesome [01:24] spiv: that bzr 2.2.1 upgrade has been approved and is currently being landed via ec2 [01:27] lifeless: with the reference to tempting people use popos etc *by design*, given the impedance mismatch between layers and the distributed computing implications and the resulting performance/robustness issues etc, i'm happy we seem to be moving to a model where it's recognised that may no longer be the best approach :-) [01:36] * thumper relocates [01:37] We have an SSO OOPS in #launchpad. Where should the user be sent? [01:37] * mwhudson is tempted to say "coventry" [01:37] I wonder if they've revived the support link... [01:37] * wgrant goes hunting. [01:38] Aha, it is back. [01:41] wallyworld: yay, thanks! [01:41] spiv: np. not sure how long it will be held up in ec2 :-) [01:45] Project devel build (184): SUCCESS in 3 hr 34 min: https://hudson.wedontsleep.org/job/devel/184/ [01:45] * Launchpad Patch Queue Manager: [r=deryck][ui=none][bug=670352] Prevent {count} from showing up on [01:45] official bug tags management page when item.count is undefined. [01:45] * Launchpad Patch Queue Manager: [r=leonardr][ui=henninge][bug=636000] Wraps configuration links in [01:45] the product involvement portlet with a collapsible that starts [01:45] collapsed when all configuration steps have been taken. [01:45] * Launchpad Patch Queue Manager: [r=jml, [01:45] mbp][ui=none][bug=645768][no-qa] Officially added a new test fixture [01:45] to help with the use of feature flags. [01:45] * Launchpad Patch Queue Manager: [r=leonardr][ui=none][no-qa] Integrate the examples added to the [01:45] launchpadlib docs by https://launchpad.net/arsenal [01:45] * Launchpad Patch Queue Manager: [r=gmb][ui=none][bug=664571] It's now possible to update an existing [01:45] BugSubscription to have a new BugNotificationLevel. [01:45] * Launchpad Patch Queue Manager: [r=mars][ui=none][bug=532055] Fix grammatical errors that show up [01:45] when integrating a desktop with the web service. [01:45] * Launchpad Patch Queue Manager: [r=allenap][ui=none][bug=664096] Allow the bug reporter to transition [01:45] away from Fix Released bug task status. [01:47] StevenK: yo [01:55] jelmer: Thanks. [01:58] wallyworld: indeed. [01:58] holy cow. how many times is the code page for projects going to change? lmao [01:58] wallyworld: I think you can write tasteful explicit popo stuff, but its often a bad idea ;) [01:58] cody-somerville: hmm ? [01:59] lifeless, the link to pending reviews for a project seems to have moved several times in the last few weeks on the code.launchpad.net/$PROJECT page. [02:06] lifeless: Hm? [02:08] StevenK: can you please change hudson to not publish subsequent successes [02:08] lifeless: I've changed it to 'failure and fixed' [02:09] thank you! [02:30] cody-somerville: yeah... bit of a PITA IMO [02:51] wallyworld: ping [02:51] thumper: yo [02:52] wallyworld: I vaguely remember you using a method in a test that got notification messages out of the response object [02:52] wallyworld: do you remember it? [02:52] makeQuestion [02:52] um, no not that [02:52] you mean for the branch alias stuff? [02:53] yeah [02:53] it's in test_launchpad, near the top from memory. i'll have a look [02:55] thumper: lib/canonical/launchpad/browser/tests/test_launchpad.py, there's a _validateNotificationContext() method [02:56] i think this is what you are after? [02:56] wallyworld: ta, and yeah, I think so [03:06] * thumper shaves a yak's butt [03:07] thumper: careful of the dags. they're a lot bigger than on sheep [03:08] * thumper ducks the dags [03:08] ewww [03:39] boom- lp.soyuz.windmill.tests.test_ppainlineedit.TestPPAInlineEditing [03:41] lifeless: And here I was about to tell you that db-devel is at 100% and devel is at 80% in Hudson [04:24] Hm, the QA bot just de-qa-ok'd a whole lot of bugs. [04:24] le sigh. Yes. We just moved to a new devpad [04:24] 100GB more disk and more memory. [04:25] And more flakiness? [04:25] nah [04:26] but we had some migration friction [04:29] * StevenK smacks the QA tagger [04:31] wgrant: in fact, some of its changes are totally right [04:31] multiple landings linked to the same bug [04:32] Hmm. [04:56] whats the magic duck to wave to get 'current user' in lp code ? [05:02] getUtility(ILaunchBag).user or something like that. [05:02] But if you do that, you will be haunted forever. [05:02] * lifeless prepares to be haunted forever [05:03] actually, its a participation lookup I need [05:04] interaction.get_current_principal [05:04] You could do that. [05:04] But that's used less than LaunchBag. [05:07] OTOH its correct. [05:07] LaunchBag is not? [05:07] It's ugly, but not incorrect TTBOMK [05:08] its redundant [05:08] that permits skew [05:08] skew leads to bugs [05:08] use the anger [05:14] wgrant: although arguably in this case its ok. [05:14] * lifeless tosses and turns [05:22] StevenK: ping? [05:35] lifeless: Hm? [05:37] StevenK: spm was waiting to help you with qa [05:37] StevenK: you disappeared without saying anything [05:37] StevenK: so we were trying to get ahold o fyou [05:51] I wonder if PQM can get into testfix in the next half hour. [05:51] If it doesn't, I'll be having a branch land first time :( === almaisan-away is now known as al-maisan [07:39] Grar. [07:40] Indeed it did not land the first time. [07:40] It was submitted. [07:40] But nothing. [07:40] dinner time [07:41] jelmer: What did PQM whinge about this time? [08:03] does anyone know what sends mail for merge proposals ? [08:06] looks like merge-proposal-jobs === al-maisan is now known as almaisan-away [08:10] lifeless: I believe that's the case. [08:10] lifeless: Could you check the PQM history to see what happened to my branch? [08:10] nom nom nom [08:10] Clearly. [08:19] jml: https://code.launchpad.net/~lifeless/launchpad/recipes/+merge/40050 [08:19] * lifeless steps away === almaisan-away is now known as al-maisan === al-maisan is now known as almaisan-away === almaisan-away is now known as al-maisan [09:10] Howdy [09:32] good morning === al-maisan is now known as almaisan-away === almaisan-away is now known as al-maisan [10:28] jelmer: Ah, yay :( [10:29] Yet Hudson remains happy. [11:00] Morning, all. [11:33] morning === mrevell is now known as mrevell-lunch === mrevell-lunch is now known as mrevell [12:59] StevenK, thanks for setting my MP to 'Work in Progress'. I forgot you should do that for larger needs-fixing branches. === fjlacoste is now known as flacoste === matsubara is now known as matsubara-lunch === al-maisan is now known as almaisan-away === matsubara-lunch is now known as matsubara === deryck_ is now known as deryck === deryck_ is now known as deryck [15:56] flacoste: hey [15:56] hi jml [15:56] flacoste: I was told recently that we don't have morphing dialog widgets yet [15:56] we don't [15:57] flacoste: I'm surprised [15:57] why? [15:57] flacoste: they were a very hot topic two years ago [15:57] they were [15:57] flacoste: why didn't we do them? [15:57] because we never reach a point that we had a workflow that needed them [15:57] we actually have now [15:57] we have a wizard widget [15:58] which is going to see some use [15:58] that widget should have the morphin behavior === Ursinha is now known as Ursinha-lunch [15:58] we have a wizard widget? [15:58] if it doesn't have already [15:58] it's in lazr-js [15:58] who's planning on using that? [15:58] and deryck has a branch adding it to launchpad [15:58] rockstar had a use for it [15:58] and I think we are using it for the new subscription stuff [15:58] tbh, I don't care about the morphing part. I care about usability & consistency w/ the rest of Canonical web stuff. [15:58] flacoste: cool. [15:59] flacoste: thanks. that helps :) [15:59] jml, if only we could get a new lazr-js landed... [15:59] anything else in canonical does morhping yet? [15:59] rockstar: does your wizard widget do morphing? [15:59] flacoste, no. [15:59] flacoste, I was going to do that after the fact. [16:00] flacoste, but the fact that it's been pretty difficult just to get this lazr-js upgrade in really killed momentum there. [16:00] rockstar: I have every confidence in you [16:00] rockstar: you can do it. [16:00] jml, I know I CAN. It's whether or not I have the time. :) [16:00] rockstar: do you have anything more important to do than make recipes rock? [16:01] jml, I suspect my rotation into U1 will provide a bit more time for lazr-js hackery, since I'll be doing mostly js work anyway. [16:01] lunch time === Guest63625 is now known as jelmer === benji is now known as benji-lunch === beuno is now known as beuno-lunch [16:42] danilo: where are we at with importing upstream translations? [16:43] jml, importing them into LP projects works, we are finishing automatic import into Ubuntu from there [16:44] danilos: and once they are imported into Ubuntu, they'll be available as (specially marked?) suggestions for Ubuntu translation? [16:45] jml, no, they are already available as suggestions, but we don't really want to set them up all because migrating is going to be harder later [16:45] jml, they will be automatically used in Ubuntu [16:45] danilos: " migrating is going to be harder later"? [16:46] jml, well, in order for us to scale, we're actually going to be using the same table rows for both upstream and Ubuntu translations (fwiw, more than 85% of them are identical) [16:46] jml, so, if we import all upstreams now, we'd have to migrate when our current feature work gets rolled out [16:47] jml, and doing any live migration is slow and painful, and even though we'll have to do some, we want it to be minimal [16:48] danilos: hmm. I think I understand. Mind if I try to say the same thing in my own words? [16:48] jml, not at all :) [16:48] danilos: we can import translations into LP projects today; [16:49] danilos: we have WIP right now to automatically import those into Ubuntu, making those imported translations the actual translations for Ubuntu [16:49] danilos: we also need to do some data entry to set up imports for all of the interesting projects [16:49] jml, that's right [16:49] danilos: but we aren't going to do that yet because we need to do some data migration first, in order to be even remotely scalable [16:49] is that it? [16:49] jml, that final thing you said is the work that is ahead of us as well [16:50] jml, well, one before final ("do some data entry") [16:50] jml, as for the final thing, yes [16:51] danilos: I'm not sure what you mean by that. Do you mean there's also current programming work involved in doing it? [16:53] jml, how about a quick call [16:53] danilos: ok :) [16:54] jml, mumble has not really worked for me today, but let's try again :) [17:02] morning [17:03] lifeless: hi [17:03] oh hai [17:04] danilos: we have exports already, right? [17:05] jml: when are we talking [17:05] flacoste: ^ [17:05] lifeless: in 55mins time [17:06] jml, we have some exports targeted at upstreams, but it's not really what'd we call really a feature as part of seamless process if anyone wanted to use it [17:07] danilos: thanks. [17:07] Does anyone remember how to deal with community contributions to lazr code? [17:07] It's a long time since I've done it. [17:08] allenap: poke them in the eye, take their money and run for the hills? [17:08] allenap: hmm, maybe I'm thinking of something else. [17:09] allenap: what makes it different from dealing w/ community contributions to LP? [17:09] jml: That'll do though :) [17:09] jml: I haven't dealt with one of those in a while either. [17:10] jml: I assume I need to check that they've signed a contributor agreement. Then I wondered what's the accepted way of landing to (in this case) lazr.restfulclient. [17:10] allenap: I think that's pretty standard across Canonical [17:15] * lifeless hates on testfix [17:15] you know what I think would be most useful [17:15] an indicator that we're in testfix [17:15] or not [17:20] lifeless: bug 424060 (also the related bug 422964) [17:20] <_mup_> Bug #424060: Impossible to know whether we are in testfix [17:20] <_mup_> Bug #422964: testfix mode should stop the queue, rather than rejecting new items

[17:20] jml: ah === almaisan-away is now known as al-maisan === benji-lunch is now known as benji === beuno-lunch is now known as beuno === Ursinha-lunch is now known as Ursinha === brianchidester is now known as brianchid === salgado is now known as salgado-dr === al-maisan is now known as almaisan-away [18:56] ah, wifi again. [19:00] wgrant: around? I'd like to understand bug #645620 better. [19:00] <_mup_> Bug #645620: Deleting recipe leaves SourcePackageReleases with no traceability [19:01] leonardr: if I want to extend the information exported by lazr.restful which would need to use the Request object, might there be a way to adapt Entry or ResourceEntry or somesuch so that when fields are extracted from my adapted object, then my own Entry could inject it's on context sensitive information? [19:01] err, s/context sensitive/request sensitive/ [19:02] cr3: i kind of think you want to create a new resource type? [19:02] can you spell out the request/response you want to do? [19:06] leonardr: I'm not sure if I can just define a new resource type because I think I'd need to adapt it for another request interface as well, and all that [19:07] cr3: in that case i need a little clearer picture of what you're oding [19:07] leonardr: for example, lets say I want to attach the version to objects returned by the restful interface, obj.version [19:08] cr3: this is the web service version, or something else? [19:09] leonardr: yes, web service version [19:09] leonardr: I realize it's redundant information because I'm making a request against a versionned url, but I'd like the remote object to carry that information for debugging purposes [19:10] cr3: ok, the best thing might be to subclass EntryResource and register your subclass wherever EntryResource is retrieved [19:10] benji might be able to put that better than i [19:11] leonardr: if someone could figure how to make IJSONPublishable(obj) in _resource.py return anything other than EntryResource, that'd be awesome! [19:12] * benji reads [19:12] cr3: couldn't you register your own IJSONPublishable adapter for your objects? [19:14] leonardr: I tried and it didn't work, I'll try to remember why... [19:16] a custom IJSONPublishable adapter sounds to me like the way to go [19:16] ...which would probably be a subclass of the stock adapter [19:16] leonardr: my understanding is that I need to adapt EntryResource to provide the IJSONPublisher interface, but that never gets resolved in ResourceJSONEncoder [19:17] benji: class Foo: implements(IJSONPublishable); adapts(EntryResource); def toDataForJSON(self): import pdb; pdb.set_trace(); never gets called [19:18] cr3: sorry, benji's -fu in this matter is stronger than mine, and i have to work on other stuff [19:18] cr3: you have to register the adapter so the component machinery knows it exists [19:19] benji: I also had something like this in my configure.zcml: [19:20] cr3: don't you want something like adapts(EntryResourceWithVersion) instead of adapts(EntryResource)? [19:23] benji: I meant EntryResource literally though, to override the one in _resource, not just for a specifically adapted class+version [19:23] * cr3 had to lookup the latest lazr.restful code just in case "EntryResourceWithVersion" actually existed :) [19:23] :) [19:23] so you want the version on all objects then? [19:24] hmm, I'm surprised you didn't get an error on start-up, it sounds like you've created a conflicting registration (two adapters for the same set of interfaces) [19:24] benji: I'd like to make a best effort, so if I could override EntryResource with my own toDataStructure or somesuch, I could try a few things [19:24] is there a branch I can see or can you pastebin the diff or something? [19:25] benji: I worked on that yesterday evening and didn't get anywhere, so I deleted everything thinking I was going down the wrong path [19:26] it sounds like the right path to me, you want to replace one component with another (slightly different) one; that's what they're for :) [19:26] benji: just to make sure I understand correctly though, I should be aiming for "return IJSONPublishable(obj).toDataForJSON()" in ResourceJSONEncoder to return my own IJSONPublishable implementation in order to augment the data normally returned by EntryResource.toDataForJSON, right? [19:27] benji: err, "IJSONPublishable(obj)" should return my own IJSONPublishable..., the complete call should return the data :) [19:30] cr3: right (in other words "IJSONPublishable(obj) should return the result of your adapter (which is a class that /implements/ IJSONPublishable) which will be something that /provides/ IJSONPublishable (an instance of your class)" [19:31] benji: awesome, if you happen to have an example somewhere, that might help. otherwise, since I seem to understand what's going on, I'll probably figure it out eventually :) [19:32] benji: by the way, good work on the whole registration of adapters and interfaces in lazr.restful, pretty cool stuff! [19:32] cr3: I don't have an example at hand, but it sounds like your previous attemt was very close [19:32] benji: I'll make sure to keep the code if I get blocked again :) [19:32] :) [19:34] Leonard deserves the credit for anything nice in lazr.restful and Jim Fulton gets credit for the Zope component framework [19:34] actually i bet flacoste deserves the credit for what cr3 is mentioning [19:35] sounds like a few people making a project come together nicely, as far as I can see. I'm jealous :) === matsubara is now known as matsubara-afk [22:19] has anyone seen a storm query replace a condition with FALSE? [22:34] jcsackett: no [22:41] abentley: Hi. [22:41] wgrant: doh. EOD and I have company. === Ursinha is now known as Ursinha-afk [22:42] Heh, sorry. [22:52] wgrant: hi [22:53] wgrant: I'm about to head out to lunch, but I know a little about what abentley was going to talk to you about [22:53] wgrant: bug 645620 [22:53] <_mup_> Bug #645620: Deleting recipe leaves SourcePackageReleases with no traceability [22:53] thumper: What do you want to know about it? [22:54] I think we were wondering how to create the traceability [22:54] perhaps through making the recipe registrant the uploader? [22:54] Don't delete things. [22:54] wgrant: not deleting things isn't really an option [22:54] we should allow people to delete things [22:55] Deleting a semantic object doesn't necessarily require removal of the underlying datastore: one can have a "deleted" flag, or similar. [22:57] thumper: Normally we record the signing key used on the changes file. [22:57] persia: sure [22:57] thumper: That is clearly not possible here. [22:57] So we agreed that the SPRB would be recorded. [22:57] And now you're nullifying that. [22:58] hmm... [22:58] * thumper has to run, but perhaps we could talk more after lunch [22:58] Sure. [22:59] jelmer: Hi. Could you try to land my branch before we get into testfix again? [22:59] wgrant: Yes. [22:59]