[00:46] <gary_poster> You are right, that is from mochikit.  The merge we want is on the Y object.  You can see it in the console with YUI().merge({foo:4, bar:5}, {bar:7,bing:8})
[00:46] <gary_poster> night for real :-)
[12:31] <gary_poster> benji, hi.  "save" nominally works, now even more than it did last night.  Specifically, the save button is hooked up, it saves to the server, and changes to the name and filter are reflected dynamically after a save.
[12:31] <gary_poster> As Danilo mentioned, there are a number of other related issues, and I'm wondering how many of them I should claim as part of this particular effort/"branch".  Here's a list off the top of my head.
[12:32] <gary_poster> * state is not loaded properly, especially for the radio button/checkbox divided thing (that is, if your notification level is "everything but comments")
[12:33] <gary_poster> * patching fails if you try to use the accordion widget (form_data.importances is undefined)
[12:34] <gary_poster> * the panel is not reset entirely across usages
[12:34] <gary_poster> (no details available in my head for that one, just a vague memory of encountering the problem)
[12:35] <gary_poster> I think there are some other ones, but that's what comes to mind now
[12:36] <gary_poster> do you have a preference as to whether I land as is, and then try to fix some of those; or you tackle some of those (maybe they are in progress already?); or I try to fix them before I land?
[12:36] <gary_poster> If you are not around to reply, my default will be to commit as is, merge with ~yellow's branch and push, and then try to fix some of those other issues.
[12:37]  * gary_poster proceeds to do that.
[12:39] <benji> gary_poster: sorry, I got distracted waiting for the list, pre-coffee attention span is lacking
[12:39] <gary_poster> np :-)
[12:40] <benji> +1 on committing what you have (especially with TODOs, I plan on doing a TODO/XXX purge before the end)
[12:43] <gary_poster> pushed to ~yellow
[13:03] <gary_poster> benji, I'd like to start keeping the punch list on the kanban board, please.  I have marked the bits that are specific to "unsubscribe in anger" as low.  I've added the two concrete bugs I mentioned above, as well as "Add JS tests".  I think you are working on that one?  If so, and you have no other objections, I'll move it to "coding" for you, and I'll move "load state properly and fully into overlay" into "coding
[13:03] <gary_poster> If you could then add your other punchlist items to Feature Work 1 tasks I would appreciate it.
[13:04] <benji> gary_poster: correct and +1 on "Add JS tests"; I'll add my other items as cards.  Do you want the non-required ones low and the required ones regular?
[13:05] <gary_poster> bac, benji, gmb, flacoste made a suggestion on how we might run our morning meeting a bit differently.  In sum, I'll be reviewing the kanban board and asking questions of you guys and asking for details.  Hopefully that will be faster, it will leverage the kanban board better, and it will maybe even help us with the collaboration thing (we'll see; brief details on call)
[13:05] <gmb> Cool, works for me.
[13:05] <gary_poster> cool thanks
[13:05] <bac> good experiment
[13:06] <gary_poster> benji, yes, that would be great, thanks
[13:06] <benji> k
[13:13] <benji> gary_poster: which part of the backlog should the punchilst items go in?  I've forgotten which of the subdivides was for what.
[13:17] <gary_poster> benji, feature list 1: tasks
[13:17] <benji> thanks
[13:17] <gary_poster> sure
[13:17] <benji> oh, ok
[13:18] <bac> gary_poster: do we have a means of testing IE?  i can set up a windows VM here if needed.
[13:19] <gary_poster> bac, the direction from Francis is to simply remove the "no IE" clauses from our JS
[13:19] <gary_poster> testing is extra niceness
[13:19] <bac> hmmm
[13:20] <gary_poster> his argument is that Firefox is the only browser that is truly officially supported
[13:20] <gary_poster> Because that's where the Windmill tests live
[13:20] <gary_poster> We fix webkit because it is in use
[13:20] <gary_poster> but we don't test any of these exhaustively
[13:21] <gary_poster> even FF is "most recent version on our test box"
[13:21] <gary_poster> IE should be given a chance to try and work
[13:21] <gary_poster> especially when the functionality has no alternative
[13:21] <gary_poster> Also, the "no IE" was added at a time that YUI 3 had a very poor IE story
[13:21] <gary_poster> Now AIUI it does not support IE 6
[13:22] <gary_poster> but later versions of IE are supported reasonably well
[13:22] <gary_poster> and IE 8 is the primary IE by far on LP
[13:22] <gary_poster> So anyway, please feel free to argue, but I was alright with it myself
[13:22] <benji> gary_poster: tasks added, I think there's one or two that I added that you've already done so a glance over them would be appreciated.
[13:23] <gary_poster> ack, looking
[13:23] <gary_poster> yes
[13:24] <benji> I think we need a small but visible warning to people using unsupported browsers.  I can only imagine the feeling of shoddy workmanship a corporate type visiting with IE would get.
[13:25] <gary_poster> I can see your position
[13:25] <benji> [in general, not just our latest work ;)]
[13:28] <benji> we did something like that on a previous project and it helped a great deal to both manage expectations and push people toward using supported browsers
[13:29] <gary_poster> understood. :-) I'd be happy if you were to advocate that in some appropriate forum.  The only argument against it that I can think of off hand is that, depending on how you define "supported" the list could be *really* small.
[13:29] <gary_poster> FF works fine for me on Chrome and Safari in addition to FF, but our support of Chrome/Safari is essentially catch-as-catch-can.  I dunno anyone who uses older versions of FF on the team.
[13:29] <gary_poster> Saying "we'll treat problems in browser X as high priority" might sound nice, but as we know from the size of the open bug collection in our bugtracker, that could be argued to be just hot air.
[13:29] <gary_poster> bac benji gmb, mumble/kanban in 1-ish
[13:29] <gmb> Ack
[13:37] <bac> crickets
[13:45] <gary_poster> that was not an example of "faster" but hopefully it will become so
[13:46] <gary_poster> ok, bac, so, you want me to just verify that the functionality works; or look at the code...?  Give me an idea of what you are looking for, please
[13:46] <gary_poster> standard review?
[13:46] <bac> gary_poster: just look the presentation, really
[13:46] <gary_poster> ok cool, trying
[13:47] <bac> gary_poster: i just put up two <a> links.  nothing fancy
[13:47] <bac> sanity check, really
[13:51] <gary_poster> bac, I would say that it is functional and reasonable.  In a perfect world, I'd have some CSS tweaks to change several things about the pane: "Select all" and "Select none" would be smaller...and if LP used underlines to show links like the rest of the world then I'd advocate that too, but nevermind.
[13:52] <gary_poster> I'd also put in some padding to the whole pane, as well as some horizontal padding for each of the checkbox items.
[13:52] <gary_poster> So in context, then, my take is "good, and let's maybe send the whole thing to Huw for some polish soon, or spend some time on that ouselves"
[13:52] <gary_poster> Good enough, or do you want to drillinto any of that?
[13:56] <benji> gary_poster: I have a ZF meeting on my calendar for today, any idea if that's right?
[13:56] <gary_poster> benji, might have been cancelled, because the board was all elected?
[13:56] <gary_poster> I mean, nominations equaled spots available
[13:57] <gary_poster> so voting was not necessary
[13:57] <benji> could be; I don't even remember getting the vote email, I wonder if they're still using my zope.com address
[14:01] <bac> gary_poster: thanks for looking at it.  i agree with your comments but think it may be best to send the whole thing off to huw for tweaking.
[14:01] <gary_poster> cool, bac
[14:39]  * gmb -> out for a run
[15:06] <benji> gary_poster: ZF meeting /is/ on (the time zone change made me be off by an hour); #zope-foundation
[15:06] <gary_poster> benji, ah, k
[15:07] <benji> gary_poster: are there any other ZF members at Canonical that we should remind?
[15:07] <gary_poster> ...
[15:07] <gary_poster> is sidnei?
[15:12] <bac> jml is doing a TDD presentation today at noon:  https://wiki.canonical.com/KnowledgeSharing/TDD
[17:21] <gary_poster> bac, you were asking for confirmation of whether the thunderdome was going to be in Ireland.  I asked Francis.  Still no confirmation, but he said it was a reasonable time to check back in with Marianna about it.
[17:21] <bac> thx
[17:23] <gary_poster> lunch
[18:51] <gary_poster> benji, ~yellow now has proper rendering of data (loading of state) in edit forms.  It may have fixed "patching fails if you try to use the accordion widget" on the way; not sure.
[18:51] <gary_poster> I'm now going to a card I added, "Normalize "any status" and "any importance" so that if all checkboxes are checked, or none, they are the same in summary display and checkbox redraw."
[18:51] <gary_poster> Notice I added another card too: "Make help links work (tags, subscription name)"
[18:52] <benji> k
[18:53] <gary_poster> or, bac, is there something I can do to help you?  "Make sure that clicking add subscription after an add or cancel displays a clean form " would suit me fine.
[18:53] <bac> gary_poster: that is a good one
[18:53] <gary_poster> ok, doing that
[18:54] <bac> gary_poster: i talked to curtis and getting our link in that portlet is best done by creating a hidden link.  that's going to require some surgery on the Link rendering
[18:55] <gary_poster> bac, brain surgery, or ear piercing?
[18:55] <bac> gary_poster: i hope it isn't too bad.  will need to add a new attribute to ILink and teach the renderer to include display:none or something similar
[18:56] <gary_poster> ok, yeah, doesn't sound awful
[18:56] <bac> should be straightforwardish but all of the abstraction around menuing makes my head hurt
[18:56] <gary_poster> yeah, I hear you. :-/
[18:56] <bac> gary_poster: so i plan to make a separately landable branch to do that and then wire it into our branch
[18:56] <gary_poster> sounds perfect
[19:17] <gary_poster> bac, if you open an overlay with "Subscribe to bug mail," make some changes, click cancel or click away to make the overlay vanish, and then click on "Subscribe to bug mail" again, what do you think should happen? 1) your changes are remembered or 2) you get a fresh start?  I have an opinion, but I'd like to hear yours and compare notes.
[19:21] <gary_poster> I'm going to make a decision, but I'll keep quiet on what it is until I hear from you...or until I have to land. :-)
[19:46] <bac> hey gary_poster
[19:46] <gary_poster> hey bac
[19:46] <gary_poster> I hope we agree ;-)
[19:46] <bac> sorry, my house is all tore up and a guy is here installing new floors.  sometimes it is distracting.
[19:46] <gary_poster> lol, np
[19:47] <bac> two rooms worth of stuff have been crammed into my office.  :(
[19:47] <gary_poster> hey, same here!
[19:47] <bac> gary_poster: i guess a cancel should wipe out your work and you get a fresh start
[19:47] <gary_poster> stuff that was in the baby-room-when-we-don't-have-a-baby was dumped out here
[19:48] <bac> same for reopening after a successful submit
[19:48] <gary_poster> bac, cool, agree, that's what I did.  Almost done.
[19:48] <bac> is click-away a different scenario?
[19:48] <bac> i guess not
[19:49] <gary_poster> It could be--I see why you ask, I think--but making it one might be annoying
[19:49] <bac> i can just see the 'i did lots of stuff and then it ate my work' bug
[19:49] <bac> probably from wgrant. :)
[19:49] <gary_poster> heh
[19:49] <gary_poster> I still think the desired behavior in that case is ambigious at most
[19:49] <bac> we're having an NC launchpad dinner tomorrow
[19:50] <gary_poster> and so implementing the easier one makes sense
[19:50] <bac> yeah
[19:50] <gary_poster> NC launchpad, huh?
[19:50] <bac> well, sackett wanted to try lantern
[19:50] <gary_poster> :-)
[19:51] <gary_poster> If that's an invitation, I could see if Karyn is up for it and we could get a babysitter
[19:51] <bac> oh, you're more than welcome if you can possibly come
[19:51] <bac> i assumed you were not doing a lot of social stuff these days
[19:51] <gary_poster> no, not so much, but K has wanted to go to Lantern
[19:52] <bac> oh.  well find out and i'll up the reservation.  it is currently at 6:15
[19:52] <bac> and i promise they will not have green beer
[19:52] <gary_poster> heh
[19:53] <gary_poster> cool.  I should know in half an hour or less; I suspect the answer is probably no, but thank you for mentioning it.  We'd definitely like to get together more often, though things will probably be more challenging, not less, for at least a few months after the delivery.
[20:01] <gary_poster> bac, enjoy.  We won't be able to do it this time.  K says maybe we can have you guys over sometime soon.
[20:02] <bac> that sounds great
[20:22] <benji> from the looks of it, it's not safe to run the tests on the ~yellow branch; right?
[20:24] <gary_poster> I'm probably guilty
[20:24] <gary_poster> I have no idea how to run the tests
[20:24] <gary_poster> which is probably bad, what with me changing things and stuff
[20:24] <gary_poster> how do I run the tests, benji?  I'll see if I can fix in a sec
[20:25] <benji> gary_poster: I was just running bin/test -c lp.bugs.browser and got a wall of errors
[20:25] <gary_poster> ah, those tests
[20:25] <gary_poster> yeah, I got scared of those earlier.
[20:25] <benji> (the JS tests are run like so xvfb-run ./bin/test --layer=RegistryWindmillLayer -cvvt test_yuitests)
[20:26] <benji> while I have your attention, did you write person_is_team_admin?
[20:26] <gary_poster> yeah, I've almost exclusively been touching the JS lately
[20:26] <gary_poster> benji, yes, and it is fixed in my branch.  sorry about that.
[20:26] <gary_poster> I can commit in just a sec
[20:27] <benji> heh, ok; sounds good
[20:34] <gary_poster> benji, pushed, along with fixes for a another related item or two you might have encountered.
[20:35] <benji> cool, pulling now
[20:35] <gary_poster> (the deletion of filters within subscriptions had been a bit hosed)
[20:35] <gary_poster> I'll see if I can see what lp.bugs.browser does...
[20:41] <gary_poster> benji: AttributeError: 'BugSubscriptionListView' object has no attribute 'structural_subscriptions' and AttributeError: 'TargetSubscriptionView' object has no attribute 'structural_subscriptions' are trivial.  I had set up an attribute for you to use when building your views, and you ignored it. :-P  I ripped it off locally, and forgot to remove the test.
[20:41] <gary_poster> That said, I've seen "UnknownEntryAdapter: No IEntry adapter found for Interface (web service version: devel).  Encountered as a result of the entry interface None, field ''." when I run LP.  That one is mildly scary to me and has been around for a little while.  I'll look into it.
[20:42] <benji> yeah, the IEntry one worried me a bit too
[20:57] <gary_poster> benji, looking at the diff with devel, this seems like the most likely culprit.
[20:57] <gary_poster> @export_factory_operation(Interface, []) # Really IBugSubscriptionFilter
[20:57] <gary_poster> That's on def addBugSubscriptionFilter(subscriber, subscribed_by):
[20:58] <gary_poster> I assume there's supposed to be a fix for a circular import.  I'm not entirely sure how to do that, but I think I know where to look.  If you already have an idea of what to do, though, I'm all ears.
[21:03] <gary_poster> yeah, I think I see it...
[21:10] <gary_poster> yeah, benji, that was it, and I have a fix.  I'll push it and a merge with devel in just a few, hopefully.
[21:21] <gary_poster> benji, pushed.  bin/test -c lp.bugs.browser passes and devel is merged
[21:21] <gary_poster> off to dinner
[21:22] <benji> gary_poster: cool; that was less painful than I expected