[13:26] bac benji danilos, I'll look at kanban in a sec, & call in 4 [13:28] who's doing "identical displays of subscriptions" in FW 1: active? [13:29] * gary_poster guesses danilos [13:29] gary_poster, that's right, sorry [13:29] np :-) [13:31] bac and benji are you rejecting my Skype calls? :-) [13:37] gary_poster: should I put this branch on ~yellow to make it easier for us to collaborate? [13:37] benji, do you think your branch is in a state that it could be merged, and then we could land separate things on top of it? [13:38] (In general, I'd prefer to do that, and feature flags let us) [13:38] at the moment it puts placeholder text in the spots, but I think if I changed that it would be sane; or we could accept it as-is if we're cool with it because it's behind a feature-flag [13:39] Yeah, I think the only constraint should be that what you have that is supposed to be working is tested before it is merged [13:39] yep, it's fully tested [13:39] (I don't thin we need tests for the placeholder text, for instance :-) ) [13:40] awesome [13:40] I'm in favor of landing as is [13:40] heh, no the tests don't depend on the text [13:40] k, I'll do that [13:40] and then the plan is that you guys will work from devel? [13:41] cool :-) (and even moving a separate card along the kanban board for "direct action pattern" (or "infrastrcture" or something like that) [13:41] sounds good [13:41] since landing will take a while I'd work from your branch [13:41] But then I'd get it reviewed with your branch as a dependency if it is not in devel yet [13:41] actually, I should probably mutate my current card to that one and then add a new one for the mute action that I'm adding [13:42] k [13:42] Yes, that does make sense === Ursinha-afk is now known as Ursinha [13:53] gary_poster: did you try to install natty? [14:10] bac, no. problems? [14:10] gary_poster: it installed fine under vmware but no unity [14:10] as vmware doesn't have the required 3d drivers yet [14:11] yeah, that's what I expected, bac [14:11] so it is a bit of a wash [14:11] might work in parallels [14:11] yeah [14:11] I'm still using server version [14:11] i've read it may work in virtualbox...but i'm dubious [14:11] I readthat too [14:11] deryck said he might go back to dual boot [14:11] i meant to try on metal but the weekend slipped by and i didn't want to risk it [14:12] yeah [14:13] benji, lp:~benji/launchpad/direct-personal-subscription-actions-scaffolding right? [14:13] * danilos -> lunch [14:13] gary_poster: yep [14:13] cool [14:19] gary_poster: should there be a new feature flag for the scaffolding? [14:19] benji, no, we feature flag the link to this page [14:19] I think that's good enough [14:19] the page was already "broken" [14:19] in the sense that it didn't make sense [14:19] yep, I agree; I just wanted to make sure it wasn't turned on in production; thanks [14:20] cool, np [14:25] benji, do you have a plan for what to do after a change has been made that requires another functionality to be available? [14:25] i.e. [14:25] I go to the page and mute [14:25] this is done via ajax [14:25] now I need to be able to unmute [14:25] "no" is fine, but we should talk through it if so [14:26] I've given it a little thought, since the current functionality works off of the cached values and those should be updated by AJAX calls, we can just re-run the code to generate the description and the IDs of the subscription controls that should be visible [14:27] so, like, collapse, redraw, expand? [14:28] I guess the nice thing is that we only have to do that for the direct/personal stuff [14:28] we can leave the "other" bits to handle themselves [14:28] right [14:29] ok that sounds doable. Thanks [14:31] benji, sorry another question. You had worked on code that tried to hook up the current subscribe-with-notification-level stuff before I asked you to move to the scaffolding. What's the status of that work? What's your opinion on reuse? Does this warrant a call? [14:33] gary_poster: status: not in good shape, prognosis: decent, reccomendation: it shouldn't be too hard to refactor the current code until what we want is easy [14:35] ok thanks benji. not really looking forward to that :-P but that should be done. I guess I'll try that (so, "subscribe_action" and "change_subscription_action" and, unfortunately, "unmute_action" are all tied into this). Any pointers on where to get started? I have not looked at this code at all. [14:36] gary_poster: after I prepare to review the branch I'll look at it and see what memories it jogs [14:36] ok thanks [14:44] gary_poster: I think the state of my hacking branch tells the story of what I know at this point: http://pastebin.ubuntu.com/595519/ [14:44] if not, feel free to ask me to make up for its story telling deficiencies [14:45] benji, .log('cool, thanks, that looks helpful') [14:45] :) [14:46] gary_poster: that code currently dies wanting to find a spinner, but I think it's close to working [14:46] cool [16:03] gary_poster: you know what this warning means? http://paste.ubuntu.com/595547/ [16:05] bac, I understand some of the elements (for instance, I'd have an idea on what to do to find the unhelpfully described "milestone-edit.pt.validate_widgets") but not the main point, no. :-/ [16:05] gary_poster: ok. i didn't introduce it but i was curious [16:05] cool [16:05] gary_poster: putting my milestone branch up for review now [16:06] great! [16:06] * gary_poster is staring at largely untested JS with concern and potential dithering [16:09] The bug unmute story really is unpleasantly confusing [16:23] benji, this code we are trying to reuse makes me sad :-( [16:23] * gary_poster goes to go have lunch [16:23] :-D [16:23] heh [17:42] gary_poster, the big branch is landing, I've still got https://code.launchpad.net/~danilo/launchpad/duplicate-pillars-subscriptions/+merge/58135 up for review [17:42] danilos, great. You need me to shepherd that one through, so you can head out? [17:44] gary_poster, yeah, please :) [17:44] danilos, I think I'll claim it so I can be sure to actually feel productive about something today :-P [17:44] good luck on the test [17:44] talk to you Thursday [17:49] danilos, approved with no changes; going to try and land [17:51] gary_poster, cheers [17:51] gary_poster, there was a conflict, merged, and lint is happy now :) [17:51] heh, ok thanks [18:39] gary_poster: i'm free to help now. where should i start? [18:39] bac, /me looks, one sec [18:42] bac, unless benji has another suggestion, I suggest you branch lp:~benji/launchpad/direct-personal-subscription-actions-scaffolding (which he will land separately, so this will be a dependency of your branch), merge in devel, and then look in lib/lp/bugs/javascript/subscripton.js. [18:42] I suggest you work on real implementations for unsubscribe_action and unsubscribe_with_warning_action . [18:42] benji, agree/disagree/suggest? [18:42] * bac branches [18:42] * benji has abort/retry/fail flashbacks. [18:42] agree [18:42] bac, tests are in lib/lp/bugs/javascript/tests/test_subscription.js [18:42] great [18:43] :-) thanks benji [18:43] benji: will you be able to look at my branch soonish? it's ever so tiny [18:44] bac: sure, if it's small I'll do it now [18:44] 64 lines of diff, i think [18:45] benji, if we are reusing the existing stuff, and I'm trying hard to continue to make myself do so, then mute is tied in with unmute, which is tied in with subscribe. But nevermind...I'll try to ignore. :-) [18:46] Or divide them up in that portlet code [18:47] gary_poster: yeah, it's a bit of a tangle, I was going to apply the old saw of refactoring until what you want to do is easy [18:48] bac: done [18:48] gracias [18:51] el gusto es mío [18:51] heh [18:52] my lack of spanish but knowledge of cognates translated that as "the taste is mine" [18:52] But I suspected that "pleasure" was a better translation than "taste" [18:54] right; I like "it's my plesure" better than "it's nothing" but that's probably my english-centric brain misapplying idioms [18:55] I would really like to learn more Spanish; taking German in HS/college was such a bad choice. [18:55] :-) [19:26] and I'm back (total machine freeze) [19:26] meh [19:26] benji, fwiw, I've looked at what the current susbscription stuff does, and what we need, and I've decided to not reuse. They are too dissimilar IMO. I've made a list of what we want for the three scenarios that I have claimed [19:27] I'm not sure how it will work with what we have exactly, but I'm just going to run with it so I can make some progress. I have a goal, at leats [19:27] least [19:28] cool, at least we tried [19:28] yeah [19:28] you did fix a bug in your branch though [19:28] I don't want to lose that [19:52] bac are you at UDS Mon and Tues? [19:52] yes [19:53] gary_poster: you have a mission for me? [19:53] bac, Brian Murray wants us to present our work there. He actually wants to help present. Would you be willing to work with him on that? [19:54] gary_poster: sure! [19:54] awesome [19:54] thank you [19:54] np [19:54] I'll email folks [19:54] i find it easier to have a structured thing to do than just mill about trying to engage people in discussions about launchpad registry [19:55] heh, I can understand that [19:55] so, jorge, any thoughts on the team participation table? [19:55] :-) [19:56] bac, do you know bdmurray already? [19:56] yep [19:56] cool [20:13] gary_poster: in your email you mention me being head down for this week and the next two. as a reminder, i leave for budapest on tuesday may 3rd [20:13] bac, lol [20:14] ? [20:14] bac, laughing at myself, sorry. feel free to correct. If you are not head down for the third week, but just for this and next, I think that will work out fine for us. Is that OK, do you think? [20:15] yes, i just didn't want you to be surprised [20:15] cool, thank you [20:17] benji, I'm changing some of the framework. basics are still there but [20:17] (1) I'm adding a separate box for actions that increase email quantity, and dividing up the actions into the two kinds (and only showing each box when appropriate); [20:17] (2) I'm adding some actions to separate out some of the actions I claimed into individual nodes (some of which will go into the two boxes); [20:17] and (3) I'm changing the action functions to use the action_ids mapping (and making those values not have the # prefix). [20:17] I'll make that as a separate branch [20:17] or at least that's my intent now [20:17] does that sound ok? [20:18] note that we can tweak this; it's just a step in the right direction, or at least a direction that I can see now [20:21] gary_poster: that sounds fine; I'm especially curious to see the results of dropping the #s [20:22] benji, cool thanks. dropping the #s just means I can use the "constant" strings when I construct the nodes; I'll have to add the # back when I use the string as a selector of course [20:23] I suspect I'll dislike that, but I dislike lots of things and still manage to forge ahead :P [20:23] heh [20:23] I'm just reusing your action_ids [20:23] but ok [20:23] * benji tries not to turn into Fred Drake. [20:23] :-) [20:23] what is his stance on this? [20:24] grumpy [20:24] lol [20:24] I see [20:27] benji, I think we should assemble some JS differences of opinion and present them to bac for discussion, perhaps at Thunderdome or wherever he thinks is appropriate. I think string constant identifiers are very good for certain cases, and this fits into those certain cases though I have not taken the time to identify why yet. [20:27] Similarly, I disagree with danilos about not reusing var, and about his stance on not reusing values returned from appendChild. Settling down on some standards probably would save time and annoyance in the long run. [20:27] anyway... [20:29] gary_poster: are you suggesting that b/c i led such scintillating and productive sessions in dallas? [20:29] :), btw [20:29] bac, heh, yes...and you are the head of the reviewers, yes? :-) [20:30] of course those two hours of pain in dallas have spared us the weekly meeting, so i guess it was a good trade off [20:30] yeah, I think so [20:30] it's worth a shot; we have a lot to reconcile I think between: our stated desire not to nitpick in reviews, our still quite large python style guide, and our lack of a JS style guide [20:31] yeah :-/ [20:31] If we don't have an LP agreement, I think we need a squad one [20:31] benji: and our lack of common expertise in JS [20:31] yeah [20:32] bac: yep; you know I wonder if there isn't something like "The Seven Stages of Code Review" [20:32] ...we need a squad one just so that we can know when to squelch the desire to refactor, or indulge in it [20:32] heh [20:32] refactor/reformat/... [20:33] gary_poster: was danilos against chaining in general or just with appendChild, or did i misread? [20:34] bac, I don't know if he took his opinion beyond appendChild. Even just within the world of appendChild, chaining is pretty idiomatic afaict [20:34] unfortunately we'd still have to decide on what format to adopt; do whatever you feel like doesn't seem like an equilibrium [20:34] the way we're doing it is pretty jarring to see the first time (multi-line chaining) but is quite readable [20:34] agreed [20:34] heh, to both [20:35] that is, agreed to both [20:36] yeah, I'm pretty sure the multi-line chaining is a win; personally I've been experimenting with puttint nothing more than '' in the Y.Node.create() call and doing everything with methods from there. It seems easier to read and reason about thus far. [20:36] I noticed that and liked it [20:36] I wondered if all browsers support it [20:36] IE 7/8 for instance...to the degree that we care [20:37] Obviously I didn't, much :-P [20:37] I'm pretty sure that pattern is supported on all of YUI's "grade A" browsers. [20:37] Francis says we support Firefox, because that's what we have automated tests for [20:37] period [20:37] everything else is convenience [20:37] all Grade A: great [20:45] benji, another one. :-) Why do you prfer [20:45] var i; [20:45] for (i=0; i direct_node.one(direct_info.increases[i]).removeClass('hidden'); [20:45] } [20:46] over [20:46] for (var i=0; i direct_node.one(direct_info.increases[i]).removeClass('hidden'); [20:46] } [20:46] (that is, why do you not like the var in the for statement? [20:46] ) [20:46] primarily because jslint complains about the first, secondly because it has a point [20:46] you mean complains about the second? [20:47] the point is that in JS the "var" acts in the local scope, not where the var is placed, it's like "global" in python; you should therefore put them in the place that makes their effect as obvious as possible when reading the text [20:47] right [20:47] ah [20:48] so the second has the effect of the first [20:48] right [20:48] so therefore write the first? [20:48] gotcha [20:48] I can buy that [20:48] thank you [20:49] granted, it's a subtle point and if jslint didn't complain, I might come down on the other side, but since it does it's worth going with the flow [20:49] yeah, I'm very happy with "follow what the lint says to do" as a general rule, myself [20:50] Though I must admit I didn't care for the optional lint bits he introduces as "the good parts" [20:50] my rule is "follow what the lint says to do but figure out why it says what it says so you don't feel like a robot" [20:51] don't remember details [20:51] yeah sounds good [20:51] I haven't payed mutch attention to the good parts; we might have to read his book to figure out why he feels the way he does. [20:51] yeah [20:51] I've read some about the on the net [20:51] them [21:39] benji, is it possible that the entire JS test suite wasn't passing in your branch? I think I might be fixing things in the underlying branch now. Small stuff, but things that we might all hit. I could be wrong though. If you are not sure I'll give it a whirl after I'm done [21:39] I mean, is it possible that some of thes tests were failing [21:39] even though your new suite was passing [21:39] argh, new case I mean [21:40] it's possible; I don't recall running the whole thing, so I wouldn't be suprised (and I'm a bad person) [21:40] heh, I should have run it before I started [21:40] I did run all of the ones in the file I added a case too though (because I don't know how to run just one) [21:40] that's what I meant [21:40] it seemed like some of them might be failing before I came along [21:40] but anyway [21:41] I'd be really surprised if that were the case. [21:41] if that's the case, we can just land my branch of yours [21:41] ok [21:41] is your branch already reviewed and such [21:43] Maybe I removed the one line [21:43] no worries [22:12] benji, do you mind if I target my MP specifically to you? [22:12] since it is tweaking your initial infrastructure [22:17] ooh, you freshened... [22:20] benji, it lookslike your merge might have done something bad in structural-subscriptions.js [22:21] In some places, it uses namespace._add_subscription_overlay (as is current in trunk I think) and in someplaces it uses add_subscription_overlay [22:22] and clean_up is in the wrong place [22:26] benji, https://code.launchpad.net/~gary/launchpad/direct-personal-subscription-actions/+merge/58197 fwiw [22:26] night all === Ursinha is now known as Ursinha-afk