[00:00] Otherwise you're counting bugtasks instead of bugs. [00:05] sinzui: still ok? [00:07] jtv: I can tune this. I think 150 should be the minimum heat threshold because that is the minimum number for a private bug [00:08] well, 250 might be best because private bugs are not community driven, but security are, which is 250 [00:08] sinzui: how does bug privacy factor into it all? [00:09] jtv: I am reading the heat calculator. It add 150 points [00:09] oh ah [00:10] I am sure the numbers are arbitrary. so are mine. I just want to get the packages that need the most love to be listed first [00:10] sinzui: do you see a big performance difference between those threshold? [00:10] s [00:11] jtv: 67.82..27941.89 is better than 85994.40..85994.40 [00:11] sinzui: uh yes, looks like [00:14] sinzui: you could multiply the bug count by some factor to compensate. The ideal factor might be something like the average bug heat for bugs that stay below your chosen threshold. [00:15] jtv: maybe: The heat filter keeps the top packages 100 very distinct [00:16] sinzui: you mean it sets them very far apart from the packages further down the list? [00:17] yes, there is less variation in the mid range of packages because their bug heat scores are 0 [00:18] In the context of this list, do you care a lot about those packages? [00:19] Because maybe the list should just stop at some pseudo-arbitrary point. [00:26] Is anyone tackling the merge conflict from stable -> db_devel? [00:26] thumper: i'd got as far as thinking about it [00:28] thumper: seems trivial to fix, i'll do it [00:28] mwhudson: ta [00:29] mwhudson: rs=me if you don't want to rs=you :) [00:29] heh thanks :) [00:32] sinzui: I'm off... good night & good luck! [00:32] me too [00:35] * mwhudson lunches [00:46] https://wiki.ubuntu.com/PackagingGuide/PatchSystems [00:46] bah sorry [01:20] mwhudson: Add a new code import result for success of partial import [01:20] mwhudson: was that the commit that you fixed after [01:20] ? [01:20] mwhudson: just wondering about the qa status [01:20] thumper: yeah, that's the commit that was fixed in two followup branches [01:21] mwhudson: we should change it's status to FIXED [01:21] mwhudson: I'm not sure I like the RCFIXED, as it wasn't an RC [01:21] mwhudson: perhaps just move it to OK now [01:21] thumper: ok [01:21] thumper: well, the fix hasn't been QAed [01:21] ah [01:21] poo [01:25] yep === bjf is now known as bjf-afk [02:19] jml: you on? [02:19] * kfogel guessing not... [02:19] thumper: ah, but you might know: do we have any bugs filed for work on patch/branch equivalence? [02:20] or story pages, etc? [02:21] mwhudson: ^^ (if you know) [02:22] kfogel: i don't know of anything formal [02:22] mwhudson: thanks [02:22] mwhudson: I'm looking at bugs and branches under ~jelmer, just to see [02:26] kfogel: what exactly are you interested in? [02:26] kfogel: worth skyping about? [02:27] thumper: hmrmrm. It is worth skyping about, but I can't do a skype right now (need to wrap up this draft blog post about the new patch report feature). I'm just listing, at the end of the blog post, some of the stuff we haven't gotten to yet, and that's on the list. If there were a bug or a spec to link to, I'd link to it. [02:27] I don't think there is a bug about it [02:27] kfogel: one thing we haven't gotten around to [02:28] kfogel: is automatically turning a patch into a branch if it applies to trunk cleanly [02:28] thumper: :-) yes, that's one of the things I'm mentioning in the post [02:42] thumper: you can't see this, right? http://blog.launchpad.net/?p=1356 [02:46] * thumper looks [02:46] nope [03:27] mwhudson: ping [03:27] thumper: pong [03:28] mwhudson: what version of pygments are we using ATM? [03:28] thumper: good question [03:28] mwhudson: easy to find out? [03:28] mwhudson: is it an egg? [03:28] no, i think it's from the package [03:29] could/should switch to an egg though [03:29] thumper: seems like 0.9-2 [03:30] hmm... [03:30] bug 392406 [03:30] mwhudson: why should? [03:30] Bug #392406: Update Pygments library to version 1.1 or later [03:30] lifeless: easier for us to upgrade, more in line with what we do for everything else [03:31] mwhudson: I don't really like what we do for everything else ;) [03:31] its odd for us, a large chunk of an OS vendor, to ignore the OS for our products. [03:33] lifeless: i am having a little difficultly composing a civil reply here [03:33] :> [03:33] troll:1 burdened-programmer:0 ? [03:33] i guess [03:33] I wasn't intending to troll, but I realise picking one package isn't a good way to change the systemic approach [03:34] right [03:34] so - sorry; and please get back to what you're doing [03:34] thanks! [03:38] mwhudson: bug 153779 still an issue? [03:39] * thumper wanders off, back UK morning time [03:45] thumper: not really i guess [03:45] * mwhudson closes it [03:46] * mwhudson EODS [03:46] not the most productive day, oh well [03:46] heh [03:46] I have had similar [03:46] slow progress [03:46] maybe staging will be magically up to date when i start tomorrow [03:57] It does seem particularly strange to me that a product from an OS vendor does not use a custom archive of dependencies, when a large part of the product is designed to produce custom archives. [08:27] good morning [09:37] When are the buildds expected back? [09:37] This is the longest queue I have ever seen. [09:37] I haven't heard. bigjools ^^ [09:38] I don't know [09:38] * noodles775 tries to find out. [09:38] 12 hours is way beyond "absolutely ridiculous" territory. [09:38] FWIW the PPA service only has 4 builders, the others are a bonus [09:38] (per arch) [09:39] I thought it had only three. [09:39] you could be right [09:39] we're getting some more but they will be reserved for daily builds [09:39] Hmmm. [10:45] henninge: Hi. do you have time to land my last branch review or should I ask the OCR ? https://code.edge.launchpad.net/~adiroiban/launchpad/bug-509252-take-2/+merge/19484 [10:46] adiroiban: oh sorry, forgot about that. Sure. Does it have a commit message? [10:46] adiroiban: ah, yes it does ;) [10:47] henninge: yes. and I have updated it [10:48] adiroiban: ok, landing it now. [10:49] henninge: if you have time, can you also QA the fix for this bug https://bugs.edge.launchpad.net/rosetta/+bug/127171 ? [10:49] Bug #127171: Rosetta experts not allowed to "Change translators" [10:49] I don't have rosetta admin rights [10:49] so I don't know how to test it on edge [10:49] adiroiban: we can probably make you an admin on staging [10:50] henninge: that is also OK [10:50] danilo__, danilos: ^^? [10:50] adiroiban: as a reminder: Please don't push to the branch anymore now that it is landing. [10:51] henninge: ok [10:51] henninge, /me is thinking... are there any privacy concerns? is rosetta-admins subteam of any generic team? [10:53] danilos: I just need that to test that fix [10:53] if some of you can qa it [10:53] it's ok for me [10:55] henninge, adiroiban: I've looked and it seems it's ok, I'll just do it and let Adi QA this :) [10:55] adiroiban, haha, there's also "Poor Adi" account, nice name for what I assume is a testing privilege-less account :) [10:55] adiroiban, anyway, you should be in rosetta-admins on staging now [10:55] danilos: yep :) [10:56] adiroiban, fwiw, staging will be refreshed sometime on weekend, so that's until when you've got the chance :) [10:57] danilos: ok. well I will try to qa it now as I will not have time on friday weekend [10:57] adiroiban, cool, thanks [10:58] and I don't want to fix it when pqm is closed [11:02] Morning, all. [11:03] danilos: can you please target this bug for the next release https://bugs.edge.launchpad.net/rosetta/+bug/462013 [11:03] Bug #462013: Don't ask me to import obsolete templates [11:03] I think this is requred to me marked as „fix-released” [11:10] deryck: Do you have access to run a SELECT on staging? [11:10] gmb, I do, yeah. [11:10] deryck: Could you run http://pastebin.ubuntu.com/383617/ and paste me the output? [11:11] * gmb neatly sidesteps a) the LOSAs being sprinty and b) the fact that staging is 10 revs behind where he needs it to be. [11:11] gmb, sure. doing now.... [11:11] Thanks. [11:12] gmb: when you have time, can you please try a new landing for https://code.edge.launchpad.net/~adiroiban/launchpad/bug-522188/+merge/19395 ? Thanks! [11:13] adiroiban: Sure, it's already on my list for today :). [11:13] :) [11:28] intellectronica, https://code.edge.launchpad.net/~deryck/launchpad/max-heat-by-target-511382/+merge/19998 [11:29] deryck: as it happens i already read through it and ran it working on the patch for updating the column, so r=me :) [11:29] intellectronica, excellent! easy-peasy. Thanks! :-) [11:29] deryck: actually, scratch that. did you want me to review just the db patch, or the rest of the code? [11:30] intellectronica, the code [11:30] if the latter then i need to go through it more thoroughly [11:30] ok [11:30] intellectronica, yeah, the code. stub and BjornT are on the patch. [11:34] deryck: i'm wondering, isn't there a more general getOrCreate sort of thing for DSPs? this can't be the first time we do this in the code [11:34] and even in your test you repeat the code twice [11:35] ehrm, not in the test, in the distro model object [11:36] maybe bigjools will know if there's something like that [11:36] intellectronica, hmmmm, let me look at the diff.... and I greped for something and didn't find anything, and I was also following what is already there for another bit of code. [11:36] intellectronica, ah, I see what you mean, to get the DB version of the class. [11:36] whu what? [11:36] deryck: yes [11:37] bigjools: is there a standard getOrCreate thingster for DistributionSourcePackageInDatabase ? [11:37] I have no idea, Gavin wrote it! [11:37] a getOrCreateDistributionSourcePackageInDatabase :) [11:37] I'd be looking for it [11:38] intellectronica, I copied the bits from what I assume Gavin had before, but I can refactor into a nicer getInDB method. [11:38] I did think about that and never went back. [11:39] deryck: if there isn't anything already in existence i'm fine with just filing a bug for doing it later (if you don't want to spend time on it now) [11:40] deryck: why do we need a set on distroseries if all it does it delegate it to the distro? [11:40] isn't it better to just not implement it? [11:41] intellectronica, but in the distro series bug view you'll have to get at the max_bug_heat for that, right? I thought it made using max_bug_heat less tricky if everything implemented it. [11:42] deryck: yes, it makes sense to have a getter, but does it make sense to have a setter [11:43] since we don't currently have any code that relies on it, i think it might be better to throw a NotImplementedError or something [11:43] intellectronica, ah, right. Yeah, I went back and forth on that. I don't know that it makes sense. You would never set on the series, but there's no harm in doing so. [11:43] intellectronica, and given past bugs I fixed I have a nervousness about NotImplementedError :-) [11:43] deryck: in fact, i'm not even sure we need a setter anywhere. as i just discussed with stub, it looks like we'll update this column from a trigger. [11:44] though i guess at the very least it's useful for testing [11:44] intellectronica, yeah, that was my reaction. without a setter, from the test's pov it's just a useless attribute. [11:45] deryck: so, i rather not set if it's done through delegation, because it can be confusing and lead to subtle errors. if you throw an error then whoever is trying to write to the attribute will become aware of the way it's implemented and do the right thing [11:46] intellectronica, good point. I'll do that then. [11:46] cool [11:47] deryck: r=me with that change [11:49] intellectronica, excellent. thanks! [12:37] adiroiban: What is the 'archive name' of a source package? [12:37] wgrant: repository [12:38] maybe the info is already available in API... but it is not obvious how to retreive it [12:39] A SourcePackage doesn't really have an archive. [12:39] Except potentially primary vs. partner. [12:40] ah... [12:40] looks like in the UI is called component === matsubara-afk is now known as matsubara [12:40] https://edge.launchpad.net/ubuntu/karmic/+source/kubuntu-docs [12:40] Oh. that's something completely different to an archive or a repository. [12:41] it may be... [12:42] but on the Internet [12:42] it is said that an Ubuntu package is part of main or universe repository [12:43] They are wrong :) [12:43] The term has always been component, both inside and outside Launchpad. [12:43] yep. someone is always wrong on the Internet :) [12:43] I will update the bug report [12:45] * wgrant looks around for somebody who can be bribed into bumping a build score. === thekorn_ is now known as thekorn [13:41] three cheers for adeuring killing 4 bugs with one branch. errr, 4 cheers, then. [13:49] deryck: thanks but the cheers should go to sinzui [13:49] he does know our bugs well now. [13:50] adeuring: It would have been cruel for me to ask you to fix it without first finding out why the page has been broken for 18 months [13:53] wgrant, i'm looking at https://code.edge.launchpad.net/~wgrant/launchpad/export-das-chroot/+merge/19759 [13:53] can you explain to me what exactly a chroot is? some sort of massive file stored in the librarian? [13:54] leonardr: yep, it's a tarball of a filesystem stored on the librarian and used by the buildds when building packages [13:55] leonardr: "massive" being about 60MiB a the moment, but potentially some hundreds of megabytes. [14:10] wgrant: i haven't swapped in all the details yet, but to publish a librarian file on the web service you should export a Bytes field [14:10] the example i'm working from is IBugAttachment.data [14:11] leonardr: But that's not going to do anything useful like giving me hashes, is it? [14:12] wgrant: it will not give you hashes, but it will let users read the librarian file from within launchpadlib rather than having to fire up httplib2 to grab the librarian url [14:14] leonardr: what's stopping us from exporting ILibraryFileAlias? [14:15] BjornT: well, there's no code in lazr.restful for that because the library file alias is launchpad-specific [14:15] but there is code in lazr.restful for publishing 'bytes' fields as generic hosted files, and code in launchpad for hooking up LibraryFileAlias to that implementation [14:16] Could one not easily export ILFA with a Bytes field inside it? [14:17] wgrant, what information does your end-user want? [14:17] leonardr: I would like to be able to verify the content of the files, given that I downloaded them over HTTP. [14:18] so like the md5 sum? [14:19] Yes. [14:20] ok, i filed a bug at one point to publish a json representation of a hosted file resource which would contain that information [14:20] Thanks. [14:20] this would be a change to lazr.restful (and to the launchpad implementation of the hosted file), and publishing ILibraryFileAlias vs publishing IBytes would not change anything [14:20] i'm trying to find that bug [14:21] i really hate how that bug could have been filed in one of four projects [14:21] Hmm. [14:21] wgrant: see if this is what you want [14:21] https://bugs.edge.launchpad.net/lazr.restful/+bug/406912 [14:21] Bug #406912: Publish a JSON representation of a binary file containing metadata [14:23] leonardr: Looks good to me. [14:23] ok, i'll respond to the review [14:23] Thanks. [14:23] wgrant: shall i add on to this bug that you requested the md5 sum of the file? [14:23] leonardr: i just find it odd that in python code we say that an attribute is an ILFA, while we have to export it as Bytes. seems easier and more intuitive if we could export ILFA themselves, with a Bytes field inside them. [14:23] leonardr: And the other hashes, too. [14:24] wgrant: i don't know what other hashes you're refering to [14:24] oh, sorry [14:24] i thoguht you meant hash as in the data structure [14:24] Ah, no, the cryptographic variety, sorry. [14:25] bjornt: i'm doing research to understand what you mean, but lazr.restful wouldn't care what is inside an exported field. if we got some way to export ILFA, then some representation of the ILFA would go into the entry's representation, and that's is [14:25] s/is/it/ [14:27] good morning Launchpadders [14:27] wgrant, are you visiting New Zealand or perhaps some Pacific island? [14:27] wait. [14:27] wgrant, I mean, are you visiting Perth or perhaps some island in the Indian Ocean? [14:29] jml: No.. [14:29] It's not yet 1:30. [14:31] wgrant, that's still kind of late :) [14:34] jml: I blame Enablement for making PPA builds take too long. [14:35] But it looks like my build still isn't going to happen for at least another hour, so i might as well sleep. === henninge_ is now known as henninge [14:41] BjornT: the basic reason is that lazr.restful is not part of launchpad, so it can't know anything about ILibraryFileAlias [14:42] if this was a huge problem i could put some indirection in place such that ILibraryFileAlias could substitute for Bytes, but i just don't consider it that big a problem [14:43] leonardr: right. i was talking about how we export things in LP. [14:43] me too [14:45] there's a slight possibility you could get it to work by making ILibraryFileAlias subclass Bytes, but if that doesn't work i don't think it's worth putting in additional work [14:45] s/Bytes/IBytes/ [14:46] leonardr: i don't get why we need to hide ILFA. Bytes and ILFA are different things. why does the exported API need to be different from our internal API? [14:48] BjornT: when the web service starts up, the launchpad classes are run through lazr.restful [14:49] when lazr.restful encounters a published Bytes field, it thinks "this is a hosted binary file" [14:49] and when the time comes to create a representation of it, lazr.restful performs a lookup, adapting the field to some interface (provided by launchpad) [14:50] when lazr.restful encounters a published ILibraryFileAlias field, it thinks "i've never heard of this", and crashes [14:51] hi. do you know where I cound find some info about how to write API tests? I was looking at this API https://api.launchpad.net/+apidoc/#translation_import_queue_entries , and grepping the whole source tree after „translation_import_queue_entries” did not reveal any test [14:52] leonardr: but ILibraryFileAlias have (or should have) a Bytes field for its content, and ILibraryFileAlias could be exported just like any other interface, like IBug, IPerson, etc. no? [14:53] bjornt: ok, you want to publish ILibraryFieldAlias as an entry, not a field [14:53] i didn't understand that [14:57] bjornt: what you describe is technically possible, and it's the launchpad team's decision how to do that, but i think publishing the hosted file as a Bytes field would give a better end-user experience [15:00] bjornt: because right now you have, eg. a bugattachment object that has a 'data' field [15:00] right now you can do something analogous to open(bugtask.attachment.data).read() [15:01] if data was an ILibraryFileAlias then that would be open(bugtask.attachment.data.file).read() [15:01] but it should still be possible [15:02] leonardr: well, i see now that IBugAttachment is lying. it says that IBugAttachment.data is a Bytes field, yet BugAttachment.data is an ILibraryFileAlias [15:04] we should make sure that our content objects provide what the claim to provide === matsubara is now known as matsubara-lunch [15:08] bjornt: unless ILibraryFileAlias can subclass IBytes i don't see any good way to resolve that problem [15:08] flacoste might be able to help [15:09] leonardr: i think there are a few options, although i'm not sure how feasible they are. one is of course to have our exported API to behave the same way as our internal API [15:09] actually, we could define a new interface in lazr.restful and have ILibraryFileAlias subclass that [15:10] leonardr: if we want to have it work like it works today, we could mark ILibraryFileAlias, and say that this is our hosted file, and provide an adapter, or something like that [15:10] bjornt: how about this. define lazr.restful.interfaces.IHostedFile [15:10] have ILibraryFileAlias subclass IHostedFile [15:10] change lazr.restful to treat IHostedFile the same way it treats Bytes [15:10] use IHostedFile instead of Bytes in launchpad [15:11] leonardr: what would IHostedFile look like? [15:12] BjornT: i don't think it has to have any fields [15:12] this is work i don't want to do, but it should work [15:13] leonardr: i think your idea sounds good, the end result is that we want to be able to export a Bytes or LibraryFileAlias field as a hosted file [15:13] leonardr: why do we call export_as_webservice_entry() when exporting interfaces, rather then subclassing marker intefaces? [15:19] leonardr: or a better question: does lazr.restful deal with ILibraryFileAlias, or LibraryFileAlias to make the decision that it's a hosted file? [15:27] BjornT: lazr.restful deals with Bytes to make that decision [15:27] the only Launchpad-specific code it uses in this process is lib.canonical.launchpad.rest.bytestorage.LibraryBackedByteStorage [15:28] basically it adapts the Bytes object to IByteStorage [15:28] and launchpad says the IByteStorage adapter to use is LibraryBackedByteStorage [15:28] LBBS hides all the details of LibraryFileAliases, how to create and delete them, etc [15:29] so the change i'm proposing is to replace Bytes with IHostedFile, and adapt IHostedFile to IByteStorage [15:33] leonardr: so it doesn't make sense to say that LibraryFileAlias is an IHostedFile then? if so, it seems like you should mark ILibraryFileAlias, rather then subclassing. but i'm not sure i follow completely === matsubara-lunch is now known as matsubara [15:53] bjornt: it makes sense to say that LibraryFileAlias is an IHostedFile, but it doesn't make sense to tell lazr.restful anything about LibraryFileAlias === salgado is now known as salgado-lunch [16:00] intellectronica: http://paste.ubuntu.com/383753/ For larger maxet values, you'll get a sort of "gap" after the relative heat 2/3 [16:00] intellectronica: but i think ii have a proposal for a better function [16:00] just a second [16:07] intellectronica: http://paste.ubuntu.com/383761/ is at least "smoother" [16:35] intellectronica: I'm getting quite bad error in lib/lp/bugs/tests/../stories/bugtask-searches/xx-listing-basics.txt with your branch [16:40] adeuring: damn [16:40] let me check [16:41] noodles775: still around? [16:42] adeuring: yeah, i'm getting the errors too. looking at them now [16:44] abentley, your superseded comments stuff is made of awesome. [16:45] Thanks, but you designed about half of it. [16:45] rockstar, chat? [16:46] abentley, gimme a bit to clear the backlog of reviews here. [16:46] rockstar, sure. [16:54] intellectronica, I just merged you branch and will push up now. If you're fixing errors could you merge our combined branch, or else branch new from me? [16:54] intellectronica, since I fixed some of the changed elements. [16:55] deryck: sure, i'm remerging your branch [16:55] will ping you when i've got a fix for you guys to pull [16:55] intellectronica, still running a test.... a minute more and will push up the version from me. sorry. [16:56] I started the test before I saw the scrollback here. ;) [16:57] intellectronica, it's up now. thanks! [16:57] cheers [17:00] eod! eod! eod! [17:07] deryck: strange, i get ForbiddenAttribute: ('max_bug_heat', ) [17:07] could it be that wer're missing the zcml to allow the new attribute or something? [17:08] intellectronica, hmmm, maybe. and I just realized I haven't done the NotImplementedError you suggested yet. Sorry. [17:08] intellectronica, yeah, I bet DSP needs some zcml. Sorry. because I used zopeless layer in test it by passes that check, right? [17:09] deryck: yeah, i now see that dsp uses the verbose attribute-by-attribute format for permissions [17:09] i'll fix it in my branch, since you have to re-merge it anyways [17:10] excellent. thanks! [17:12] whoa, it gets weirder. after fixing the permission problem i get 'InternalError: transaction is read-only' [17:15] deryck: too early to tell, but my first guess is that something is not ok with your getOrCreate trick [17:16] deryck: i pushed the fixes in my branch, if you want to look [17:16] intellectronica, ok, thanks. [17:16] deryck: my guess is we're using the read-only store, and then you try to create the dsp but you can't, so somehow we need to force it to use the read-write store [17:17] ah, right [17:17] intellectronica, ok, I'll look closely here in just a sec. Trying to go over the latest bug about log() with adeuring. [17:18] intellectronica, I think we may have to adjust your branch a bit, too. Sorry to send more work you way again. [17:18] deryck: intellectronicagive me a second for a proposal of a better function [17:18] deryck: in what way? [17:19] intellectronica, in that the current branch will make anything 2/3 and up 4 flames. We want something more like: if max_heat is 100, use intervals 0..40, 41..70, 71..80, 91..100 [17:19] deryck: i don't think it will. see the documentation === beuno is now known as beuno-lunch [17:20] * deryck looks again [17:20] but as i said this is hardly my expertise. if you have a better transformation go for it [17:24] * deryck is playing with numbers in the doc test [17:31] intellectronica, I'm actually getting the numbers of how many bugs will get what flames right now. That might help us decide. [17:32] cool. nothing like real data :) [17:33] deryck, intellectronica: http://paste.ubuntu.com/ (no lint check ;) [17:33] adeuring: are you asking for input? ;) [17:34] intellectronica: well, that's a proposaal for other thresholds in calculate_heat_display() [17:34] adeuring: right, but you only gave the url to the pastebin, not to the pasted item [17:34] intellectronica: argh, I am idiot... http://paste.ubuntu.com/383823/ [17:36] another option are median statstics, BTW [17:36] adeuring: yes, that looks like a good way to do it [17:37] intellectronica: how/when do we calculate heat values (or max_heat for targets)? [17:37] if this is done by a script, we could set the threshold based on actual data to build thresholds that match the data. [17:38] adeuring: i'm creating a trigger that calculates it whenever a heat value is entered for a bug [17:38] so that we have the same number of bugs with 0, 1, 2,... flames [17:38] yes, that was the original idea, but i think for now it's too complicated [17:38] intellectronica: ah, no, running median statistics tehre is not a good idea, I think. [17:41] intellectronica: I suspect that the function can be simplified.... [17:41] let me see [17:44] adeuring, intellectronica -- I'm preparing real numbers with both approaches for what ubuntu and malone (extreme and average) would do in terms of bug distribution in these scales. [17:44] deryck: cool, I'm curious [17:52] deryck, adeuring: so i fixed the problem with getting max_heat from a dsp. you can now re-merge my branch [17:52] intellectronica: too late: EC2test is already running... [17:52] ...for my branch... [17:52] adeuring: well, it will fail [17:53] unless you fixed it independently [17:53] yours is already merged? [17:53] deryck: ftr, i did that by removing the bit that creates the record in the getter. thinking about it it really shouldn't have been there, since it potentially allows anonymous users to create new records [17:53] adeuring: no, that's the branch you presumably branched from. you notified me of errors and i fixed them. [17:54] intellectronica, ok. I'll look closer here in a minute. [17:55] intellectronica: yeah, but that's not what I got reviewed, and so deryck suggested I just go ahead with my branch. [17:55] deryck, adeuring: i have to go out for a few hours soon. if you need me to update the scaling, or whatever, drop me a line and i'll do that later in the evening when i'm back. sorry to have to leave you like that. [17:55] intellectronica, no worries. So far, your scaling is looking better. Though both have issues. Will email. [17:56] intellectronica: seems that I'm also getting tired. I think I can proposed a more efficient varaint than what is in the pastebin, but i need a bit more time ;) [17:56] adeuring: i'm not sure i understand. in my scale-heat branch there was one error that originated in my branch, and another error the originated in deryck's branch. i fixed both and pushed, and thought that if you branched from it you might want to re-merge. [17:57] intellectronica: no, I simply stared from a devel branch... [17:57] intellectronica, abel's branch is based on devel. He's just changing icons, no? [17:57] ...started... [17:57] deryck: well, no... [17:57] i changed also the HTML rendering [17:58] and the place where that happens changed [17:58] in intellectronica branch [17:58] ah, right. [17:58] adeuring: right, and i told you that you will have to look at my branch since the place where the rendering is done has changed in my branch [17:58] heh === salgado-lunch is now known as salgado [17:58] heh. [17:58] argh... I missed that.... [17:59] adeuring, can you just kill your run. and we can merge your branch into intellectronica's. Or vice versa. And one of you can fix conflicts. yes/no? Likey? :) [17:59] adeuring: well, if your branch lands in devel then i guess i'll just have to merge and resolve the conflict. no big deal [17:59] intellectronica: ok, thanks [17:59] yeah, that works. [17:59] intellectronica is waiting on me anyway :-) [18:00] i'm not. i'm going to a concert :) [18:01] heh [18:01] intellectronica, adeuring -- so enjoy the night. I'll send my numbers in email. We'll stick with Tom's scale now and re-evaluate later if need be. [18:01] we still end up with large numbers in 0 flames with both. [18:03]