[12:32] <kiko> ddaa, I think that caching of images/other references would be a much greater speed improvement than your former suggestion, tbh.
[12:33] <ddaa> I think that the caching issue is tied to the https issue, isn't it?
[12:34] <ddaa> And they are two sides of the same coin. Improving perceived speed involves improving actual speed, but also providing early feedback.
[12:38] <kiko> ddaa, yeah, it is tied to the https issue. but that would be the largest speed gain we could produce today.
[12:39] <ddaa> ack, I thought that streaming pages could be magically produced by the right zope incantations.
[12:39] <ddaa> I certainly see nothing in TAL that would prevent that.
[01:02] <elmo> ehm, so.  lightweight checkouts are cool and all
[01:03] <kiko> elmo, but...?
[01:04] <elmo> ah, nm, let me try something before making myself look stupid(er)
[01:05] <LarstiQ> elmo: you have quite some credit to burn through before that happens though.
[01:26] <lifeless> elmo: also, #bzr may be better
[01:28] <elmo> lifeless: I doubt it ;-) it was how do I implement this on sodium question
[01:28] <elmo> but I'm muddling through
[01:28] <elmo> p.s. y'all suck at documenting LP development, kthx
[01:30] <lifeless> elmo: on sodium? 
[01:35] <elmo> lifeless: I'm trying to work out how to do lightweight checkouts without having to sync my lightweight-but-still-way-too-large-for-my-adsl repo directory up to sodium
[01:36] <lifeless> elmo: have a local repo, use a lightweight checkout from that, rsync the repo to sodium
[01:36] <lifeless> as jamesh documents
[01:36] <lifeless> lightweight checkouts are only of use within a LAN/local disk
[01:36] <elmo> rsync which repo?
[01:37] <elmo> the one with the 200Mb .bzr?
[01:38] <lifeless> https://launchpad.canonical.com/WorkingWithSharedRepositories
[01:39] <elmo> yeah, I know, I've read it
[01:39] <lifeless> maybe the question I should ask is 'why do you want to have a lightweight checkout' ?
[01:39] <elmo> because the last time I did anything with LP, I ran out of disk space on my laptop
[01:39] <elmo> so having them locally is very attractive
[01:40] <lifeless> do you mean 'not having..' ?
[01:40] <elmo> blink
[01:41] <elmo> no, I mean "having light weight checkouts as opposed to space sucking heavyweight ones, is very attractive"
[01:41] <elmo> anyway, don't worry about it, I'm probably being stupid - I'll try again tomorrow morning when I'm awake, and go back to normal branches which I know to handle with pqm if I fail
[01:42] <lifeless> do you have a local repository ?
[02:02] <lifeless> sabdfl: btw - https://launchpad.net/products/bzr/+roadmap - is not optimal for us at the moment
[02:03] <lifeless> there are specs scattered all over by priority. is it possible to get jamesh or someone to look at tuning the roadmap algorithm ?
[02:03] <lifeless> I would, but I'm a little short on time
[02:15] <sabdfl> lifeless: it's certainly way off base there
[02:15] <sabdfl> by all means ask him to redo it
[02:15] <sabdfl> he's welcome jsut to reimplement rather than trying to unparse the illogic
[02:16] <lifeless> thanks
[02:30] <lifeless> jamesh: ping
[02:56] <lifeless> BjornT: around ?
[03:52] <jamesh> lifeless: pong
[03:54] <lifeless> hi
[03:55] <lifeless> I've filed a bug on the spec roadmap
[03:55] <jamesh> okay
[03:55] <lifeless> are you interested in making it display useful things ? :)
[03:55] <lifeless> if you are, I'll ask steve about scheduling of it
[03:56] <jamesh> I'll be doing some spec/sprint tracker stuff between now and the next conf
[03:56] <jamesh> so I can probably look at it
[03:56] <jamesh> what's the bug?
[03:56] <lifeless> just look at blueprint
[03:56] <lifeless> latest-bugs :)
[03:57] <jamesh> https://launchpad.net/products/blueprint/+bug/56398
[03:57] <Ubugtu> Malone bug 56398 in blueprint "roadmap should be useful" [Untriaged,Unconfirmed]  
[03:58] <lifeless> assuming you are interested, I'll chat with steve. IMO it should be 1.0 for blueprint
[03:58] <lifeless> because its really a bad shock to look at that page at the moment
[04:07] <jamesh> lifeless: just replied to the bug with a short description of what it is doing now and what you are probably asking for it to do
[04:08] <lifeless> thank you!
[04:22] <jamesh> does what I wrote sound like what you're experiencing?
[05:15] <lifeless> jamesh: I've replied
[05:31] <jamesh> lifeless: (a) I don't think specs get attached to series, do they? and (b) milestones can have dates attached, so can have order
[05:32] <lifeless> yes, specs get targets at series
[05:32] <lifeless> see https://launchpad.net/products/bzr/+specs for instance
[05:32] <jamesh> so they do.  That must be new :)
[05:49] <jamesh> looks like SteveA will be able to carry his laptop on as hand luggage
[06:00] <lifeless> they are relaxing again ?
[06:01] <jamesh> one piece of hand luggage measuring 45cm by 35cm by 16cm
[06:01] <jamesh> can put a laptop in, but need to remove it from the bag for screening
[06:01] <jamesh> still can't take a bottle of water on
[06:02] <jamesh> unless it is prescription water :)
[06:07] <lifeless> is 45/35/16 the old size?
[06:07] <lifeless> or have they resized it ?
[06:16] <jamesh> I think that's a fair bit smaller than before
[06:16] <jamesh> 16cm is not very thick for luggage
[06:32] <lifeless> meh, I'll need to get new travel gear then
[06:32] <lifeless> sucks
[08:44] <sabdfl> lifeless: at the rate you're going you'll be able to check yourself as cargo baggage soon ;-)
[08:45] <sabdfl> jamesh: thanks for taking on the spec-roadmap, the idea is just to show "what you have to do to get the most important, approved specs nailed first"
[08:45] <lifeless> sabdfl: lol
[08:45] <sabdfl> showing their dependencies ahead of them
[09:41] <SteveA> morning
[09:42] <jamesh> SteveA: sounds like you can carry your laptop on the plane now
[09:43] <jamesh> but no cosmetics
[09:54] <SteveA> hmm, got a URL for that?
[10:08] <jamesh> SteveA: www.baa.com
[10:59] <SteveA> thanks james
[11:03] <SteveA> jamesh: I want to do a bzr log, but for one particular file, and see only revisions where that file was updated
[11:03] <SteveA> how can I do that?
[11:04] <jamesh> SteveA: "bzr log filename" should do it, but it seems pretty slow
[11:04] <SteveA> it is giving me lots of revisions when that file was not updated
[11:05] <jamesh> I think it shows the log message for each mainline revision where it was changed (which includes all the log messages for merges)
[11:05] <jamesh> iirc they were looking at improving it for 0.9
[11:09] <spiv> SteveA: if you pipe the log output through 'grep -v "^    "' you'll filter out all the merged revisions.
[11:09] <jamesh> spiv: --short also trims the merges
[11:09] <SteveA> spiv thanks
[11:09] <SteveA> I have the revisions I'm after now
[11:09] <spiv> jamesh: ah, that's probably nicer :)
[11:10] <jamesh> but that doesn't give you the log messages for the revisions that changed the file
[11:10] <jamesh> it gives you the log messages of the merges
[11:34] <sivang> re 
[11:34] <sivang> sabdfl: pong
[11:35] <sivang> spiv: pong
[11:36] <stub> Znarl: asuka is borked. I can't ssh in. I would suspect carlos chewing up the resources, but he isn't online, so I think it needs a power cycle unless someone happens to be in the data centre
[11:37] <spiv> sivang: I don't think I pinged?
[11:38] <sivang> spiv: ah right 
[11:38] <sivang> 06:00 #launchpad: < spiv> sivang reported the problem.
[11:38] <sivang> spiv: sorry
[11:45] <spiv> sivang: ah :)
[11:45] <spiv> Hmm, that merge didn't happen.
[11:48] <danilos> stub: ping
[11:49] <stub> danilos: pong
[11:49] <danilos> stub: do you perhaps have the last queries carlos executed for xaraxl translation removal?
[11:49] <danilos> stub: or he never sent them to you (and run them only on staging so far)
[11:50] <stub> I haven't seen anything about xaraxl
[12:02] <danilos> stub: ok, thanks
[12:10] <SteveA> stub: hi
[12:10] <SteveA> stub: would you look at bug 56397 please?  I think it is a cookie naming issue or something like that.
[12:10] <Ubugtu> Malone bug 56397 in launchpad "App subdomains require separate login" [Untriaged,Unconfirmed]  https://launchpad.net/bugs/56397
[12:32] <SteveA> stub: assigned to you.
[12:33] <SteveA> bug 56397
[12:33] <Ubugtu> Malone bug 56397 in launchpad "App subdomains require separate login" [High,Unconfirmed]  https://launchpad.net/bugs/56397
[12:46] <sivang> laters
[12:48] <jamesh> morning ddaa
[01:03] <stub> SteveA: Did you take down staging?
[01:21] <SteveA> stub: no
[01:51] <sabdfl> sivang: please update your branch and fix the trivial issue I mailed about, and i'll land it
[01:53] <jamesh> sabdfl: for the BranchIndirection spec (lp:... URLs for bzr), are you attached to lp://$product, or would you be happy with lp:/$product or lp:///$product?
[01:54] <sabdfl> jamesh: whats the semantic difference in url-speak?
[01:54] <jamesh> the latter two leave the door open for talking to non-default launchpad instances (e.g. staging)
[01:54] <sabdfl> and what's the difference between the latter two?
[01:55] <jamesh> sabdfl: if you have a URL like "scheme://foo/bar", the "//foo" bit is the authority component which generally refers to a host
[01:56] <jamesh> "lp:/$product" is a URL without an authority component, and "lp:///$product" is a URL with a blank authority -- I was thinking it would be good to accept either of them and treat them as the default LP instance
[01:56] <sabdfl> are there cases where people have agreed to treat scheme:///bar and scheme:/bar differently?
[01:57] <jamesh> not to my knowledge (there are only a few schemes using blank authority sections like file:///)
[01:57] <sabdfl> who has a landing due today? i have a one-line .pt fix that i'd like to get it
[01:58] <sabdfl> ok, +1 on your recommendation, and thanks
[01:59] <jamesh> while lp:///$product is one extra character to type, if we accept lp:/$product as a synonym it can be one less character to type :)
[02:24] <sabdfl> stub: ping
[02:24] <stub> sabdfl: pong
[02:24] <sabdfl> stub: did you take a look at that idea of keeping a spare test_db handy at all times?
[02:24] <sabdfl> to reduce test runner time?
[02:25] <stub> It seemed a valid idea. Only trying it will let us know how much of a saving it would be.
[02:27] <stub> It will increase complexity in parts of the code (need a daemon or thread that creates and drops the dbs), but will simplify some of the existing code that needs to deal with race conditions in creating and dropping databases.
[02:28] <stub> (Hmm... although the daemon will likely need to deal with this too...)
[03:07] <stub> SteveA: We will likely have trouble testing cookies with our existing development domain setup
[03:08] <stub> btw. If you follow the documented procedure for setting up /etc/hosts, Gnome will blow it away when you reconfigure your network through the configuration applet.
[03:09] <stub> Hmm... actually should be fine
[03:13] <stub> Anyone know the difference between request.getURL and request.getApplicationURL ?
[03:55] <SteveA> stub: yes
[03:55] <SteveA> stub: the application URL is the root, taking virtual hosting into account
[03:55] <stub> ta
[03:55] <SteveA> there are args you can apply to count up URL segments and include them.  or is it down?  whatever.  not all that useful.
[03:56] <SteveA> getURL gets you the currnetly published URL.  gets weird if you ask for it during traversal, as in, during the process of publication
[03:56] <SteveA> basically, the zope3 model of a request is rather too bound to "traversal" in a zope2-ish-way
[03:56] <SteveA> well, not really a zope2-ish-way
[03:56] <SteveA> more of a zope3-ish-way
[04:19] <salgado> stub, ping?
[06:13] <bradb> BjornT: ping
[06:52] <sabdfl> anybody have a landing due shortly and willing to slipstream in a 1-line template fix?
[06:53] <sivang> sabdfl: I'm sending the patch shortly
[06:53] <sivang> sabdfl: send it to your email ?
[07:15] <sivang> sabdfl: I have the patch ready, after applying kiko's and your comments. Sending it to you now via email.
[07:19] <sivang> sabdfl: sent, kiko CC'd
[07:22] <sivang> be back alters.
[07:22] <sivang> argh, that is - laters.
[07:35] <ddaa> Call for bikeshedding
[07:35] <ddaa> I'm modifying branch/+edit to allow changing the product and name of a branch
[07:36] <ddaa> Now, when changing those attributes, we can have an unique-name constraint violation if there is already a branch existing with that owner, product and name.
[07:36] <ddaa> So, when the user just changed the name, it's easy, the error should be displayed on the name field.
[07:36] <ddaa> But when the user changed the product, that probably means the user _really_ means that branch should be in the product.
[07:37] <ddaa> So the right way to get that done is to change the name...
[07:37] <ddaa> But... displaying an error for the name field, which was not modified would probably be confusing...
[07:37] <ddaa> Same problem if the user changed the product _and_ the name.
[07:37] <ddaa> Does anybody have an idea to make that non-confusing?
[07:39] <salgado> ddaa, maybe displaying a custom "The project you've chosen already has a branch with this name, you'll have to either rename this branch or the existing one" (or something to that intent) at the top of the page?
[07:39] <salgado> s/project/product
[07:40] <ddaa> Alternatively, we could show the same error on both the product and name fields, saying "There is already a branch registered by $owner in product $product with name $name. We suggest you change the name of this branch to avoid the conflict."
[07:40] <ddaa> salgado: two remarks: the owner of the branch is as important as the product, and in the general case the user does not own the branch with the conflicting name.
[07:40] <ddaa> And so cannot change its name.
[07:40] <salgado> I think that gives the impression that the user has to change both fields, when in fact changing only one would be enough
[07:41] <ddaa> Right.
[07:41] <ddaa> That's my concern, but showing an error on name when the user just modified product would be confusing IMO.
[07:41] <salgado> agreed
[07:42] <salgado> that's why I suggested a message on the top of the page
[07:42] <salgado> (using top_of_page_errors of GFV/LFV)
[07:43] <ddaa> I see. But don't you think we should also provide a marker on the field to change?
[07:43] <ddaa> It's going to be a pretty large form, so some assistance would be welcome.
[07:44] <salgado> yes, that would be like the ideal solution, but if this is not a hand-crafted form, this is not going to be trivial, as I don't think we have the necessary infrastructure
[07:44] <salgado> (maybe I'm wrong and there's something new with zope3.2, but I can't tell for sure)
[07:45] <ddaa> jamesh: can any of your new magic help me there?
[07:52] <ddaa> Mh... +addbranch does not appear to handle name conflicts anyway...
[09:12] <kiko> SteveA, BjornT: ping?
[09:12] <kiko> ValueError: Unknown SQL builtin type: <type 'zope.security._proxy._Proxy'> for <Person at 0x31c18450>
[09:12] <kiko> SteveA, BjornT: this error occurs when we try to do a selectBy(person=self) when the object we have is actually a security proxy.
[09:13] <kiko> SteveA, BjornT: is it possible to work around this? Can I simply allow __sqlrepr__ in some base interface?
[09:14] <kiko> SteveA, BjornT: or is there somewhere else where I can allow __sqlrepr__ to be called on all our objects?
[09:14] <bradb> kiko: personID=self.id?
[09:14] <kiko> bradb, that is the bug I am trying to work around.
[09:14] <kiko> err fix.
[09:14] <kiko> using personID=self.id is arguably a bug
[09:14] <kiko> we should be able to do person=self
[09:14] <kiko> and in most cases it works
[09:15] <kiko> however, in code which uses a proxy object as its argument..
[09:15] <bradb> we should, i agree. i thought you were asking if you could work around person=self
[09:15] <kiko> well, I don't want to work around that error -- I want to fix it (that was the purpose of my current branch :)
[09:16] <BjornT> kiko: what's the traceback?
[09:16] <kiko> BjornT, one moment.
[09:16] <kiko> https://sodium.ubuntu.com/~andrew/paste/file4mJIz8.html
[09:19] <BjornT> kiko: i'd guess, that in _SO_columnClause, obj.id should be replaced with getID(obj)
[09:19] <BjornT> kiko: we override getID to make it aware of security proxies
[09:19] <kiko> BjornT, a bug in SQLObject? aha.
[09:19] <BjornT> kiko: actually, the whole if-else clause could probably be replaced with getID(obj)
[09:23] <BjornT> kiko: i leave it to you to decide wheter it's a bug in SQLObject or not. i'm trying to stay away from the SQLObject code as much as possible :), so i'm not 100% sure what's the correct thing to do.
[09:46] <ddaa> bradb: I think Launchpad demonstrates that sqlobject has quite a thorough support for duct taping.
[09:46] <bradb> sqlobject is some craaazy glue
[10:04] <ddaa> from canonical.launchpad.scripts.importd.tests.sourcetransport_helpers import (
[10:04] <ddaa>     ImportdSourceTarballTestCase, ImportdSourceTransportTestCase)
[10:04] <ddaa> that's sick
[10:05] <ddaa> somebody said that "flat is better than nested", maybe we should flatten the canonical namespace a bit...
[10:06] <kiko> BjornT, so I ended up doing something different, which does work. the issue is that I don't want to just cut sqlrepr() out of there completely.
[10:08] <kiko> (it may be a high-impact change)
[10:29] <kiko> stub!
[10:29] <kiko> good that you showed up
[10:56] <lucasvo> does LP have some sort of a source viewer?
[10:57] <lucasvo> for bzr branches
[10:58] <kiko> lucasvo, not yet. is there a source viewer for bzr at all? what does #bzr say?
[10:59] <lucasvo> crap, I am in a discussion about what to use as a dev-plattform lp and bzr or svn and trac 
[11:03] <lucasvo> can a bug be closed on lp by stating "fixes #18" in a commit message?
[11:04] <kiko> lucasvo, not yet, but it will be possible in the short term.
[11:04] <ddaa> not yet, but we do plan to do that soon
[11:04] <ddaa> I should be there three months from now
[11:04] <ddaa> s/I/it/
[11:05] <ddaa> same for the branch viewer
[11:05] <lucasvo> in three months? 
[11:05] <ddaa> yeah, same time frame
[11:06] <lucasvo> I guess that's kinda too late for a project starting now :(
[11:06] <lucasvo> ddaa: but linking a bugfix to a bzr ci is not possible now?
[11:06] <ddaa> there was some work done before on that, but it was overriden by work to make hosted branches and mirrors faster
[11:06] <ddaa> lucasvo: yes it's possible now
[11:06] <lucasvo> ddaa: how?
[11:07] <ddaa> from the bug page, click "Add Branch"
[11:07] <ddaa> the branch must already be hosted or mirrored on Launchpad
[11:08] <ddaa> what's missing is adding some smarts to e.g. create bug-branch links, or updating bug status by scanning commit messages and merges.
[11:09] <kiko> bradb, is the XMLRPC interface to +filebug actually deployed?
[11:09] <bradb> kiko: it should be, but I haven't tested it yet, because I didn't want to send my p/w over the network
[11:10] <kiko> bradb, even over https?
[11:10] <kiko> or is xmlrpc not over https?
[11:10] <ddaa> bradb: mh, eventually we should put an easy path to registering an external branch and explaining how to host one from the bug/+addbranch page.
[11:10] <ddaa> it's a bit mysterious at the moment
[11:11] <lucasvo> are there any plans that LP will have a wiki per project?
[11:11] <lucasvo> such as trac?
[11:11] <ddaa> lucasvo: not AFAIK, but there are plan to add a simple wiki langage to the specifications tracker.
[11:11] <lucasvo> ok
[11:12] <bradb> kiko: it's over https, but, aiui, the credentials seem to be passed in the URL, which i thought might be a security concern. maybe that doesn't matter?
[11:12] <sabdfl> it does
[11:13] <lucasvo> btw, on https://launchpad.net/products/harmony/+specs "mozilla specifications" is more or less a deadlink
[11:13] <kiko> bradb, the credentials are passed in the URL? really?
[11:13] <ddaa> mpt: copy that? ^^
[11:13] <ddaa> mh.. crap mpt is likely not around at this time
[11:14] <mpt> hi ddaa
[11:14] <bradb> kiko: yes, and no, i think. /me verifies the xmlrpclib docs
[11:14] <ddaa> mpt: see last message from lucasvo
[11:14] <bradb> Both the HTTP and HTTPS transports support the URL syntax extension for HTTP Basic Authentication: http://user:pass@host:port/path. The user:pass portion will be base64-encoded as an HTTP `Authorization' header, and sent to the remote server as part of the connection process when invoking an XML-RPC method. You only need to use this if the remote server requires a Basic Authentication user and password.
[11:15] <mpt> lucasvo, good point, report a bug and assign it to sabdfl :-P
[11:15] <mpt> It's hard to show a good example until upstreams start using Blueprint, though
[11:15] <kiko> bradb, it seems to suggest that you use that syntax to /specify/ a user and password, but that an Authorization: header is what's shipped to the remote server.
[11:15] <bradb> yeah
[11:15] <mpt> bzr specs would be a good example
[11:15] <bradb> so, perhaps it's ok
[11:16] <kiko> sabdfl, bradb, why would the URL be an issue, btw? it is also encrypted in HTTPS traffic.
[11:16] <sabdfl> mpt: woncha fix that with your long-approved-conflict-free-but-unlanded-bazaar UI cleanup? and that oneliner I gave you earlier?
[11:16] <mpt> okie dokie
[11:17] <lucasvo> mpt: I still don't really get what a spec is, maybe writing a doc would be better than linking to upstream
[11:17] <mpt> lucasvo, like a bug report on steroids
[11:17] <sabdfl> kiko: if it's passed in url arguments it would be logged, for a start
[11:18] <sabdfl> it it's in an auth header, that's different, but not what bradb said
[11:18] <sabdfl> mpt: thanks
[11:18] <kiko> sabdfl, logged by.. whom?
[11:19] <sabdfl> kiko: by us
[11:19] <sabdfl> remember we don't as a rule know anybody's password
[11:19] <sabdfl> it's not evern recoverable from the db, given the digesting we do
[11:19] <kiko> ah
[11:20] <sabdfl> however, if it were logged, it would be at risk of lying around
[11:20] <sabdfl> and being exposed
[11:20] <kiko> I don't think the password is ever passed over the URL, though
[11:20] <sabdfl> we should not be loggin in through xmlrpc
[11:20] <bradb> sabdfl: not in url args, just in the URL, as per the syntax taken from the xmlrpclib docs
[11:20] <sabdfl> it should be a key that can be exchanged
[11:20] <sabdfl> so that scripts etc can keep the key in the clear
[11:20] <sabdfl> without exposing a password
[11:20] <kiko> user-agents allow specifying the user/password that way
[11:20] <sabdfl> make sense?
[11:21] <sabdfl> bradb: as long as it turns into auth headers, that's no problem for now
[11:21] <sabdfl> but the proper xmlrpc interface needs keys
[11:21] <kiko> sabdfl, the server doesn't actually receive the URL the client is accessing though!
[11:21] <kiko> it receives the path and host portions
[11:21] <kiko> the path in the GET or POST line
[11:21] <kiko> and the host portion (post HTTP/1.0) in a header
[11:22] <kiko> ah
[11:22] <kiko> I see, you were confused by brad's suggestion of "URL arguments".
[11:22] <sabdfl> (22:12:37) bradb: kiko: it's over https, but, aiui, the credentials seem to be passed in the URL, which i thought might be a security concern. maybe that doesn't matter?
[11:22] <kiko> right
[11:22] <sabdfl> that's all i was commenting on
[11:22] <kiko> sorry :)
[11:22] <kiko> as for the token idea.
[11:23] <sabdfl> it would be perfeclty possible to write an xmlrpc interface this way if you did not know better
[11:23] <sabdfl> i have seen worse done
[11:23] <kiko> so the user would post an auth header and get back a token which he could then keep on using for a while?
[11:23] <sabdfl> kiko: no, the user goes to lp.net, goes to a page in their account, requests a key and is given one
[11:23] <sabdfl> it has a lifespan of n days
[11:24] <sabdfl> it can be revoked
[11:24] <kiko> ah.
[11:24] <bradb> bug 56523
[11:24] <Ubugtu> Malone bug 56523 in malone "xmlrpc works" [Untriaged,Unconfirmed]  https://launchpad.net/bugs/56523
[11:24] <bradb> w00t
[11:24] <kiko> VF
[11:24] <sabdfl> we correlate the key to the account, and use that person
[11:24] <bradb> kiko: that was a test with a python script
[11:24] <sabdfl> if a project has a special need for a long-lived key, we can give them that
[11:24] <bradb> https://help.launchpad.net/MaloneXMLRPC
[11:24] <sabdfl> we can throttle on the basis of keys without hitting the db
[11:24] <sabdfl> if we need to raise the throttle for a key, we can do that too
[11:24] <sabdfl> all making sense?
[11:25] <kiko> sabdfl, by throttle do you mean "time-limit"?
[11:25] <sabdfl> rate-of-query-limit
[11:26] <sabdfl> typicla limit would be 1 query per second over any given minute
[11:26] <sabdfl> so, you can burst, but then have to wait, or you can just slowly trawl
[11:27] <kiko> sabdfl, and rate-limit where in the software stack? iptables? 
[11:38] <sabdfl> kiko: most anything that can do rate-limiting can do it on the basis of a header like that
[11:39] <kiko> sabdfl, oh. apache has a mod_throttle, right?
[11:39] <sabdfl> kiko: yes, and i'm sure pound has something similar, and there are very good appliances that can do it too
[11:40] <kiko> right.
[11:40] <sabdfl> xmlrpc is great but also a risk, we can invest in doing it properly
[11:40] <sabdfl> on the icon - doh
[11:42] <kiko> ok
[11:44] <lifeless> squid-3 can throttle on anything it can filter on :0
[11:44] <lifeless> so yeah, lots of things as sabdfl 
[11:44] <lifeless> says
[11:45] <kiko> salgado, have you seen bug 35099?
[11:45] <Ubugtu> Malone bug 35099 in launchpad "feedback about karma" [Wishlist,Confirmed]  https://launchpad.net/bugs/35099
[11:47] <salgado> kiko, no, first time I'm seeing it
[11:47] <kiko> yeah, me too
[11:47] <kiko> sabdfl, about karma in LP: http://alligevel.blogspot.com/2006/07/karma-in-launchpad.html
[11:48] <kiko> salgado, assign to you?
[11:49] <salgado> kiko, sure
[11:50] <kiko> salgado, also, see the blog above.
[11:52] <kiko> BjornT, bradb, salgado: there's no new@support.launchpad.net, right?
[11:52] <bradb> no idea
[11:53] <salgado> AFAIK, the email interface of the support tracker can only be used to add new comments
[11:53] <kiko> salgado, thanks.
[11:55] <sabdfl> we should definitely let folks create a question via email
[11:55] <kiko> agreed, just checking.
[11:55] <kiko> salgado, is there a bug filed on that?
[11:56] <salgado> not sure, let me check
[11:57] <kiko> yes
[11:57] <kiko> there is
[11:57] <kiko> https://launchpad.net/products/launchpad-support-tracker/+bug/53292
[11:57] <Ubugtu> Malone bug 53292 in launchpad-support-tracker "Email submit support ticket feature" [Untriaged,Unconfirmed]  
[11:58] <salgado> this is not really that, it's something more complex
[11:58] <kiko> salgado, I think aaron is just confused, that would solve his problem
[11:59] <salgado> yeah, maybe
[11:59] <kiko> if he sets the mailing list to be his support contact
[11:59] <kiko> and we allow replies to the support requests
[12:00] <kiko> and email to new@support
[12:00] <kiko> then, well, it would work out.
[12:05] <sabdfl> that's a little heath robinson, but creative and yes it would work
[12:05] <sabdfl> we do need mailing list integration. would you put a penny in that jar, please, kiko?
[12:06] <kiko> sabdfl, heh, okay. I'm not sure what that has to do with aaron's problem though. he wants to use gmane and our ticket tracker together. and we do support that already!
[12:07] <sabdfl> has anybody tried to run LP with python-twisted 2.4.0 in edgy? spiv?
[12:07] <sabdfl> i just KNOW you must have made that work
[12:07] <kiko> I hope spiv's still in bed!
[12:09] <sabdfl> one eye open, thats how it's done