[00:16] hi lifeless ! [00:16] happy new year [00:17] hi poolie, ditto. [00:18] popping out for food, brb [00:20] poolie: Did you happen to check if Lucid's python-oauth is fixed too? [00:20] wgrant, i did not, yet [00:21] francis's message led me to suspect it was already installed from an egg? [00:21] that was the next thing i was going to check [00:21] Ah, I haven't read the MP. [00:21] I'm just interested because I have been trying to remove contrib/ over the past year or so. [00:22] Most of it is gone. [00:22] lib/contrib/oauth should be easily removable. And we for some reason have a version of BeautifulSoup in the tree too, which should be removable. [00:22] * wgrant lunches. [01:10] wgrant: Far too many scripts use contrib.glock :-( [01:12] wgrant, StevenK: With today's soyuz, how difficult would it be to separate the buildd and job dispatch code into a discrete service? [01:25] cody-somerville: what do you mean by that? [01:25] Beat me to it. [01:25] what operations would be 'buildd but not job dispatch'? And vice verca. [01:26] wgrant, there is a download-cache/dist/oauth-1.0.tar.gz [01:26] which i take to mean it's not installed from the distro [01:26] no [01:26] istm it would be better if more stuff was [01:26] that just means its in the download cache [01:26] I think the "buildd and job dispatch code" is a single entity that cody-somerville wants extracted? [01:26] versions.cfg and setup.py are what you need to consult [01:26] wgrant, aye [01:26] poolie: It would make sense for lots of stuff to be installed from the distro, I think. [01:26] But Zope disagrees, so we disagree. [01:26] poolie: to do more stuff from the distro we need to solve the concurrent version issue I've been harping on about (e.g. see debian-python mails from yesteday) [01:27] wgrant: its not about zope [01:27] what is that, briefly? [01:27] multiple versions of the same python library? [01:27] yes [01:27] or for multiple interpreters? [01:27] lifeless: It is to an extent. [01:27] former [01:27] wgrant: if you mean not at all [01:27] lifeless: Oh? [01:28] ... because, lp needs some things more recent than in lucid, that cannot be upgraded without breaking other packages? [01:28] Zope people use buildout. [01:28] and actually a more interesting question I have is, how difficult would it be to make the packaging building stuff (exclusively) a service? Ie. I use an API to provide a source package + chroot configuration and I get back the binaries [01:28] Some other people are starting to use virtualenv, true, but it's not the way things have mostly worked in the past. [01:28] poolie: because we run multiple versions of launchpad concurrently in the same machine [01:28] *package [01:29] cody-somerville: With queueing? [01:29] poolie: such as when we're deploying an upgrade [01:29] wgrant, yes [01:29] hm [01:29] wgrant: I think you're talking about something else, I know what other zope projects do, I'm talking about what we'd need. [01:29] cody-somerville: It wouldn't be horrifyingly difficult to write a job to do that. But buildd-manager still depends on most of the rest of Launchpad. [01:29] poolie: wgrant: one of the first things I did as TA was analyse what we need from buildout, as part of looking to simplify things. [01:30] lifeless: Most projects do not need to be locked to particular versions of libraries. [01:30] one way to look at this is, probably [01:30] the primary thing is having dependency V1 and V2 concurrently installed as we transition [01:30] wgrant, just the buildd is already separated out, right? [01:30] cody-somerville: Right. [01:30] wgrant: it only takes one. [01:30] if launchpad itself was packaged, you couldn't run multiple (closely related) versions concurrently [01:30] lifeless: Right. [01:30] therefore, they should actually be in separate chroots or something [01:31] generally speaking debian expects you'll have just one version at a time [01:31] poolie: huh? [01:31] poolie: we're talking deps, you're talking application. [01:31] poolie: for deps debian expects many versions in nearly every other language than python. [01:31] C, C++, C#, perl (I think), ... [01:32] wgrant, Does it have a well defined, generic API that would make it easy to just use say amazon's simple queue service and some dispatching glue code? [01:32] cody-somerville: Hee hee. [01:32] mm i agree it would be good to support multiple versions in debian [01:32] cody-somerville: we have rabbit, why would we use sqs? [01:33] just don't know if that should be a dependency for getting more lp dependencies packaged [01:33] cody-somerville: perhaps you should talk about what you want to do, now how to do it :) It might be a more effective discussion [01:33] wgrant, Does it have a well defined, generic API that would make it easy to just use an existing queue solution such as rabbitmq and some dispatching glue code? [01:33] poolie: its not a dpeendency for getting them packaged; its a dependency for *using them from packages* [01:34] lifeless, I am but you're getting hung up on the example I used. :P [01:34] cody-somerville: My previous rofling stands. [01:34] that's what i meant [01:34] wgrant, seriously? :( [01:34] anyhow, in this particular case, we could use the packaged version? [01:34] poolie: we will be running 30 or more appservers per physical machine, I shudder at the idea of vm's or chroots in the mix. [01:34] cody-somerville: It's not impossible. [01:34] But probably not terribly easy. [01:34] or is there a general thing of keeping it in sourcecode because we might want to change it? [01:34] poolie: in this case, yes. [01:35] where is the line? [01:35] poolie: if the packaged version matches our version needs, once its remoed from contrib we should just use the package automatically. [01:35] ffs, why don't people just trust all the books that tell you that people WILL reuse your code :-( [01:35] cody-somerville: I'm not hung up on it, I don't get your use case. [01:35] cody-somerville: Probably because this was written in 2004 or so :( [01:36] no, what i meant was, what's the policy on using the packaged version? [01:36] is it as simple as saying if the distro's own package is adequate, we'll use it, otherwise not? [01:36] poolie: there isn't a hard one, its an engineering decision per package. [01:36] I wouldn't use a high flux dependency (like bzrlib) from a package today. [01:36] poolie, thats what we do with OEM's image build system [01:37] poolie, we create a virtualenv and pip will only install dependencies that aren't already met by the system's site-packages [01:38] mm i see your point [01:39] in some ways it seems like a kludge not to update the bzr package and install that [01:39] of course it would be difficult to do staged testing then [01:39] i guess also it seems not quite perfectly safe to upgrade packages while they're being used [01:40] lifeless, I want to be able to use the launchpad buildd farm directly to build source packages. ie. I use API to say I want to build this source package using this chroot configuration and it gives me back the binary packages. [01:41] poolie: ignoring the link-unlink bug, the problem is that we want version 1 running while version 2 is prepped and checked [01:41] poolie: and during that time, version 1 might restart (log rotation) or import a module it hadn't used before [01:41] right [01:42] poolie: in fact, for cronscript servers, we're continually starting new processes of version1 all the way until version2 is live [01:43] cody-somerville: Why? [01:43] cody-somerville: ok; so you want to not-publish-into-a-ppa and you want to specify the chroot rather than it being inferred from the target ppa [01:44] cody-somerville: we could certainly refactor to have a dedicated layer for that [01:44] assuming the python multiple version problem is solved, would you use that? [01:44] poolie: I'm very keen to use more distro packages of python. [01:44] it seems unidiomatic to have separate package names at very fine granularity [01:44] lifeless: Another requirement is custom sources.list entries. [01:44] but perhaps we would have stable on bzr2.2.2 and staging on bzr2.2.3 [01:44] wgrant: right, we'd need complete parameterisation [01:45] Which is messy. [01:45] wgrant, we already can do that [01:45] cody-somerville: Not... really. [01:45] cody-somerville: we inject those into the chroot, its not a different chroot [01:45] cody-somerville: *you* might be willing to run with a different chroot, but lp can't sensibly. [01:45] we'd have thousands [01:46] I don't actually want to use my own chroot with my current use case, just be able to define the sources.list really [01:46] lifeless, i'd like to have a talk sometime today, or tomorrow [01:47] sure [01:47] Ideally the build farm would not really be part of LP. [01:47] wgrant, +10000 [01:47] wgrant: why? [01:47] lifeless, makes it easier to reuse the code [01:47] will just do a couple more chores then ping you [01:47] if that suits [01:48] cody-somerville: that doesn't really follow :) [01:48] poolie: sure [01:48] lifeless, it currently sounds like I'd have to setup an entire launchpad instance to reuse the code or to deploy my own instance [01:49] lifeless, plus, the buildd farm stuff really has no need knowing anything about launchpad its self - so why make it? :) [01:50] theres a bunch of opportunities we haven't capitalised on [01:50] anyhow [01:50] they can all be done at a higher level [01:51] something we'd want to make all this done better would be to have web callbacks for things completing [01:51] lifeless: Because Launchpad is really huge and unnecessarily monolithic. The build farm is sensibly reusable, so it is a good target for ripping out. [01:51] wgrant: I'm pro that if we sort the interface out properly first [01:51] lifeless: That would seem to be a requirement regardless. [01:53] wgrant: The worry I have, is that if the goal is 'rip out' then sorting out the interface becomes secondary and 'good enough' often isn't. [01:54] wgrant: if the priority is instead 'get a really clean interface and make use of the build farm in better ways' - and if by chance someone can extract it later, thats fine with me. [01:55] lifeless: If we do not clean up the interface, there is little direct benefit to ripping it out. [01:55] So to reveal my master plan, I know that OEM Services isn't going to run our own deployment of launchpad - we don't want to - and I know that launchpad.net isn't going to be able to meet all of OEM Services's needs while meeting everyone elses at the same time which is why I'd like to be able to build custom services that are a perfect fit for us on top of services provided by Launchpad so I don't have to reinvent the wheel o [01:55] r duplicate resources. [01:55] That is a large part of my desire to chop LP into little pieces. [01:55] cody-somerville: Why can we not provide all of your needs? [01:55] beat me to it this time. [01:56] We should be trying to fix LP -- whatever that may entail -- before we try to work around it. [01:56] wgrant, because you have to have the same behavior across launchpad and the desired behavior for OEM Services, Ubuntu, and upstream projects conflict. [01:58] Plus some things won't be appropriate in Launchpad at all and you guys would hate us if we made you hack something in and we'd be angry that it wasn't maintained very well and we can't just do it all ourselves as it would duplicate part of something Launchpad does well [01:58] ugh, not typing very well but that seems readable, yes? [01:59] cody-somerville: we need all projects in lp to be consistent, we don't need distros to be the same as projects [01:59] lifeless: Yes we dooooooooo. [01:59] They should be the same object. [01:59] Anything else is just a mess of pain and user confusion. [01:59] wgrant: if we sort out project groups, sure. [01:59] cody-somerville: What sort of things do you want? Your needs are not terribly unique. [01:59] lifeless: Project groups are a bug. [02:00] wgrant: one solution to grouping things; one I'm not terribly happy with, but not a bug per se. [02:00] wgrant, Our needs are considerable unique. [02:00] cody-somerville: will you be @ the rally? [02:01] lifeless, No, sorry. [02:01] cody-somerville: Some of your specific needs, sure. [02:01] cody-somerville: I'd like to do this on specifics, not on generic statements. [02:01] But your need for extensions is not unique. [02:01] lifeless, Agreed. [02:01] wgrant, True which is why I think its entirely possible for launchpad to make it really easy for us to build services on top of launchpad services and everyone be happy. [02:02] cody-somerville: Exactly. [02:02] our generic requirement to find good defaults and unconfusing extensions does not mean 'cannot mean OEM's needs' [02:02] Except that you probably shouldn't be trying to run your own instances of every service. [02:02] You should probably be able to integrate with Launchpad.net. [02:03] (argh, I wish the code had been released as "Rocketfuel" or similar, so we didn't have "Launchpad" vs "Launchpad.net" :() [02:03] We don't want to. For example, we want to use the launchpad buildd farm but we want to do our own upload processing. Maybe in the future Soyuz will be able to do what we want to do there but it'll be a long time out. Part of the desire to do this is to improve turn around on meeting our needs and not wanting to bloat Launchpad [02:04] *and also [02:04] cody-somerville: Why do you need to do your own upload processing? And is there a good reason to run your own build farm? [02:06] wgrant, A good example is that we want to have the project name as the target instead of the Ubuntu release name. It would take a lot of work to make that possible in Soyuz right now but in the future, if this was our only requirement, we'd switch to using Soyuz upload processing again when it became possible. [02:07] wgrant, I can think of no way to justify the cost of hardware for us to set up our own build farm [02:07] cody-somerville: Then you probably want to integrate with the Launchpad build farm, rather than set up your own. [02:07] wgrant, neither could the c-level execs which is why we are now using PPAs to build our packages instead of traditional debian dak buildds [02:08] we're /not/ going to run multiple competing control nodes [02:09] wgrant, Sorry if I haven't been clear. We absolutely want to which is why I was asking my previous questions about refractoring the code. [02:09] cody-somerville: But you don't want it split out so you can run your own. [02:09] You want to be able to inject your own things into the queue. [02:10] wgrant, in the future, we may want to supplement our own capacity to build packages using a private farm [02:10] cody-somerville: Then we can probably use builder pools. [02:10] Which don't exist, but have been devised. [02:10] wgrant, thats fine too [02:12] wgrant, basically I just want to be able to use the buildd farm like one can use pbuilder (in terms of input and output, roughly) [02:12] so devs will use it directly like that ? [02:12] Right. [02:14] lifeless, No. What I'm envisioning is that our engineers will upload the source package to our upload processor which will handle our unique constraint checks and then use launchpad API to queue it for building with the right sources.list [02:14] then we'll poll for completed builds, download the binaries, and install them into our archive [02:14] cody-somerville: so I think you've spent a bunch of time thinking about this *without us* [02:14] and framed the problem as 'how to workaround launchpad' [02:15] this isn't helpful :) [02:15] cody-somerville: What I'd like to do is just design something that directly adds in what you need; it sounds like the first thing you need is a callback for constraint checking [02:15] lifeless, I don't think so. I've shared exactly what I wanted out of Soyuz with the soyuz team almost two years ago. [02:15] Well, thinking about how to fix Launchpad also isn't entirely helpful. [02:15] This may change in January. [02:15] When we are actually capable of responding to requirements. [02:16] cody-somerville: its not visible to me in my TA role unless it was captured somewhere, which it doesn't seem to have been. [02:16] lifeless, I even reiterated over it in June with Jono Lange and kiko in Lexington. [02:16] lifeless, I don't believe you were the TA then [02:16] Julian is aware of it. [02:16] We are aware of it. [02:16] * cody-somerville nods. [02:16] But this is all about to become irrelevant :( [02:17] cody-somerville: I wasn't. [02:17] cody-somerville: July :) [02:18] cody-somerville: so polling is a performance and bandwidth hog [02:18] lifeless, in the future we'd have web callback [02:18] cody-somerville: would a callback from lp @ the constraint checking stage help you today ? [02:19] lifeless, for some of our requirements, yes [02:19] lifeless, but we still wouldn't be able to use the project name as the target [02:20] cody-somerville: we may need more than one change to meet all your needs. [02:20] cody-somerville: Why can't you use separate archives? [02:20] wgrant, we do currently, one for each project [02:20] wgrant, the issue is that the target has to be the Ubuntu series [02:20] Is this a problem? [02:21] wgrant, and that'll take a lot of work (pretty much rewriting soyuz) to make that work [02:21] The scale of the problem depends on why it is a problem. [02:22] wgrant, yes. engineers are forever uploading to the wrong series (and then think something is wrong and think soyuz is broken again), its more difficult to track the changes now since we have projects that inherit from other projects, and several times packages have been accidentally uploaded to Ubuntu (but were rejected for other reasons thank goodness). [02:23] cody-somerville: It sounds like you want series-restricted PPAs, and probably to remove the default dput target... [02:23] its not the dput target I'm talking about [02:24] its the target in the changelog (which is the default value for the Distribution field in the .changes file) [02:24] The dput target was for the Ubuntu part. [02:25] Also, even now you can put whatever you want in the Distribution field, if you also add the series to the path. [02:25] It's not that ingrained. [02:25] re: series-restricted, sorta but I'd rather think of it like being able to create an archive and be able to configure my own suites [02:25] Right. But that's a little harder. [02:25] Not *terribly* difficult. But substantially harder. [02:25] cause thats our biggest barrier to using launchpad for our archive management [02:26] === Top 10 Time Out Counts by Page ID === [02:26] Hard / Soft Page ID [02:26] 92 / 266 BugTask:+index [02:26] 91 / 5150 Archive:+index [02:26] 41 / 263 Distribution:+bugs [02:26] 26 / 114 ProjectGroupSet:CollectionResource:#project_groups [02:26] 17 / 37 MailingListApplication:MailingListAPIView [02:26] 13 / 4 Product:+filebug-show-similar [02:26] !! I am no longer winning :D [02:26] 11 / 190 POFile:+translate [02:26] 11 / 12 DistroSeriesLanguage:+index [02:26] 8 / 2 ProjectGroup:+milestones [02:26] 8 / 2 Distribution:+builds [02:26] wgrant: so are [02:26] Soft timeouts don't count. [02:27] yeah, they do. [02:27] Shhh [02:27] * wgrant finds a recent oops. [02:30] Oh, that's right. [02:31] Last time I looked at this I noticed that there were many seconds of Python time which didn't make sense. [02:31] Presumably single-threading may eliminate that. [02:33] yes [02:33] I've mailed flacoste asking him to bump it up now I'm back [02:34] It's possible that the view is buggy, but 2.5 seconds after a 100ms query that should only return a few dozen objects seems unlikely. [02:54] lifeless, hi, how about now? [02:55] sure [05:28] subunit-filter, you make me sad and I hate you [05:39] StevenK: perhaps a more constructive version of same would garner more useful responses than this [05:39] lifeless: 'subunit-ls | subunit-filter --no-success' shows me a lot more than the failed tests [05:39] But I still hate using subunit since it's obtuse [05:40] subunit-ls does not output subunit [05:40] you want subunit-filter | subunit-ls [05:41] Oh, damn it [05:41] The upgrade in the background played with postgres [05:43] lifeless: Can I have that tell me which tests failed, without the traceback? [05:44] what traceback ? [05:44] Oh, it's a frinxing doctest === almaisan-away is now known as al-maisan [08:53] good morning [08:59] morning [09:17] Hello! [09:21] Good morning [09:33] Hey, I've come back after the holiday and now find that when I try to run make schema in devel I get a message asking me to run link-external-sourcecode. devel is usually the target I link to, though, so I'm a bit confused. Any ideas? [09:35] mrevell: Try 'utilities/link-external-sourcecode ../../lp-sourcedeps' [09:36] Thanks wgr [09:36] ugh [09:36] :) [09:37] Seems to have done the job, thanks wgrant. [09:37] Excellent. [09:53] allenap, Around? [09:53] mrevell: Yep, what's up? [09:54] allenap, Remember the egg problem I was having last year? (Couldn't find a distribution for 'testtools==0.9.8-r151'.) I don't suppose you've got any other ideas on how I can get round it? [09:55] allenap, Don't worry if you don't remember :) [09:56] mrevell: Mmm, I don't really remember the problem. Do you have a paste of it? [09:57] allenap, Sure: http://pastebin.ubuntu.com/550154/ [09:59] /win 71 [09:59] $ ls -al download-cache/dist/testtools-0.9.8-r151.tar.gz [09:59] -rw-r--r-- 1 stub stub 83750 2010-12-07 12:34 download-cache/dist/testtools-0.9.8-r151.tar.gz [09:59] mrevell: Does your tree have that? [10:00] * mrevell checks [10:01] stub: hi [10:01] stub, No, it doesn't. I've tried rf-setup in the hope that might pull down whatever's missing but it hasn't helped. [10:01] stub: wgrant was hoping to talk to you about the archive:+index timeout bug - 400ms queries. [10:01] Oh, right, forgot about that. [10:01] * wgrant finds an OOPS. [10:01] wgrant: linked in ze bug :) [10:01] mthaddon: cd download-cache; bzr up [10:01] s/mthaddon/mrevell :P [10:02] mrevell: ^^^ (sorry mthaddon) [10:02] np [10:02] thanks stuv [10:02] heh, and I failed to write your name [10:03] mrevell: Update scripts should be doing that for you. Perhaps there is one you are not running? [10:03] rocketfuel-setup should run rocketfuel-get which updates download-cache. [10:03] Unless things are misconfigured and it is updating some random location :) [10:04] stub, Ah, I'm hitting a repository format error: http://pastebin.ubuntu.com/550164/ ... I'm trying a bzr upgrade [10:04] stub: https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-1817D1186 <- the query count should now be constant, but the remaining queries are being rather slow. [10:05] stub: Any suggestions? [10:06] NoScript update thinks Ubuntu SSO is doing XSS. [10:07] It probably is. [10:07] wgrant: I think we are going to need to eliminate those big IN (list, of, constants) - they used to benchmark fairly well (years ago) but that seems to be the common factor on the slow queries. [10:08] stub: :( [10:08] stub: really? [10:08] I don't know - just my spidey sense. [10:08] stub: thats going to play havoc with complex datasets [10:09] (because prejoining across many tables performs terribly in storm due to deserialisation overheads and cache-replacement-thrashing) [10:09] Some unions in there that look suspicious too [10:10] And those tables have been getting pretty darn big now we have several whole distro releases in there. [10:14] ((seven table join with unnecessary ORDER BY) UNION (five table join with unnecessary ORDER BY)) ORDER BY id [10:15] (query 22 at over 1s) [10:21] gnight [10:21] lifeless: We shouldn't have cache replacement issues - the appserver runs with a big cache (10,000). And if that isn't big enough, we can spare some more RAM. [10:21] (storm cache that is - the current config specifies size 10000 and generational cache for the appservers. === al-maisan is now known as almaisan-away [12:02] Morning, all. [12:02] Happy New Year! [12:06] Merry New Year! === matsubara-afk is now known as matsubara === mrevell_ is now known as mrevell-lunch === almaisan-away is now known as al-maisan [13:53] hi deryck [13:53] hi bac [13:53] deryck: hope you had a good break. [13:53] deryck: i've got a question for you about QA and bug mail [13:54] bac: indeed, a wonderful break. Thanks! and hope your's was good. [13:54] bac: sure, shoot. [13:54] so i need to qa the fix for bug 579502 [13:54] <_mup_> Bug #579502: Do not send notifications to registrants (and never if the pillar does not use bugs)

< https://launchpad.net/bugs/579502 > [13:55] but bugmail does not appear to be sent from qastaging [13:55] and, if i remember what sinzui said yesterday, it isn't sent by staging either [13:55] bac: I thought qastaging mail was sent to the staging mailbox. [13:55] deryck: so can you give me some advice on how to QA a bug mail branch? [13:56] bac: we usually do some action, have losas run the send bugmail script, and then check the mail in the staging mailbox. [13:56] deryck: really? sinzui indicated there was a separate qastaging@ mailbox...but the mail sending script wasn't being run [13:56] mail isn't sent via cron, so you need a losa. [13:56] deryck: ok, so the script is run on demand? [13:56] well, then, that's the missing link [13:56] bac: right. and I wasn't aware of a separate mailbox, but maybe that's the case now. [13:57] deryck: thanks. those are two good pieces of ammo to move forward! [13:57] bac: np! === mrevell-lunch is now known as mrevell [14:53] henninge: ping. [14:54] Hi jcsackett! ;) [14:54] hi, henninge. i was wondering how the qa on recife was going? [14:55] jcsackett: still ongoing but looks good. ;) [14:55] henninge: cool, thanks. :-) === salgado is now known as salgado-lunch === deryck is now known as deryck[lunch] === Ursinha is now known as Ursinha-afk === al-maisan is now known as almaisan-away [16:18] anyone know if there's a bug filed about the screwy branch diff overlay? === beuno is now known as beuno-lunch === Edwin__ is now known as EdwinGrubbs === matsubara is now known as matsubara-lunch === salgado-lunch is now known as salgado === deryck[lunch] is now known as deryck [17:06] bigjools: there's one filed about it being too wide on bug pages [17:07] * gmb EoDs. [17:07] deryck: ah I don't think that's the same. The top of it is off the page for me, and on Chromium it's not even formatted properly. [17:07] for the latter, it takes up the whole page [17:08] bigjools: the bug I'm think of was Chromium specific, so maybe related then. but nothing about those issues specifically that I recall. === Ursinha-afk is now known as Ursinha === Ursinha is now known as Ursinha-afk === Ursinha-afk is now known as Ursinha === Ursinha is now known as Ursinha-afk === Ursinha-afk is now known as Ursinha === beuno-lunch is now known as beuno === gary_poster is now known as gary-lunch [17:39] bac: thanks for fixing that has_*_ppa stuff! [17:39] bigjools: np. === benji is now known as benji-lunch === yofel_ is now known as yofel === gary-lunch is now known as gary_poster [18:48] flacoste: We're popping into the hospital this morning, in about 2 hrs for $unknown-duration [18:48] flacoste: if there's anything more you want to discuss before then would be good :) [18:49] lifeless: nope, we are good === benji-lunch is now known as benji [20:16] morning === salgado is now known as salgado-afk === matsubara is now known as matsubara-afk === Ursinha is now known as Ursinha-afk [21:35] Is there any systematic distinction between lp.code and lp.codehosting ? [21:52] maxb: ish [21:52] do tell :-) [21:53] i guess you could say that lp.code is the code for the code tab in the webapp [21:53] lp.codehosting is for the stuff that deals in bzr branch data === gary_poster is now known as gary-afk [23:20] mwhudson: / thumper: either of you aware of any reason we can't move from internal-xmlrpc to apis for the code* stuff? [23:21] lifeless: there are some that shouldn't be accessible from the wider world [23:21] and it would be nice to do authentication more tidily, but that's a bit orthogonal really [23:21] mwhudson: why not? [23:21] I mean [23:21] should they be limited to some service account [23:22] and we simply don't use from outside [23:22] or would they be an actual problem if the outside used it even on the service acocunt? [23:24] i think limiting to a service account would be ok [23:24] I'd like to get rid of the internal xmlrpc 'cluster' [23:24] it requires manual load balancing and complicates haproxy substantially [23:34] i'd like to change bzr to stop using external xmlrpc too [23:35] the anonymous lp-api interface should permit a crafted url with no indirection. [23:35] if we bypass all the restful overhead, it should be tolerably fast [23:39] sinzui: what teams use polls? [23:40] ~ubuntumembers has in the past. [23:40] For CC elections. [23:40] well, its coming back is all [23:40] Recent DMB elections have used an external Condorcet service, though. [23:40] yes, I know. [23:40] wgrant: I'm asking sinzui because of his MP [23:41] It is tempting to restrict them by FF to grandfather them for certain teams. [23:41] But that sounds difficult. [23:41] pretty easy [23:42] however hard to explain