[00:00] <wallyworld> bac: ack
[00:09] <StevenK> bac: Sorry, we were afk discussing a feature
[00:53] <wallyworld> do i recall correctly that there is no need for GoogleServiceLayer anymore? ie we are not using any google apis anywhere?
[01:02] <wgrant> We still use it for search.
[01:02] <wgrant> Just not for maps.
[01:04] <wallyworld> ok. thanks. a test i was running timeout out waiting for setup() so i was just wondering
[01:19] <poolie> can someone answer out of hand abentley's question on https://code.edge.launchpad.net/~mbp/launchpad/690021-rlimit/+merge/43733
[01:20] <poolie> if a scan branches job aborts unexpected (is killed by rlimit) what will happen?
[01:20] <poolie> will the jobs be failed, or re-run?
[01:40] <poolie> wallyworld: ^^ do you know?
[01:41] <wallyworld> poolie: i think any branches that haven't been scanned yet would need to be rescanned, but i'm not 100%
[01:43] <wallyworld> poolie: the scan branches job is just a cron script so shouldn;t any branches not scanned when the job is killed be picked up next time the job is run?
[01:44] <poolie> i would have thought so
[01:44] <poolie> i guess they may just fail repeatedly
[01:44] <poolie> if it scans multiple branches in a single process invocation this might mean that we get stuck with none being scanned?
[01:44] <poolie> this is probably still an improvement over the whole machine bogging down though
[01:44] <wallyworld> i'm wondering about the same thing myself
[01:53] <wallyworld> poolie: each python BranchScanJob instance works on a single branch but i'm not sure how these are invoked from the calling script ie if one fails, does it continue with the others
[02:00]  * poolie looks
[02:14] <poolie> yeah it's not obvious to me yet
[02:17] <poolie> it looks to me like if we kill the process, it will still be seen as running
[02:18] <poolie> oh i guess we could just look at what has actually happened recently to the scanner
[02:26] <poolie> i don't suppose there are docs of the lp jobs system?
[02:26] <poolie> ah, some in https://dev.launchpad.net/Foundations/JobSystem
[02:28] <wallyworld> poolie: tim would be able to provide an immediate answer but he is away till monday
[02:29] <poolie> i will request a review from him and sit on this until then
[03:21]  * wallyworld sad - lost power, huge thunder storm, limited internet connectivity :-(
[03:24] <spiv> wallyworld: http://www.bom.gov.au/products/IDN65152.shtml has a fun diagram
[03:24] <mwhudson> heh yes
[03:24] <wallyworld> spiv: yeah, and my wife has the car and it can't be put under cover :-(
[03:25] <wallyworld> lucky i got a 3G modem for these type of emergencies
[03:25] <wallyworld> the rain here is pissing down
[03:50] <wgrant> "This thunderstorm is very dangerous"
[03:50] <wgrant> Not something I thought I'd hear from the BoM.
[03:51] <spm> wallyworld: aarnet lost au.mirror... so you're not alone
[03:52] <wallyworld> spm: sucks for them and me :-(
[03:54] <wgrant> I want a storm :(
[03:54] <wgrant> Maybe not quite that big.
[03:54] <wgrant> But it's getting disappointingly warm down here.
[03:57] <wgrant> lifeless: Hah, I win. Soyuz is out of the top-10 timeouts.
[03:57] <wallyworld> wgrant: where are you?
[03:57] <wgrant> I am safe for now.
[03:57] <wgrant> wallyworld: Melbourne.
[03:57] <wgrant> it's been nice and rainy the last couple of weeks.
[03:58] <wgrant> But this week is fairly warm.
[03:58] <poolie> huge thunderstorm here too
[03:58] <wallyworld> wgrant: well you know what they say about mne - 4 seasons in one day - careful what you wish for
[03:58] <poolie> *by sydney standards, would be a shower in bne
[03:58] <wgrant> True, true.
[03:58] <wallyworld> poolie: :-)
[04:15] <wallyworld> worst part about having no power - it's way past my afternoon coffee time :-(
[04:19] <StevenK> wallyworld: Coffee shop?
[04:19] <wallyworld> i think the whole suburb is out
[04:20] <wallyworld> it would be a looong drive and the window doesn't win up properly on my 2nd car which is a bomb
[04:20] <wallyworld> s/win/wind
[04:26] <lifeless> wgrant: till jan 17th
[04:41] <wgrant> lifeless: :(
[04:43] <lifeless> wgrant: something real small would be to add a garbo job populating bugmessage.index
[04:44] <wgrant> lifeless: Sadly Steve and I hae something real big.
[04:45] <lifeless> fun times!
[04:45] <wgrant> s/hae/ha[tv]e/
[04:45] <StevenK> Hate seems more appropos
[04:45] <StevenK> apropos, even
[05:16]  * wallyworld about to disappear. laptop battery almost dead :-(
[05:39]  * nigelb congratulates lp folks on new team structure :)
[05:53] <poolie> :)
=== almaisan-away is now known as al-maisan
[07:55] <wgrant> wallyworld: You have power again?
[07:56] <wallyworld> wgrant: yeah. i decded to go out and find a coffee shop with power (there were several suburbs without) and when I got back, it was on again \o/
[07:56] <wallyworld> just turned out the cricket to take a peek - not good for us :-(
[08:00] <wgrant> Excellent!
[08:00] <wgrant> And I don't care about cricket :P
[08:03] <wallyworld> what? shame on you!
[09:17] <mrevell> Hi
[11:51] <danilos> bigjools, hi, do you have a minute to chat about bug 685624?
[11:51] <_mup_> Bug #685624: Translation template build jobs should use the new BuildFarmJob <lp-soyuz> <lp-translations> <Launchpad itself:New> < https://launchpad.net/bugs/685624 >
[11:51] <bigjools> danilos: 60 seconds and counting
[11:52] <henninge> danilos: I was just about to ping you ...
[11:52] <danilos> bigjools, I am hoping for a mumble chat
[11:52] <bigjools> danilos: ok give me 5 mins
[11:52] <danilos> henninge, should be quick, I am on a countdown
[11:53] <danilos> henninge, heh, so, what's up with you while I am on hold for Julian? :)
[11:54] <henninge> danilos: the test for setCurrentTranslation is failing and i don't understand why this is supposed to work this way.
[11:55] <danilos> henninge, I am guessing because of makeCurrentUbuntu/makeCurrentUpstream changes
[11:55] <henninge> danilos: no, it is related to my "fix" in setCurrentTranslation I believe.
[11:56] <danilos> henninge, oh, you should not have changed setCurrentTranslation lightly
[11:56] <henninge> danilos: line 183 in test_setcurrenttranslation.
[11:56] <henninge> danilos: well, it is pretty isolated to other_side sharing but that is what is failing now.
[11:57] <danilos> henninge, some of the decisions in setCurrentTranslations are relatively arbitrary (i.e. we could have gone either way since it doesn't matter too much), but most of the critical ones are not
[11:57] <henninge> danilos: I don't understand why "the sharing policy has no effect"
[11:57] <danilos> henninge, I'll have to thing carefully about this particular case though
[11:58] <henninge> danilos: please do ;)
[11:58] <danilos> henninge, so, just to confirm we are looking at the same thing, it's test_c_None__n_None__o_shared__follows
[11:58] <henninge> right
[11:59] <henninge> danilos: but there are a couple more failing
[12:00] <henninge> danilos: all with "__follows"
[12:00] <henninge> that's what sets "share_with_other_side" on setCurrentTranslation
[12:00] <henninge> sets to *True*, obviously
[12:00] <bigjools> danilos: wake up
[12:01] <danilos> bigjools, coming
[12:01] <danilos> henninge, be right back
[12:03] <deryck> Morning, all.
[12:07] <danilos> henninge, ok, back to you
[12:07] <danilos> henninge, well, you did invert the logic in setCurrentTranslation completely for a few things :)
[12:08] <danilos> henninge, well, maybe not
[12:08] <danilos> henninge, I see you tried to move makeCurrent stuff into it though
[12:08] <henninge> danilos: what do you mean?
[12:09] <danilos> henninge, btw, I think your change for translation credits is wrong as well: translation credits does need to read explicitely from the upstream side
[12:09] <danilos> henninge, well, unsetting of the flag that makeCurrent* methods used to do
[12:10] <danilos> henninge, so, here's what I think we should do: keep makeCurrent* methods and switch them to the new model by using explicit UPSTREAM for getImportedTM and UBUNTU for getCurrentTM methods
[12:10] <danilos> henninge, note that we should not make those calls side-sensitive since it's obvious makeCurrent methods are already using the new model (just like the translation credits message is)
[12:11] <danilos> henninge, they are only using getCurrent/getImportedTM methods in a low-level way (explicit side requests, not expecting them to be side-aware)
[12:11] <henninge> danilos: hm, getCurrentTM *is* explicit about sides anyway.
[12:12] <henninge> danilos: I am not sure about keeping makeCurrent around.
[12:12] <henninge> danilos: I just think that my change to setCurrentTranslation was not correct
[12:12] <danilos> henninge, well, makeCurrent* is directly used by setCurrentTranslation (I didn't know that), which means that it's an integral part of the setCurrentTranslation design
[12:13] <danilos> henninge, please, don't try to fix setCurrentTranslation *now*
[12:13] <danilos> henninge, if you remember, we spent days on designing, implementing and providing tests for it
[12:13] <danilos> henninge, so, if shareIfPossible and makeCurrent* are used by it, they are "new model" methods and we should keep them
[12:14] <henninge> danilos: but I, too, remember that makeCurrent* was a temporary solution.
[12:14] <danilos> henninge, perhaps, but as a step from, if you remember, DB triggers!
[12:15] <danilos> henninge, they are still improvement enough over DB triggers
[12:15] <danilos> henninge, and we can worry about getting rid of them later, they are not critical and require much careful consideration which I'd rather not do right now :)
[12:16] <danilos> henninge, if you feel you can do that, make sure you do it without changing any setcurrenttranslation tests :)
[12:16] <henninge> danilos: well, I see which part of my change makes that test fail.
[12:16] <henninge> I just still don't understand why it's supposed  to work this way.
[12:17] <danilos> henninge, and make sure you back out this change: https://pastebin.canonical.com/41104/
[12:18] <danilos> henninge, the problem with how setCurrentTranslation is supposed to work is that it has many different conditions and they are hard to get unless you consider the whole picture
[12:18] <henninge> danilos: ah yes, I was guessing there ...
[12:19] <danilos> henninge, that's why we have constructed a matrix of things that need to happen, and you can read it on https://dev.launchpad.net/Translations/Specs/UpstreamImportIntoUbuntu/FixingIsImported/setCurrentTranslation
[12:20] <henninge> danilos: actually, reading the code for setCurrentTranslation last night helped me better undstand what is going on there.
[12:21] <danilos> henninge, I am sure it did, but some of it will not be clear from reading the code, because we 'unified' different matrix cells when what we wanted was for the same things to happen
[12:25] <danilos> henninge, if you really want to get rid of makeCurrent, you'll have to modify A and B actions in the matrix (which call setFlag)
[12:25] <danilos> henninge, good side of that approach would be that you should already have all the relevant messages that you might need to unset
[12:27] <henninge> danilos: test_setcurrenttranslation is passing again ;)
[12:27] <henninge> without makeCurrent* and just one line change in setCurrentTranslation
[12:27] <danilos> henninge, heh, did you remove it? :P
[12:27] <danilos> henninge, which one line is that? :)
[12:28] <danilos> henninge, don't forget there's a possibility that we forgot some tests even though there's like a million of them :)
[12:28] <henninge> https://pastebin.canonical.com/41106/
[12:28] <henninge> Remove a flag before setting it.
[12:29] <henninge> Without that it is causing erros elsewhere (withoug makeCurrent*)
[12:30] <henninge> danilos: I reverted the canges to the '*' action but that is the one I don't understand yet.
[12:30] <henninge> danilos: I don't see why I'd need to change 'A' and 'B' actions because they just unset flags.
[12:30] <henninge> danilos: what we lose by not using makeCurrent* is the unsetting of flags.
[12:30] <danilos> henninge, right
[12:31] <danilos> henninge, sorry, my bad :)
[12:31] <henninge> that' ok ;)
[12:31] <danilos> henninge, so, I guess you should go on with removing makeCurrent* methods then :)
[12:32] <danilos> henninge, it is basically a missing method if we compare it with the wiki page
[12:33] <danilos> henninge, btw, I'd say it'd probably be a good idea to mention https://dev.launchpad.net/Translations/Specs/UpstreamImportIntoUbuntu/FixingIsImported/setCurrentTranslation in the comments of _setTranslation somewhere
[12:34] <danilos> henninge, and look through "Capture the flag" section on that wiki page to understand why is '*' like it is
[12:37] <henninge> danilos: ah yes, I remember reading about "Capture the flag"
[12:37] <henninge> don't think I understood it back than, either :-P
[12:37]  * henninge tries harder this tim
[12:37] <henninge> e
[12:43] <danilos> henninge, do not forget that action '*' or '+' happen only after A/B/Z and a numbered action has gone through
[12:44] <henninge> yes, thanks.
[12:44] <danilos> henninge, that's why the need for makeCurrent* is removed in all other actions, but seems jtv only forgot to implement the line you are adding
[12:45] <henninge> danilos: Reading through the "guiding principles" I see that it may conflict with the sharing policy we discussed at a higher level.
[12:46] <henninge> danilos: I was asking you yesterday "when it comes to calling setCurrentTranslation, the decission if this new translations should be shared has already been made"
[12:47] <henninge> "it is passed into setCurrentTranslation as share_with_other_side"
[12:47] <danilos> henninge, yes, exactly
[12:47] <henninge> We had discussed that uploads on the upstream side would automatically update Ubuntu translations but not the other way round.
[12:48] <danilos> henninge, it should still worry about unsetting the flags, I just forgot a few bits of the design myself :)
[12:48] <danilos> henninge, yes, that's how it should be implemented today
[12:48] <henninge> setCurrentTranslation prevents that by design, though, AFAIUI
[12:49] <henninge> "stealing the flag" only happens if the other side is untranslated.
[12:49] <henninge> otherwise "share_with_other_side" is ignored.
[12:49] <henninge> I think.
[12:49]  * henninge needs to read to the end.
[12:50] <henninge> danilos: oh sorry, I think I found my error in thinking
[12:51] <henninge> Upstream uploads only update Ubuntu translations if they were not changed on the Ubuntuside.
[12:52] <henninge> I forgot about that. Never mind my rambling ...
[12:52] <henninge> ;-)
[12:58] <danilos> henninge, heh, don't worry
[12:58] <danilos> henninge, anyway, try to get that branch into landable state asap, I want it behind us today :)
[12:59] <henninge> danilos: I am currently re-running lp.translations tests on it. See what's left.
[12:59] <henninge> I am also going to revert the the renaming of getImportedTranslationMessage to reduce the branch size.
[12:59] <danilos> henninge, cool
[13:02] <henninge> only two failures left ...
=== matsubara_ is now known as matsubara
[13:40] <pcjc2> Hi, One of our users uses a text based web-browser, and whilst LP works really well on my local instance with that browser, the Launchpad OpenID provider causes it problems
[13:40] <pcjc2> Is the code for the LP OpenID provider available somewhere?
[13:41] <pcjc2> The bug is pretty trivial actually.. the "Continue" button on the login page is served up with a "<button>" element, rather than an "<input ....  type=button>", which that web browser doesn't support
[13:41] <pcjc2> The dummy OpenID provider in the LP checkout does not have that problem
[13:59] <benji> pcjc2: I think a bug has been filed for that; let me see if I can find it
[14:04] <benji> pcjc2: https://bugs.launchpad.net/launchpad/+bug/523229
[14:04] <_mup_> Bug #523229: The Continue button isn't selectable in w3m for sso login <iso-testing> <lp-foundations> <Canonical SSO provider:Won't Fix> <Launchpad itself:Triaged by gary> < https://launchpad.net/bugs/523229 >
[14:06] <pcjc2> ok, shame its wontfix
[14:07] <pcjc2> ah - just in the SSO provider, never mind
[14:17] <gary_poster> pcjc2: work-around is to install elinks.  Use it with env variable (BROWSER=elinks).  The change I'm trying to get is to have the w3m <button> support in natty backported to maverick and lucid.
[14:18] <pcjc2> A question of user preference I'm afraid... but thanks though - I've pointed the user at the bug report, and hopefully he'll be able to find the newer package. He's in Debian I believe
[14:18] <gary_poster> cool pcjc2 .
[14:18] <pcjc2> It was just one nit in the process of moving our projects bugs to LP - some of our users might come off as "strange" in their preferences for softwar
[14:18] <pcjc2> e
[14:19] <gary_poster> :-) I know the same could be said of me
[14:19] <pcjc2> One refuses to use anything modern, and back-ports everything to some old UNIX variant with ~1 user in the world
[14:19] <gary_poster> heh
[14:20] <pcjc2> (This wasn't the guy in question.., but I believe the reporter of the W3M issue is still running on a 486 or something)
[14:20] <gary_poster> heh
[14:20] <pcjc2> (Hell - I have BBC micros in the loft for the sake of nostalgia, but I don't try to do work on them any more ;))
[14:23]  * benji shovels coal into his steam-powered laptop.
[14:32] <danilos> henninge, hi, how is the branch coming along?
[14:32] <henninge> danilos: I am was just about to prepare the mp.
[14:32] <danilos> henninge, cool
[14:32] <pcjc2> OT: Just a quote which came in today from that user  - "I read all my mail raw exactly as it comes across the wire, without using *any* MUA that does any decoding behind my back.  I have a little program I wrote myself that decodes base64, but it's a major PITA."
[14:33] <pcjc2> "Hence if mail arrives in base64 and neither its source nor its subject line give a strong signal that it's important, it usually gets deleted by the firmware in my fingers without ever reaching my eyeballs.  Any responses to this message that are encoded in base64 are likely to receive such fate."
[14:33] <pcjc2> We tend not to pander to him too much ;)
[14:33] <henninge> danilos: but I don't think it still fits the bug ... or the kanban card.
[14:33] <danilos> henninge, oh well, I wouldn't worry about that too much
[14:35] <danilos> pcjc2, sounds very "smart", what does he do if I use my real name in Cyrillic when I try to email him? "unknown sender, delete" :)
[14:35] <pcjc2> No idea.. He's Russian I believe.. but he believes all computers should be in English, and no time wasted on i18n
[14:36] <pcjc2> He's a nice enough guy... just a reminder that you can meet some very strange people on the interweb
=== salgado is now known as salgado-lunch
=== Ursinha is now known as Ursinha-brb
[15:08] <danilos> bigjools, IBuildFarmJob doesn't specify .build at all, I am very much surprised to see it being required
[15:08] <bigjools> danilos: it's delegated I think
[15:09] <danilos> bigjools, to what?
[15:10] <bigjools> specific_job
[15:10] <bigjools> IIRC
[15:10] <pcjc2> Is it normal for "bin/test bugimport" to take about 35-40 seconds?
[15:12] <danilos> bigjools, but what interface are specific_jobs supposed to implement?
[15:12] <danilos> bigjools, afaics, BuildFarmJobDerived delegates to BuildFarmJob but none of them implement .build
[15:13] <bigjools> danilos: see lib/lp/soyuz/model/buildpackagejob.py
[15:14] <bigjools> danilos: looks like it's not in the interface.
[15:17] <danilos> bigjools, that doesn't answer my question: what should .build be at all
[15:17] <bigjools> danilos: it's either a binarypackagebuild or a sourcepackagerecipebuild for the other job types
[15:17] <bigjools> does that map to the ttbj jobs?
[15:18] <danilos> bigjools, I am not sure it does, and that is the whole problem
[15:18] <bigjools> ah :/
[15:18] <danilos> bigjools, well, we do have translationtemplatesbuild job but that is an IBuildFarmJob (BuildFarmJobDerived) as far as I can see
[15:18] <danilos> bigjools, it sounds weird for it to link to itself via .build
[15:19] <danilos> bigjools, that's why we probably have this confusion in the first place
[15:20] <danilos> bigjools, and it seems PackageBuild is also inherits from BuildFarmJobDerived
[15:21] <bigjools> this whole model is a nightmare at the moment
[15:21] <bigjools> loads of it is still there to support non converted jobs but I don't know what any more
[15:22] <danilos> bigjools, right, this is what sounds weird: BuildPackageJob inherits from BFJD (BuildFarmJobDerived), and .build points at a BinaryPackageBuild which inherits from BFJD as well
[15:23] <danilos> bigjools, so, it seems as if we are either using the same data structure for two different things or that I am very confused :)
[15:23] <danilos> bigjools, if we simply implemented .build to point at self in TranslationTemplatesBuild, I wonder what would happen :)
[15:24] <danilos> bigjools, basically, the problem is that we don't need that much indirection in translations
[15:24] <danilos> bigjools, maybe we do because of the buildmaster design, but it seems neither noodles nor abentley are around today :(
[15:25] <bigjools> danilos: the indirection is there because it's trying to support the old model as well
[15:25] <bigjools> we need to remove it and it will all become simpler
[15:25] <bigjools> but right now I have not been involved enough in that to sort it out
[15:25] <bigjools> we could ask wgrant to take a look
[15:26] <danilos> bigjools, right, so basically, I think that we just need to remove that and start using the new TranslationTemplatesBuild classes instead of the old ones
[15:26] <danilos> bigjools, perhaps the way to simplify this in translations is to put .build on *old* translation build class pointing to the new translation build class
[15:26] <danilos> would that be correct?
[15:26] <bigjools> I can't say with any certainty
[15:26] <bigjools> sorry to be useless
[15:27] <danilos> bigjools, heh, you probably have at least a better idea than I do, that sounds like an easy thing to do, and I'll ask around (email noodles and abentley to see if that's correct)
[15:27] <bigjools> danilos: noodles would be the best start
[15:28] <danilos> bigjools, right, thanks
=== salgado-lunch is now known as salgado
[16:08] <bigjools> do we have any tests for the front page?
=== deryck is now known as deryck[lunch]
[16:10] <bigjools> mrevell, when you've changed it before did you need to fix tests?
[16:10] <mrevell> bigjools, No, certainly not for when I did what's new, but I think flacoste made the most recent big change to the front page so he may have more recent info on test coverage.
[16:14] <bigjools> I can't see anything referencing the "Getting started" section either.  I guess for such a simple page it's hardly worth tests.
=== beuno is now known as beuno-lunch
[16:31] <jam> jml are you around? Or really anyone with twisted experience
[16:52] <jam> I should mention that my above load test contrasts with being exactly 0.98 to the ssh loopback at any load level.
[17:02] <EdwinGrubbs> bigjools: ping
[17:02] <bigjools> EdwinGrubbs: 'sup
[17:02] <EdwinGrubbs> bigjools: I'm working on the bug to prevent a person/team from being merged while it has a ppa.
[17:03] <bigjools> ok
[17:03] <EdwinGrubbs> bigjools: in your comment on the bug, you said that it could have the same restriction as for renaming a person, which is to prevent renames if the person has a ppa with published packages.
=== al-maisan is now known as almaisan-away
[17:05] <EdwinGrubbs> bigjools: sinzui and wgrant pointed out that the ppa might show up in searches, and that the ppa would have to be in a DELETED status before it is merged, since it uses the user name to determine the directory that it will delete, and merge persons have "-merged" appended to the name.
[17:05] <bigjools> EdwinGrubbs: yes, the code that is used in renaming can be re-used for blocking merging, it does that already
[17:06] <EdwinGrubbs> bigjools: but shouldn't we block merges even if the ppa does not have a published package?
[17:06] <bigjools> EdwinGrubbs: the code that's used in renaming DTRT
[17:07] <bigjools> either (has publications and is DELETED) OR (has no publications ever)
[17:07] <sinzui> EdwinGrubbs, bigjools read the last comments on bug 684112
[17:07] <_mup_> Bug #684112: Link to PPA merged owner from +archivesubscriptions is broken <404> <lp-registry> <merge-deactivate> <tales> <trivial> <Launchpad itself:Triaged> < https://launchpad.net/bugs/684112 >
[17:07] <sinzui> EdwinGrubbs, bigjools I think my suggest is bad. I suspect that the clean up proc will never remove the directories because the user/team names have changed
[17:08] <bigjools> sinzui: indeed, I had overlooked that
[17:08] <bigjools> it needs a manual cleanup to get the orphaned PPA repos
[17:08] <sinzui> bigjools, the list is small. could re prepare a shell script to remove them?
[17:09] <bigjools> should be fairly trivial, we just get a list of all repos and check that they are valid in LP
[17:13] <EdwinGrubbs> bigjools: another question: since a ppa in DELETING status says that it is "Deleted", it will be annoying and confusing that they still can't merge the person, because the ppa needs to be in DELETED status. How long should I tell the user to wait before trying to merge again?
[17:13] <bigjools> EdwinGrubbs: 5-10 minutes, we need to wait for the publisher cron job to run
[17:14] <EdwinGrubbs> ok, thanks
[17:17] <bigjools> gee, a message queueing system would sure be useful :
=== benji is now known as benji-lunch
=== deryck[lunch] is now known as deryck
[17:56] <jcsackett> sinzui: we're generally trying to clean up use of "assert something" and actually do proper exception raising these days, right?
[17:57] <sinzui> jcsackett, yes
[17:57] <jcsackett> okay, thanks.
=== beuno-lunch is now known as beuno
=== benji-lunch is now known as benji
[18:32] <jcsackett> henninge: when you return, there are comments/questions on your MP.
[18:36] <jcsackett> ...wrong channel.
=== salgado is now known as salgado-brb
=== salgado-brb is now known as salgado
=== Ursinha-brb is now known as Ursinha
=== EdwinGrubbs is now known as Edwin-afk2
=== Ursinha-afk is now known as Ursinha
=== Ursinha is now known as Ursinha-afk
=== Ursinha-afk is now known as Ursinha
[21:03] <deryck> later on, all.
[22:02] <salgado> bac, I'm jealous of you; I wish I could've deleted all that poll code
[22:02] <bac> salgado: yeah, i know
[22:03] <salgado> and then close all those bugs as won't-fix/invalid
[22:03] <salgado> it must've felt good. :)
[22:03] <bac> salgado: it is kind of sad, though.  i wish it would've been a viable feature
[22:04] <salgado> indeed, but this was yet another feature we directed too much time that would be better spent improving other things. IMHO
=== fjlacoste is now known as flacoste
[22:04] <bac> salgado: oh, i agree killing it off at this point was the right thing.
[22:35] <lifeless> once we get on top of things
[22:35] <lifeless> fast
[22:35] <lifeless> easy to use
[22:36] <lifeless> etc
[22:36] <lifeless> we can revisit these little-apps
=== salgado is now known as salgado-afk
=== matsubara is now known as matsubara-afk