[08:01:21] hi [08:02:20] Hi Nikerabbit [08:02:29] hi [08:02:35] Hey Krinkle [08:03:02] Hi [08:03:18] hello everybody [08:03:23] Hi iskren, santhosh, jzaefferer, scott_gonzalez, tj_vantoll1, siebrand [08:03:34] hi [08:03:50] Hi [08:03:55] I wish you all had a great time during Christmas and New Year (if you happen to follow this calendar :)) [08:04:10] Absolutely. Thanks. Hope you had the same [08:04:26] Thanks [08:04:36] thank you! [08:06:07] I guess I can start :) [08:06:17] I don't have much updates for Globalize. But, I'd like to hear what you guys have. [08:06:43] From last meeting, we talked about mediawiki needs... [08:07:14] iskren, sure. Feel free to start then ;) [08:07:28] rxaviers, well, you released the cldr-date wrapper, or this is old news [08:07:55] You missed our last meeting :p [08:08:45] But, yeah you are correct. We have landed the CLDR work in progress work on Globalize's master, including the date module. [08:09:04] Please, correct me if you are talking about something else. [08:09:20] no, you're right [08:10:30] I guess everyone here is familiar with iskren. But, for people that doesnt know. He is moment.js lead. [08:10:36] at moment, we made a release and integrated testing with sauce-labs -- they run your code in a browser in a chosen OS-browser combo [08:11:44] thanks, rxaviers :) github.com/ichernev [08:12:06] I might say that the next big thing on the radar for me is moment-cldr. Last thing we did with rxaviers is to ask a few questions in the cldr mailing list, which with some help from rxaviers we got answered [08:13:19] hmm [08:13:31] there is a doc describing moment-cldr's interface (https://code.stypi.com/vethklzp at the bottom), depending on how much of the hard work is implemented in globalize it would be easy-medium to do [08:14:06] I don't have many updates from our side, but can I propose something? [08:14:22] I need to pay some attention about packaging cldr for use of moment, and I guess that is it :) [08:14:41] Nikerabbit, sure -- go ahead [08:14:47] in the last meeting I mentioned something like "complete frontend i18n solution" [08:15:07] can we start a document where we list all the pieces such thing has and start fitting our projects into it [08:15:22] then we can see what is missing, overlapping and how to integrate them better if as needed [08:16:08] Nikerabbit, that makes sense. You a dev on wikimedia, or? [08:16:14] yes [08:16:35] Im looking forward to see moment-cldr, iskren :).. I'm confident that globalize could easy some of the pain. The date module is usable. I'll check what else we could leverage on globalize for moment.js. Also, please, just let me know any places you would lke to see in Globalize. [08:16:53] I, santhosh and siebrand are from wmf language engineering team [08:17:45] Nikerabbit, that's a great idea. We should have a big pic of it all. [08:18:51] btw, where did we keep notes from the December 17 meeting? [08:19:37] We are saving the meetings minutes here https://docs.google.com/document/d/1V8X33uphHUeUEhX8AYU4GZ4DrPPGxbbpuydqShDO-Gw/ [08:19:53] Thx [08:19:54] can someone suggest a place where we can collaboratively write this big pic document? [08:20:14] scott_gonzalez, any suggestion? ^ [08:20:41] Does a google document work for everyone? [08:20:58] Google docs work best for simultaneous editing. [08:21:13] GitHub wiki would be another option. [08:21:22] we are also used to etherpads, but they are not good for long term storage [08:21:47] but I'm fine with google doc, as we don't have any central place at the moment (to my knowledge) [08:21:59] are they deleted or sth? [08:22:12] iskren: nobody ever finds them after a while :) [08:22:17] I'm fine with google docs too [08:22:34] yeap, I'd vote for google doc for the same reason. (no central repo) [08:22:51] haha, but you send a link (as with google docs ... I don't know). I'm using only one for now, so it works for me :) [08:24:34] True, google docs works mostly with links as well. But Google Docs has a central portal where you can see things you've opened, been shared with, have access to, starred etc. Whereas etherpads you'd have to bookmark manually or otherwise keep track of. [08:24:53] Plus, auth model is more secure, naturally (at least by default Etherpad has none iirc) [08:25:19] I think we have reached consensus, now we need a volunteer to create and share it to us :) [08:25:30] Google docs it is then. If someone has anything to say, speak now. [08:25:42] I'll do that. [08:25:44] Just a seec. [08:25:50] Ok [08:26:07] siebrand, Nikerabbit, santhosh, I have sent an email to you guys, before I left on vacation. [08:26:09] Please pm me your gmail email address. [08:26:16] In the email, we have some of that big picture. [08:26:23] (so it's not in the logs) [08:26:24] That could be used as a baseline perhaps. [08:26:35] I'll make the doc open for commenting, only editing for us. [08:27:26] rxaviers: yes it has useful details [08:28:02] We're at https://docs.google.com/a/wikimedia.org/document/d/1zARV2WMowVU38MOOyYI120ceQ7KY6z-1lh_3kFIcLcc/edit [08:28:21] only Krinkle, santhosh , rxaviers , Nikerabbit and I have edit rights so far. [08:28:36] All rights holders can invite new rights holders, so feel free to. [08:28:44] thanks siebrand [08:28:53] we should add iskren [08:29:07] Im adding scott_gonzalez and jzaefferer [08:29:23] great. [08:29:32] Let me know if I have to play administrator somewhere. [08:30:41] Yay, we're drafting! [08:30:50] Draft on, little elves! [08:31:33] I still see 4 anonymous users in the doc. [08:31:44] If you got write access after you entered, please reload. [08:34:51] Only 1 anonymous left. [08:35:29] hm, I can not edit, but I'm not anonymous [08:36:00] logged in with iskren [dot] chernev [at] gmail [dot] com [08:37:32] iskren, please check now [08:43:05] We're writing along nicely now. Let's come back to the channel in 10 minutes, so we have 8 minutes to wrap up. [08:44:06] sure thing. The drafting is going fantastic. [08:44:44] rxaviers Krinkle santhosh Nikerabbit iskren scott_gonzalez : We're writing along nicely now. Let's come back to the channel in 8 minutes, so we have 8 minutes to wrap up. [08:47:10] Let's also start thinking about the next meeting. [08:47:33] Should we keep the next meeting further away? I think we've got a good amount of material to work on. [08:48:06] Larger gaps means longer projects and less (peer) pressure. [08:48:18] Let's not put checkin times further apart. [08:48:29] We have th next meeting planned in 2 weeks, same time, same place. [08:49:09] We do? [08:49:12] That's 08:00 PST for this in SF :) [08:49:19] I see it now indeed [08:49:20] Krinkle: yes, as far as I know, we do. [08:49:30] I didn't know we scheduled that already [08:50:26] Our next meeting is 2 weeks from today. I think it's a good gap. Does anyone want to reschedule it? [08:50:31] I think I'll reorg the doc in a chapter structure after the meeting. [08:50:38] That allows for easy TOC etc. [08:50:50] rxaviers: I'm fine with it as is. [08:50:57] Krinkle: does that time overlap with our architecture summit? [08:50:58] ok [08:51:09] about the reorg, sounds good for me. [08:51:10] Nikerabbit: It does [08:51:24] Nikerabbit: The day, not the time. [08:51:30] The official arch meeting starts right after [08:52:34] Krinkle: okay, so it might be okay [08:55:56] Im convinced this big-picture doc will help us to better place our needs and better cooperate. Good idea Nikerabbit [08:56:25] +1 [08:56:46] Hm.. irclogs.jquery.com down? [08:57:09] http://irc.jquery.com/%23jquery-meeting [08:57:10] Krinkle: irc.jquery.org [08:57:15] http://irclogs.jquery.com/#jquery-meeting/ [08:57:16] redirect [08:57:17] Doc reformatted. [08:57:24] http://irc.jquery.org/%23jquery-meeting/ [08:58:58] 2 minutes left in our timebox. [08:59:27] Next time I'd like to explore needs, dependencies and if we get to it, commitments. [08:59:33] Does that sounds feasible? [08:59:39] sounds = sound [09:00:19] +1 from me [09:00:51] rxaviers Krinkle santhosh Nikerabbit iskren scott_gonzalez : Meeting time over. Famous last words? [09:02:42] See you all in two weeks. [09:02:56] scott_gonzalez: Can you update channel topic? [09:03:21] Krinkle: yeah [09:04:30] Bye bye. [09:04:40] THakns, very promising :) [09:11:11] buy [09:11:11] bye*** [11:01:15] hi all [11:01:21] <_|Nix|_> Hey! [11:02:12] hi [11:03:25] gseguin agcolom [11:03:53] here [11:04:34] ok let's get started [11:04:56] link to meeting doc https://docs.google.com/spreadsheet/ccc?key=0AskujzE4Ig0QdG5nSmZiSUhjYm4ya29CdjhLZmJwSWc&usp=drive_web#gid=2 [11:05:28] Hi [11:05:56] _|Nix|_: I see you added some PR's to the agenda [11:06:13] _|Nix|_: what are the things we need to discuss? [11:06:30] <_|Nix|_> Only to report they're done. [11:06:44] <_|Nix|_> uGoMobi: Oh, so I'm only supposed to add them if we need to talk about them? [11:06:54] <_|Nix|_> OK, sorry. I guess I'll remove them then. [11:07:01] <_|Nix|_> We had an item from this morning. [11:07:09] <_|Nix|_> Re: Style option removal. [11:07:16] <_|Nix|_> But, I don't remember exactly what. [11:08:02] right, we were discussing removing style options with the web-ui-fw team [11:08:31] we used the button widget as example [11:08:50] but arschmitz is working on a new button widget for both UI and Mobile [11:09:27] yup [11:10:18] the question was if we should just document that data-wrapperclass is the way to add the style class to the generated wrapper [11:10:41] _|Nix|_: you had some concerns about when you use option enhanced [11:11:13] <_|Nix|_> Yeah. And actually, we already have these problems in 1.4.0. [11:11:27] because in 1.5 we will still support the current way (data- attributes) and option and style could get out of sync [11:11:29] <_|Nix|_> If you specify both data-wrapper-class and individual style options, they may contradict. [11:11:36] right [11:12:08] wrapper class has no logic and shouldnt [11:12:26] its no different if you go randomly doing add class on a widget [11:12:31] it can get out of sync [11:12:32] We should really go over all widgets with style options and create a document that describes the API changes before actually making changes [11:13:32] <_|Nix|_> arschmitz: Yes, it can, which is why we should document that you should pick exactly one method for manipulating style options and then stick to it. [11:14:13] _|Nix|_: yes for sure [11:14:17] <_|Nix|_> arschmitz: For example: suppose you set data-enhanced="true" and add ui-corner-all to the wrapper div, but you don't add ui-corner-all to the wrapper class. [11:14:50] thats fine [11:15:43] what will that break? wrapperClass only adds classes [11:16:07] <_|Nix|_> arschmitz: If you then .option( "wrapperClass", .option( "wrapperClass" ) + " ui-shadow" ), the corners will be removed. [11:16:07] <_|Nix|_> arschmitz: ... or rather .button( "option", "wrapperClass", .button( "option", "wrapperClass" ) + " ui-shadow" ), I mean. [11:16:16] it should never remove classes [11:17:12] which that sequence would just add ui-shadow [11:17:14] as it should have [11:17:25] <_|Nix|_> arschmitz: Well, if wrapperClass is a true option, you can change its value at runtime, so it must remove those classes added by the old value and add the classes contained in the new value. [11:17:41] because wrapperClass was previously null [11:17:50] and if you add them in your markup thats not the option [11:18:02] so yes if you add with wrapperclass it will remove it [11:18:22] but if you add any other way it should not care at all about them [11:19:43] <_|Nix|_> *sigh* ... we should seek to get rid of all these wrapperClass options ... Why not just add a .wrapper() method? [11:20:25] data-attributes [11:20:25] <_|Nix|_> After all, you don't have access to any of the (add|remove|toggle)Class methods, because those only work on .className, not an arbitrary string. [11:20:54] _|Nix|_: its to add the classes in your markup [11:21:12] <_|Nix|_> arschmitz: Right, of course. Still, it makes runtime class manipulation difficult. [11:21:18] yeah, makes sense to use data- attributes here [11:21:26] otherwise you can just do $("selector").button("widget").addClass("foo"); [11:21:36] <_|Nix|_> arschmitz: Of course! [11:21:39] <_|Nix|_> arschmitz: Duuuh! [11:21:49] <_|Nix|_> Then that's what we should document! [11:22:15] yeah even thought wrapperClass is an option that WILL work any time it shuld not really be used execpt from markup [11:22:19] <_|Nix|_> That's the replacement for all the runtime style-option-setting. [11:23:45] _|Nix|_: I suggest we go over all widgets with the web-ui-fw team and create a wiki page for notes [11:24:32] <_|Nix|_> uGoMobi: Not bad. [11:24:59] ok [11:25:36] <_|Nix|_> uGoMobi: We can use https://docs.google.com/document/d/1hZGlikXfhIEz9GUDJ1TLNHUVHaV-TlFC4zk_YgL3dUo/edit as the basis. [11:26:04] <_|Nix|_> OK. I guess that covers style options. [11:26:43] _|Nix|_: yes, or the overview that Hyunsook created and sent us by mail [11:26:52] <_|Nix|_> uGoMobi: Right. [11:27:04] <_|Nix|_> uGoMobi: We can expand on that. [11:27:18] gseguin: anything that needs to be discussed about dependencies? [11:27:34] uGoMobi: I think it's ready to land [11:27:37] gseguin: or is it just waiting to be reviewed [11:27:39] ok [11:27:53] I have another issue opened about relocating third-party code [11:28:05] but the bower thing can land before that [11:28:18] gseguin: last i checked there were still some formating issues i commented on that needed to be fixed [11:28:29] arschmitz: I fixed those [11:28:39] gseguin: ok ill look again [11:28:45] arschmitz: cool [11:29:07] otherwise there is this: https://www.google.com/url?q=https://github.com/jquery/jquery-mobile/tree/issue-6905&usd=2&usg=ALhdy2-FpLzbs-4yDrcpGy93zFfX3zQeZQ [11:29:12] sorry [11:29:12] gseguin: https://github.com/jquery/jquery-mobile/pull/6868/files#diff-35b4a816e0441e6a375cd925af50752cR780 [11:29:22] https://github.com/jquery/jquery-mobile/tree/issue-6905 [11:30:24] arschmitz: hmm weird, my forced push must have gotten lost when github was down yesterday [11:30:27] I'll push again [11:31:01] ok great [11:31:12] code coverage landed [11:31:23] yup that is AWESOME! [11:31:42] yes it is... nice work gseguin! [11:31:50] we have a score of 82% [11:31:54] <_|Nix|_> Yeah! Congrats! [11:32:05] thanks [11:32:17] in that branch: issue-6905 I'm trying to write real unit tests using Sinon to stub methods we're not actually testing [11:32:20] which mean 18% is not covered, the other 82% might be covered (at least the code ran) [11:32:37] I started writing a test for the button widget [11:33:14] gseguin: so that gives a more actual result? [11:33:20] and it looks like: https://github.com/jquery/jquery-mobile/blob/issue-6905/tests/unit/widgets/forms/button.spec.js [11:33:39] uGoMobi: the "unit" tests we have are not really unit tests [11:33:55] they are very useful but they are integration tests [11:34:16] more accurate result I meant BTW [11:34:19] gseguin: right [11:34:44] I would like to have real unit tests where a function is given an input and we check the output of it mocking everything surrounding its execution [11:35:02] I don't know if it's something that you guys are interested in [11:35:23] but I wrote a couple tests to show you what it would look like [11:35:36] gseguin: in theory yes as long as it does not require extensive code re-write [11:36:08] It will require some code massaging because in some of our modules some functions are not reachable [11:36:12] but not extensive [11:36:25] and it wouldn't be re-write [11:36:45] <_|Nix|_> gseguin: Well, one of our goals is to flatten out all widget functions. [11:37:01] it would be making these functions reachable and split some functions to smaller ones maybe [11:37:21] gseguin: gseguin you will find all the pageContainer tests are like this [11:37:32] however i dont like how the widget is written as a result [11:37:49] arschmitz: like what? [11:37:53] every method has to be passed all input nothing can be stored on the instance for use [11:38:08] also I'm interested in code climate which gives you a complexity rating on your code [11:38:36] gseguin: there was some discussion of this by dev leads already [11:39:01] arschmitz: what was the outcome? [11:39:16] we decided we didnt want to have a public badge with this that it can lead to the wrong impression of some code thats actually quite good [11:39:50] yeah absolutely I would display it only if it shows good numbers ;) [11:40:03] back to the unit tests [11:40:13] did you guys look at that test? [11:40:29] gseguin: i have not looked at this one yet [11:40:30] is it something you think is worth investing time in? [11:40:45] yeah, it's important that results are interpreted correctly [11:41:49] gseguin: my concern mostly comes with widgets and not having to change the fundamental way they are written [11:41:55] <_|Nix|_> gseguin: TBH I'm not sure. [11:41:55] <_|Nix|_> gseguin: I don't like the idea that we test at such a low level, because it removes the intention of the test. [11:42:24] <_|Nix|_> gseguin: I like it when tests ensure expected behaviour irrespective of how that's achieved. [11:42:40] _|Nix|_: I'm not talking about getting rid of the other tests [11:42:46] <_|Nix|_> gseguin: Oh, I see. [11:42:55] _|Nix|_: oh yeah no no no [11:43:08] _|Nix|_: Just introduce real unit tests that run super fast [11:43:26] so we can use a watcher like karma for instance [11:43:26] gseguin: maybe we could discuss this more in -dev and look at how much and what sort fo re-write will be required [11:43:40] +1 [11:43:43] <_|Nix|_> OK. [11:43:43] and to have TravisCI give feedback on a PR quickly [11:44:01] arschmitz: ok [11:44:11] gseguin: i like the idea though [11:45:01] ok last thing was I want to make TravisCI execute our current unit and integration tests independently [11:45:09] so we get feedback faster [11:45:10] ok, let's continue this on -dev and discuss with UI as well [11:45:46] gseguin: do you mean they will run in sync? [11:45:51] <_|Nix|_> gseguin: I'm all in favour of parallelizing, if one suite does not end up affecting another because of increased load. [11:45:54] they should indeed [11:46:18] gseguin: how will this effect github status [11:46:26] the same way the different jQuery versions are running in parallel [11:46:56] arschmitz: is the PR status updated as soon as there is a failing test ? [11:47:12] no i think its once it completes [11:47:17] darn [11:47:27] yeah I think they stay yellow until finished [11:47:36] well we can hope for some time saving anyway if we parallelize the tests [11:47:47] gseguin: id actually like to see 3 sets [11:47:56] it'll just depend on how many parallel executions we're allowed [11:48:04] 3 sets? [11:48:07] unit, integration, and navigation [11:48:20] hmm ok [11:48:35] the nav ones take all the time [11:48:38] yeah navigation takes long [11:48:38] so a combination of types and suites [11:48:49] I think I can work on that [11:49:00] yeah we should split out nav into its own folder [11:49:09] like we have unit and integration right now [11:49:15] let's mention this on -dev as well [11:49:31] I need to add some kind of pattern handling for --suites [11:49:36] maybe someone knows a reason why we should not do this [11:49:39] where you can pass !navigation [11:49:47] gseguin: +1 [11:50:16] i think we could gain a lot by going through our current tests and doing some cleanup too [11:50:51] <_|Nix|_> gseguin: Neah, I don't think we're there yet. We only have 3 instead of two. It's not like you're typing a long list because there's no inversion operator. [11:50:51] <_|Nix|_> Agreed - I think we have some duplication even. [11:51:31] maybe ill spend some time on this when i take out the dialog tests [11:51:36] <_|Nix|_> ... and then there are tests that do the same thing as a previous test, but perform an additional step. [11:52:04] <_|Nix|_> Some tests are really bad: Go to some internal page, then do this one thing, then come back. [11:52:16] <_|Nix|_> We /really/ don't need to do navigation during tests. [11:52:41] _|Nix|_: agreed [11:52:54] unless its a navigation test of course lol [11:53:15] <_|Nix|_> :) [11:53:50] ok I added one more item to the agenda [11:54:08] the examples in the API docs that use iframes [11:54:26] I'm happy to take care of that [11:54:27] we should get rid of the iframes as much as possible [11:54:36] agcolom: awesome [11:54:52] agcolom: let's open a ticket for this [11:54:54] some things will still need them [11:54:59] but most of the widgets wont [11:55:02] yes [11:55:14] only widget that can be used standalone [11:55:28] ok, so would be good to list them so I know (in the issue tracker) [11:55:54] agcolom: sure [11:56:10] Hasn't scott opened an issue already? [11:56:10] the info is in the 1.4 changelog as well BTW [11:56:26] agcolom: could be, didn't check [11:56:51] I'll check [11:56:58] ok thanks [11:57:20] anything else we need to discuss? [11:57:26] just to let you know that I fixed some inconsistencies in jsbin (jQuery entries now are all from our CDN, and have all releases and WIP via git. https://github.com/remy/jsbin/commit/344bc18f358a48a0434356ea9926e0a01eac9e3f [11:57:49] agcolom: great [11:57:50] agcolom: awesome! thank you! [11:58:07] np :-) [11:58:17] ok have to have dinner now... [11:58:22] agcolom: awesome id been meaning to submit them a pr for mobile forever [11:58:38] ok thanks all [11:58:47] <_|Nix|_> agcolom: Bon appétit! [11:59:01] <_|Nix|_> L8R [11:59:04] agcolom: Thanks for that and enjoy! [11:59:51] Later!