[00:27:30] robla: Hi. [00:32:55] *Ashlee hugs guillom. [00:33:11] *guillom hugs. [00:33:52] Ashlee, because of you, now I actually have to hurry and finish the blog page on meta :P [00:34:24] but I'm pretty sure Jay agrees with us, so David Gerard won't be a problem, I expect :) [00:36:15] I replied to David. [00:39:09] *guillom opens meta. [00:39:14] howdy [00:40:43] robla: You linked "wmf:General Engineering Team" a bit, but that page doesn't exist. [00:40:54] Is "General Engineering" a proper noun? [00:41:18] *robla did? [00:42:54] I think so? [00:43:00] Ashlee: that was zakg who did [00:43:01] Oh, no. [00:43:05] Bah. [00:43:15] Sorry. [00:43:43] Ah, but you created http://www.mediawiki.org/w/index.php?title=Meetings/General_Engineering/2010-09-14&action=history [00:44:12] so....on the topic of "General Engineering" [00:45:03] Ashlee: "General Engineering Team" is what's used in http://wikimediafoundation.org/wiki/2010-2011_Annual_Plan_Questions_and_Answers (Also, convention on wmf: seems to be using title case for page names.) [00:45:23] zakg: I've been working hard to break that convention. ;-) [00:45:29] Unless it's a job title. [00:45:54] ... as the page doesn't exist yet, now's the time to fix it :) [00:46:19] Well, is "General Engineering" a proper noun? [00:46:29] Ashlee: yup [00:46:33] Okay. [00:46:39] Then it's fine where it is, I guess. [00:46:43] Though appending "Team" is a bit funky. [00:46:48] It is a unique thing [00:47:17] Ashlee: That's what it is called. [00:47:30] we've got a Feature Engineering team that we often just refer to as the Feature team [00:47:45] however, that shorthand doesn't work as well for General Engineering [00:47:47] I thought that was "Features." [00:47:55] that too [00:47:59] Because WMF is hopefully focusing on more than one... ;-) [00:48:13] Okay. [00:48:14] baby steps ;-) [00:48:19] a car factory presumably makes multiple cars [00:48:45] Sure, but factory is a group noun. [00:48:48] Or something. [00:49:04] a copy machine presumably makes multiple copies [00:49:27] You can't have half a hippo. [00:50:29] So there's Features Engineering, General Engineering, and... [00:50:35] Are there other teams? [00:54:04] Ashlee: I'm not in the know yet. http://wikimediafoundation.org/wiki/2010-2011_Annual_Plan_Questions_and_Answers has some info on teams. [00:54:33] I haven't worked through the annual plan yet, so I'm not entirely sure what it details. [00:54:48] Okay. [01:26:44] Ashlee: the engineering teams: "General Engineering", "Feature Engineering", "Operations", and "Mobile/Fundraising" (I'm not sure I've got the title right on the last one...it's basically "stuff that Tomasz manages") [12:44:13] is the centralnotice stuff enabled somewhere atm ? [12:44:23] i wanna check if all gadgets and stuff are compatible. [12:46:55] thedj, test? [12:47:20] (i mean test wiki) [12:48:10] ah. good. [13:02:33] thedj: meta too [17:02:27] RoanKattouw: hi [17:02:32] whatcha workin on? [17:02:33] Hi [17:02:38] Replying to your wikitech post [17:02:42] k [17:02:43] cool [17:02:53] where are you at on this? [17:02:59] I'm almost done [17:03:11] I mostly agree with you, but am pointing out a factual error now [17:03:19] fair play [17:03:56] i feel like people are not reading my writing when I explain why line numbers are irrelevant in production mode no matter how much whitespace is preserved [17:04:39] WHY WON'T VIEW SOURCE SOLVE MY PROBELMS!? [17:05:29] he he [17:05:58] i dropped my droid yesterday [17:06:06] I now have my 3rd droid incredible [17:06:08] since may [17:08:55] thank goodness for insurance [17:09:14] I'm getting my $8 a month worth thats for sure [17:09:29] RoanKattouw: we have a meeting nowish yes? [17:09:39] trevor keeps drinking my orange juice. [17:09:56] Yes [17:09:58] jorm: keeps claiming ownership on what is clearly community orange juice [17:10:14] *TrevorParscal enjoys jorm's o.j. [17:10:51] i keep trying to convince tara that someone should have "keep me supplied with orange juice" as one of their job duties. [17:11:38] Yes please [17:11:42] And milk, too [17:12:36] RoanKattouw: do you have that presentation in a more editable format? [17:12:45] Ryan_Lane: I'll share it on Google Docs [17:12:51] thanks [17:12:53] But please clone it before editing :) [17:13:07] will do [17:14:53] Done [17:16:38] thanks [17:16:55] RoanKattouw: you are wrong... sorry [17:17:09] ? [17:17:28] user prefs can affect more than just user.options module [17:17:49] If that's the case, it needs to be fixed [17:17:59] they can affect the vector.* and wikieditor.* modules too, as well as other extensions which do similar pref checking [17:18:13] Only at runtime though, right? [17:18:21] They won't actually serve different code [17:18:42] They'll serve code that might take a different branch based on prefs [17:19:02] Which does not affect the meaningfulness of line numbers. It does affect debugging, but not in that way [17:19:45] Also, I promised Jeroen I'd talk to you about something [17:20:17] but if user A reports that a bug on line number X occured, depending on their prefs, that number may mean something completely different than for the developer trying to reproduce [17:20:37] we don't send code that won't be used [17:20:57] If we send different code, that's because we use a different URL [17:21:11] we used to send code that may or may not be used, and decide on the fly whether to use it or not, now we just send what the user will actually want [17:21:13] The key question here is whether one URL will serve different code for you than it does for me [17:21:33] but the point was about users reporting bugs [17:21:38] and line numbers being useful [17:21:58] and my point is that there are lots of other reasons why they are not reliable [17:21:59] If they load a different set of modules, they'll have different line numbers [17:22:09] That part is true [17:22:10] yup [17:22:30] But taking a line number from one thing and using it to index in another thing is jjust plain wrong, no matter how you disguise it [17:22:48] If I got an error at SpecialFoo.php line 123 and looked at SpecialBar.php line 123, everyone would laugh at me [17:22:57] This is hardly any different [17:23:41] However, conveniently, most browsers will report the source URL along with the line number [17:24:11] ok, I see what you are getting at [17:24:16] By itself, a line number is always useless because you wouldn't know which script it indexes into [17:24:31] the only modules which mysteriously respond uniquely based on user is the user.* modules [17:24:33] If you do know, you'll know the full URL and can get a copy of that script exactly the way the user sees it [17:24:37] Exactly [17:25:31] (Are you convinced now? Can we move to this other topic I prepared? :D ) [17:26:29] yes [17:27:25] OK so [17:27:39] I promised Jeroen to raise this issue with you [17:27:49] Basically one of his maps extensions loads a bunch of static JS, then adds an inline script along the lines of , i.e. about a dozen PHP-generated params [17:28:16] Presumably what he's doing is have a (static JS) function for generating a map, then repeatedly calling it with the data needed to generate each map [17:28:47] ok [17:28:52] So [17:28:58] He wants to convert his ext to RL [17:29:08] But he can't figure out how to add this inline JS [17:29:16] Normally this would just be $wgOut->addScript() [17:29:26] Which is not nice, but works [17:29:57] However, he has the additional problem of having to do this on parse, hence having only a ParserOutput to work with; the only options there are addModule() and addHeadItem() [17:30:02] Where the latter really means what it sayas [17:30:27] So with ParserOutput the way it's currently written, he can't add inline JS to the right place (i.e. bottom of the page) and have it stick in cache properly [17:31:02] what he is doing is scary, and can be done much better using a different approach. What he should do is output html with the information about the map to be rendered encoded as attributes (this is also a good time to render the non-js version [17:31:05] So the question is, what should we do? Should we support inline JS like that in PO or should we come up with some way that he (and people in general) can avoid using inline JS? [17:31:18] then have a plugin that looks for those kinds of HTML blocks and converts them to fancy maps [17:31:20] I was thinking along those lines a little bit [17:31:33] But it doesn't allow embedding or arbitrary data in a trivial way [17:31:36] inline js is evil [17:31:40] I know [17:31:50] That's why I was looking for a way without using inline JS [17:31:55] s/without/around/ [17:32:16] he can also extend ResourceLoaderModule, and make a module that simply includes a JSON blob with the data [17:32:23] That was my other thought [17:32:24] or an API call [17:32:27] etc... [17:32:31] However, he'd have to pass that data somehow [17:32:34] Yeah API would be best [17:32:48] inline JS is how people do it when they aren't thinking clearly [17:33:15] Either way his attitude towards this seems to be "just make inline JS work and I'll be happy" and he didn't seem very receptive to my assertion that he should be open-minded to the possibility that some other approach might be better [17:33:33] I will admit I've done it before, there's proof of it in the SVN - given this durring was pre-jquery age - but it's simply not needed [17:33:47] I can talk to him [17:34:01] Thanks [17:34:03] you need to not be bogged down with helping him see the light [17:34:11] have him email me or find me on IRC [17:34:12] Note that your suggestions all require the data to be stored somewhere [17:34:28] Whereas the current approach can just pull it out of the parsed wikitext and not have to store it anywhere [17:35:24] if you can render into the page, you can render

[17:35:46] if he insists on embedding the information, that's still possible [17:35:56] haha [17:36:00] OK that's just evil [17:36:02] just dont munge logic and data like that [17:36:03] But it'll work [17:36:11] Exaclth [17:36:13] OK, moving on [17:36:16] it's not really that evil - but yeah.. ok [17:36:19] moving on [17:36:21] You wanted us to do an arch review [17:36:25] yup [17:36:26] And I have until ~1115 [17:36:30] k [17:37:05] basically, I feel like I want to assess things based on today's version of reality [17:38:08] heh [17:39:23] ResourceLoaderContext now contains a reference to a ResourceLoader object, because part of the context is which modules are avilable [17:40:02] I haven't seen any of those revs yet so lemme pull up the files [17:40:03] this is working fine, but I wanted to look at it again, because it also seemed like an act of history more than design [17:40:19] maybe we need to get you caught up on revs first [17:41:00] I can just look at the code [17:41:08] And you can walk me through the important chnages [17:41:56] OK you know what maybe I need to SVN up first :) [17:42:41] that might help [17:42:42] OK so [17:42:52] A ResourceLoaderContext has a reference to its ResourceLoader [17:42:55] Where is this used? [17:43:34] in places like MsgBlobStor [17:43:51] Hi. Sorry to interrupt. Were should I apply to a meta tag for pl.wiki? [17:44:06] ^add a... [17:44:20] What you do mean add a meta tag? [17:44:29] TrevorParscal: Oh was that for fixing that one fatal? [17:44:34] For IE comptaibility [17:44:55] File it as a bug in Bugzilla [17:44:56] you mean the X-UA [17:45:14] If it's for IE compat it should probably be done for all wikis [17:45:24] Or not be done at all if we decide it's not the right thing to do [17:45:36] Dispenser: Yes. Our main page looks bad in compat mode [17:45:39] RoanKattouw: its being used in the startup module [17:46:14] I don't see the word 'context' in MBS at all [17:47:35] Ah yes there we go [17:47:38] I also noticed the getGroup() thing [17:47:40] yeah, I don't think it is being used in mbs [17:48:10] Which you seem to be using as an elegant way to separate the startup module and jq|mw from the rest while also allowing for Michael's JUI separation hobby horse all at the same time [17:50:07] OK anything else of note? [17:51:27] TrevorParscal? [17:55:53] sorry, was talking to neil [17:56:24] basically I need you to review lots of my code [17:56:31] I'm going to be writing unit tests today [17:56:38] OK [17:56:39] (more unit tests, there are some now) [17:56:47] but we need to get you caught up [17:56:48] I will try to do what I can today, but count on that meaning zero [17:56:57] I will do my best tomorrow and over the weekend [17:57:06] that means we need you to make it a priority [17:57:13] Yes [17:57:20] Catching up on review is my #1 prio right now [17:57:43] But apart from the next 15 mins or so I won't have time to work until about 4:15am PDT tomorrow [17:58:00] Hm actually thinking about it that should hopefully be enough time [17:58:10] To get caught up before you get to the office [17:58:36] cool [17:58:59] TrevorParscal: If you want a few evil test for the loader they are in bug 25362 (in loader_test.js) [17:59:08] ^test [17:59:25] ^tests [17:59:31] ups :-) [18:00:13] EcceNux: what are you talking about, sorry.... I'm confused [18:01:24] I thought you were talking about tests for the Resource Loader [18:01:29] You seem to be pettitioning for sending more data to hundreds of millions of people than they need, just so you don't have to add debug=true to the url [18:01:47] I'm talking about PHPUnit tests for the PHP code of ResourceLoader [18:05:38] Oh, sorry I'm off then. [18:56:13] hmm. why are ip and netmask in the geo location tool ? [22:28:45] I'm going to be moving /srv on prototype to a new disk really soon. if you are using it, be prepared.