[09:17] <danilos> gmb, hi, did you have a chance to take a look at accordionlayer branch Gary mentioned?
[11:03] <gmb> danilos: Hi, sorry, missed your ping earlier as my connection was down. So, I've been looking at it and haven't got much further than you (judging by your email). However, I'm wondering if Gavin's changes to the way lp.js is build might have anything to do with it. Probably not but I'll ask him anyway.
[11:04] <danilos> gmb, right, thanks
[11:09] <gmb> danilos: So that's a no, then. Hmm.
[11:10] <danilos> gmb, yep
[11:19] <gmb> danilos: First up, I think we can drop the activate_collapsible_div code completely, since it's not referenced.
[11:19] <gmb> Of course, that doesn't solve our other problems, but at least it's one less thing to care about.
[11:19] <danilos> gmb, right, I did see activate_collapsibles somewhere
[11:19] <gmb> Yeah, there's activate_collapsibles(), which works, and activate_collapsible_div(), which doesn't appear to exist.
[11:20] <gmb> The latter is called in product-index.pt
[11:20] <danilos> ok, so I assume they are unrelated then :)
[11:20] <gmb> Yep.
[11:20] <danilos> (I was thinking it might have been a left-over typo from rename or something)
[11:20] <gmb> I think it might be that someone's reinvented the wheel and then backed out some of their changes.
[11:20] <gmb> But since nothing broke they never noticed the error.
[11:20] <gmb> Anyway, I'll remove that code now.
[11:22] <danilos> gmb, sure
[11:23] <danilos> gmb, also, I wonder where is the link supposed to show up (so I know what I am looking for, since I haven't looked at the code that deeply :)
[11:23] <gmb> danilos: It should appear under the "Administer" link in the top portlet, but only if you're logged in as Mark.
[11:24] <danilos> gmb, mark only, not if I am logged in as admin?
[11:24] <danilos> admin@canonical.com:test
[11:24] <gmb> danilos: Mark only, last I checked.
[11:24] <gmb> ]
[11:24] <gmb> mark@example.com:test, IIRC
[11:25] <danilos> ugh, /me hits himself over the head for not following the instructions as written :)
[11:25] <danilos> and launchpad.net/firefox oopses if you are not logged in :)
[11:27] <gmb> danilos: Yeah, that's a fun one.
[11:28] <danilos> gmb, ok to commit the fix for that: https://pastebin.canonical.com/44657/
[11:30] <gmb> danilos: Yes, go for it.
[11:30] <gmb> danilos: You'll need to merge the latest ~yellow/launchpad/accordionoverlay
[11:31] <danilos> gmb, yep
[11:41] <gary_poster> hi!
[11:41] <gary_poster> any wondrous solutions? :-) I see the emails showing progress
[11:43] <gary_poster> btw, danilos, I hope you weren't working on unsubscribe in anger.  I have some significant changes from your branch in a branch of my own.  If you have been, no worries--we can connect in a little while and compare notes
[11:43] <danilos> gary_poster, hey-hey
[11:44] <danilos> gary_poster, no, I haven't since I've seen the emails, and that was right away in the morning :)
[11:44] <gary_poster> hey!  cool.
[11:44] <danilos> gary_poster, so, I was enjoying the JS debugging :)
[11:44] <gary_poster> heh
[11:44] <gary_poster> how was the test?
[11:45] <gary_poster> also, I was wondering if you and gmb have daylight savings time yet.  US chnged this weekend
[11:46] <danilos> gary_poster, we'll see, not too happy with it
[11:46] <danilos> gary_poster, hum, I think we're on only next week
[11:47] <gary_poster> test: :-( sorry to hear, but hopefully you'll be happily surprised
[11:47] <gary_poster> ok, next week is not too far away :-)
[11:47] <danilos> gary_poster, actually, it's two weeks away: http://www.timeanddate.com/news/time/europe-starts-dst-2011.html :)
[11:48] <gary_poster> :-) ok
[11:49] <gary_poster> I'll ask around what everyone wants to do for the two weeks--move to the US version of 8:30 now (in 41 min) or wait till you guys have moved
[11:49] <gary_poster> either way is fine with me
[11:51] <danilos> gmb, fwiw, even if I ignore the issue of LP.links.me being undefined (and set it manually in the code to "/~mark" :), LP.cache.context causes the next error, so I guess loading order is what we need to fix
[11:53] <gmb> danilos: Right. And here's a weird thing. If you do
[11:53] <gmb> console.log(LP);
[11:53] <gmb> console.log(LP.links.me);
[11:53] <gmb> The first shows that LP.links.me is set correctly ("/~mark") but the second shows that it's undefined.
[11:54] <danilos> gmb, I explained that in the email, the first one stores a reference to the object, and you evaluate it only when you look at it
[11:54] <gmb> Oh.
[11:54] <gmb> danilos: Sorry, missed that message (or glazed over, one of the two)
[11:54] <danilos> it's generally a smart idea to ignore me (i.e. 9 out of 10 times), but sometimes I hit the nail on the head :)
[11:54] <gary_poster> lol
[11:55] <gary_poster> I'm guessing you guys saw Gavin's email about rebuilding etc?
[11:55] <gary_poster> emailS
[11:55] <gmb> gary_poster: Yes. His work seems to have introduced some debugging noise into the JS console, but he's given me a workaround for that and is emailing the list about it.
[11:56] <danilos> gary_poster, right, I've seen it, and 'make jsbuild' has been functioning correctly for me (and I prefer the non-minified version, so I didn't need the min option)
[11:56] <danilos> gmb, I am looking forward to that email, but if it's easy enough, I wouldn't mind hearing from you directly about the workaround
[11:57] <gary_poster> cool
[11:57] <gmb> danilos: make clean_js; make JS_BUILD=min jsbuild_lazr; make JS_BUILD= -W jsbuild_lazr jsbuild
[11:57] <gmb> Apparently, if you s/min/raw you get unminified JS, too.
[11:58] <danilos> ah, nice
[11:59] <danilos> ok, so the first thing I'll do is try to run setup() from non-domready and see how that works
[12:01] <danilos> yes, that works
[12:01] <gmb> danilos: Great minds :)
[12:02] <gmb> Although it would have been quicker if I'd remembered that syntax matters.
[12:08] <danilos> so, this is https://pastebin.canonical.com/44658/ what will allow one to get a subscription link by clicking on a big ugly h2 in the middle of the page :)
[12:10] <gary_poster> :-)
[12:10] <gary_poster> ship it!
[12:11] <danilos> heh, yeah, "Click to load" is inviting enough :)
[12:12] <danilos> it should at least allow some of us to test the real stuff, while others try to figure out the load ordering problem :)
[12:12] <danilos> anyway, gary_poster, call still in 1h18 mins? (I want to get lunch before that then)
[12:13] <gary_poster> danilos, you are the first to voice a preference, and we need to make a decision now, so sure, your preference wins. :-)
[12:15]  * gmb grabs lunch too
[12:15] <danilos> gary_poster, heh, I am basing my "preference" on what works for me today, but sure, it's fine in general as well :)
[12:15] <gary_poster> bac and benji, gmb and danilos do not change DST for two more weeks.  For these two weeks, I suggest we let them keep their same times for the morning meeting, and we move to 9:30.  When they switch, we'll switch back.  They have lunch schedules to work with  and such.
[12:16] <gary_poster> cool danilos :-)
[12:16] <benji> ok
[12:16] <benji> daylight saving time is the devil
[12:16] <gary_poster> :-)
[12:17] <gary_poster> benji, btw, I made some server side changes that affect your work, particularly in browser/structuralsubscription.py.
[12:18] <gary_poster> bbs
[12:18] <benji> k
[12:18] <gary_poster> (they are pushed to accordion overlay
[12:18] <gary_poster> )
[12:50] <gary_poster> bac and benji, danilos and gmb are lunching.  are one of you tackling the JS problem , or both of you?  If you are not tackling that problem, note the pastebin danilos gave above to get something working so you can fix other stuff.
[12:51] <bac> gary_poster: i'm looking at it
[12:51] <gary_poster> ok thanks bac
[12:51] <benji> I'm blistfully ignoring the problem at the moment.
[12:51] <gary_poster> sounds perfect
[13:29] <gary_poster> bac benji danilos gmb mumble/kanban in 1-ish
[13:29] <bac> ok
[13:29] <gmb> Yarp
[13:30] <danilos> ack
[13:41] <benji> gmb: I use a gmail filter to add a label to mail sent directly to me in a colo(u)rful way so it stands out from the sea of in-direct mail I get
[13:42] <gmb> benji: As do I, but bugmail comes directly to me still. At least I think it does. I'll have a look.
[13:42] <gmb> (I know I need to fix my filters since everything went to launchpad rather than being in {malone, rosetta, soyuz, etc.} anyway)
[13:46] <benji> oh, that's why it works for me, I use a different address for bugmail so they don't get the colo(u)rful label
[14:01] <gary_poster> benji, locally I now have a working (modulo the fix for the onload thing from Friday that's affecting all of us) page https://bugs.launchpad.dev/firefox/+subscriptions that shows subscriptions-per-target using the exact same code of yours as powers https://bugs.launchpad.dev/firefox/+bug/1/+subscriptions .  So, once the other fix is done, I'll commit this and we should be good there.
[14:01] <_mup_> Bug #1: Microsoft has a majority market share <iso-testing> <ubuntu> <Clubdistro:Confirmed> <Computer Science Ubuntu:Invalid by compscibuntu-bugs> <EasyPeasy Overview:Invalid by ramvi> <GNOME Screensaver:Won't Fix> <Ichthux:Invalid by raphink> <JAK LINUX:Invalid> <The Linux OS Project:In Progress> <metacity:In Progress> <OpenOffice:In Progress by lh-maviya> <Tabuntu:Invalid by tinarussell> <Tivion:Invalid by shakaran> <Tv-Player:New> <Ubunt
[14:01] <gary_poster> I did see one oddity that was pertinent to our discussion Friday
[14:01] <benji> nice
[14:01] <benji> what's that?
[14:02] <gary_poster> Somehow I managed to make a subscription to  “mozilla-firefox” package in Ubuntu that does not have a filter
[14:02] <danilos> ok, figured out the problem, and it's as simple as us not using a closure for the event handler, so the following fixes it: https://pastebin.canonical.com/44665/ (I fired a special lp-ready event when all the data was set up and still got undefined, which pointed me at the problem)
[14:02] <gary_poster> Not quite sue how
[14:02] <gary_poster> ah, danilo!
[14:02] <danilos> gary_poster, fwiw, I might have forgotten to update the sampledata, so maybe that was just an existing one
[14:03] <gary_poster> cool danilo, I'll verify
[14:03] <gary_poster> (sampledata I mean)
[14:03] <gary_poster> danilo, that patch makes perfect sense now that I see it :-P
[14:03] <danilos> yeah, so, how do I proceed from here? land this on accordionoverlay branch directly?
[14:04] <gary_poster> yeah I think so.  We'll give bac a second to have an opinion?
[14:04] <danilos> gary_poster, heh, yeah, it's nice that JS/YUI lets you do stuff like this
[14:04] <danilos> sure thing, bac, what do you think of the following fix for the JS load problem: https://pastebin.canonical.com/44665/
[14:04] <gary_poster> yeah
[14:04] <bac> sorry was afk for a bit.  reads back.
[14:05] <bac> danilos: why does that work?
[14:06] <gary_poster> what we had before calls module.setup({content_box: "#structural-subscription-content-box"}) immediately and registers that result as the domready callback
[14:06] <danilos> bac, because previous version ran setup() when defining an event handler and set the return value (probably null) as the event handler
[14:06] <bac> gah
[14:06] <bac> land away!
[14:06] <gary_poster> :-)
[14:06] <danilos> bac, ack, off it goes
[14:06] <gary_poster> thanks danilos, great
[14:09] <danilos> it's very "nice" that: 1) YUI lets you do this, 2) this is so obvious from syntax that multiple of us spent hours on it; /me feels sad for JS taking over the world as a de facto programming language
[14:10] <danilos> anyway, landed, gary_poster, when you've got a minute, it'd be nice to chat about what do I do next :)
[14:10] <gary_poster> heh
[14:11] <gary_poster> cool danilos.  what to do next: would one of the two jobs benji listed for you be ok?
[14:11] <gary_poster> actually, gimme a sec
[14:11] <gary_poster> I'm applying your fix to those pages too
[14:12] <danilos> gary_poster, ok, let me read through the proposed tasks in the meantime
[14:12] <gary_poster> cool
[14:16] <gary_poster> benji, danilos, ~yellow/... has the code to fix up [bugtarget]/+subscriptions to work, and to make [bug]/+subscriptions to have the new JS fix
[14:16] <gary_poster> so now I need to know what to do too.  :-)
[14:16] <benji> :)
[14:17] <danilos> gary_poster, would one of the two jobs benji listed for you be ok? :P
[14:17] <gary_poster> actually, I'm going to go see if I can dupe making a structural subscription to a package that does not have a filter
[14:17] <danilos> ok, never mind that then :)
[14:18] <gary_poster> danilos, what I'm going to do is just verify.  Then I'll look into one of those two, probably, yeah.  So, tell me which one you are going to work on and I'll try to do the other one
[14:18] <danilos> gary_poster, just to confirm, that work should be based off ~yellow/.../accordionoverlay
[14:18] <gary_poster> danilos, you want to chat about the unsubscribe in anger work now for a sec even though we are not focusing on it?
[14:19] <gary_poster> yes danilos
[14:19] <danilos> gary_poster, sure thing, that's fine as well
[14:19] <gary_poster> cool
[14:19] <gary_poster> I'll push a branch for you then I'll be ready
[14:22] <gary_poster> danilos, I don't know if we'll need to look at the branch or not, but it is lp:~gary/launchpad/bug728370 .  Also I made changes (mostly additions) to https://dev.launchpad.net/LEP/BetterBugSubscriptionsAndNotifications/DirectSubscriptionsOnBug
[14:22] <bac> hurrah, danilos, my subscription link has returned!  thanks!
[14:53] <danilos> bac, cheers :)
[14:53] <gary_poster> danilos, you're going to give benji the "it's broke" news? :-)
[14:53] <danilos> benji, hey, I am looking at "Save Changes" button you proposed, but I can't get anything to happen when I click on "Edit subscription" button
[14:53] <danilos> gary_poster, already on it :)
[14:53] <gary_poster> yeah :-)
[14:54] <danilos> benji, (ftr, I am using ~yellow/lp/accordionoverlay branch)
[14:54] <danilos> benji, if I should use a different branch or debug the problem, just let me know
[14:54] <benji> danilos: darn; it works in my checkout and I was just about to merge from ~yellow/lp/accordionoverlay and push my changes so I'll be able to look at it momentarily
[14:55] <danilos> gary_poster, oh, one thing: what do I do on the kanban board? :)
[14:55] <danilos> gary_poster, (because I am only assigned to stuff that I am not working on :)
[14:56] <benji> danilos: if you don't want to wait you can work from ~benji/launchpad/yellow-accordionoverlay which should work for you
[14:56] <danilos> benji, ok, sounds good, thanks
[14:57] <danilos> benji, this is all feature work 2, right?
[14:57] <benji> danilos: nope, feature work 1
[14:58] <danilos> benji, oh, right, thanks
[15:06] <gary_poster> sorry danilos, yeah, feature 1.
[15:08] <gary_poster> benji, danilos, I think foo.bar must have had a sample-data subscription, as danilos suspected.  I unsubscribed and resubscribed, and he had a filter.
[15:08] <gary_poster> (after the resubscription)
[15:09] <benji> is this for the "“mozilla-firefox” package in Ubuntu" subscription?  if so, I believe that comes from sampledata
[15:09] <gary_poster> yes, benji
[15:10] <danilos> gary_poster, right, I've add a quick-jobs task to update the sample data (to avoid future confusion), if you don't think that warrants a task, just drop it
[15:10] <danilos> gary_poster, oh, btw, did the query improvement prove enough?
[15:10] <gary_poster> task: cool, danilos, sounds like a good idea unless benji decides we don't need to have a filter for every subscription after all
[15:11] <benji> nope, a filter in every pot^W subscription is here to stay
[15:12] <gary_poster> query: it seems so.  on staging the two pertinent queries were 1 ms and 30 ms, respectively, so I declared it a victory.  the oops tool is aggregating these timeouts poorly so it's hard to be completely confident, but it looks pretty good
[15:12] <gary_poster> ok good to know benji, thanks
[15:12] <danilos> gary_poster, cool, great job there!
[15:12] <gary_poster> thanks :-)
[15:18] <gary_poster> benji, your branch is already merged in with ~yellow :-/
[15:19] <benji> gary_poster: I've merged it before, but since made more changes and plan on merging it again.  Is that problematic?
[15:20] <gary_poster> benji, no I just meant that, at least as of the version of ~benji/launchpad/yellow-accordionoverlay that I just got, it's already been merged in with ~yellow/launchpad/accordionoverlay/ and the problem that danilos descibes exists there.  Therefore, merging doesn't show us what might be going wrong.
[15:21] <gary_poster> the diff between those two branches is 36187 lines
[15:21] <benji> gary_poster: well, I'd hoped that merging would break my working copy (in hopefully the same way) so that I can fix it
[15:22] <danilos> benji, you've been very productive if it's 36k lines :)
[15:22] <gary_poster> merging ~yellow into ~benji will probably break ~benji, yes
[15:22] <gary_poster> :-) I think the 36K is changes in devel since benji branched
[15:23] <benji> I believe they are.
[15:23] <gary_poster> or, last merged, I should say
[15:29] <benji> darn, this looks like something I've already fixed; maybe I fixed it wrong or another merge accidentally clobbered my last fix; I need tests
[15:31]  * gmb -> run
[15:31] <gary_poster> bac, did you and jon agree on who will actually remove that bad JS function call, or is that still up in the air?  if it is still up in the air, I'm going to send him a reply thanking him and asking him to clarify if he is going to do it, or if he is just going to file a bug and we should do it.
[15:31] <bac> gary_poster: yes, i'm removing it in my gallery-accordion update branch.
[15:31] <gmb> gary_poster, bac: I removed the bad call from the ~yellow branch this morning.
[15:31] <bac> i've just submitted it for review
[15:32] <gary_poster> great, thank you bac and gmb
[15:32] <bac> i think it has been removed about half-dozen times today
[15:32] <gary_poster> :-)
[15:32] <gmb> Distributed development FTW.
[15:32]  * gmb -> really run
[15:32] <gary_poster> lol
[15:35] <benji> danilos, gary_poster: I just pushed my branch to ~yellow which also contains the fix
[15:36] <gary_poster> yay benji, thanks
[15:36] <benji> well, it's currently pushing
[15:36] <gary_poster> heh, SPEED!
[15:36] <gary_poster> benji, I'm going to tackle the unsubscribe link
[15:36] <benji> she can'a take no more capt'n
[15:36] <gary_poster> :-)
[15:36] <danilos> benji, cool, danke!
[15:37] <gary_poster> You said "I
[15:37] <gary_poster> believe the REST collection operations are the way to remove a filter,
[15:37] <gary_poster> but I'm not sure how, exactly."
[15:37] <gary_poster> Forgive the flail,
[15:37] <gary_poster> but do you have any ideas on where to start?
[15:37] <gary_poster> My thoughs:
[15:37] <gary_poster> 1) ask leonard
[15:37] <gary_poster> 2) grep for ... something.  find a collection and then grep js for that name?
[15:38] <gary_poster> 3) (obvious winner) ask Benji!
[15:38] <benji> a hint: I would have been more specific if I knew the specifics ;)
[15:39] <gary_poster> lol, ok, proceeding with #2 and then #1 :-)
[15:39] <gary_poster> (I can also ask Graham when he returns)
[15:40] <gary_poster> dang, is the pull *still* going on?
[15:41] <gary_poster> push I mean
[15:41] <danilos> bac, hi, it seems you've overwritten a few changes gmb and I put into ~yellow/launchpad/accordionoverlay (and then recommitted them, so no big harm done, but just saying)
[15:41] <benji> gary_poster: bzr: ERROR: These branches have diverged.
[15:41] <benji> trying to fix now
[15:41] <danilos> fwiw, integration branches suck because we all have to behave as pqm
[15:41] <gary_poster> ah, I think you and Brad got in a race, benji
[15:41] <benji> that would explain it
[15:42] <gary_poster> ack danilos.
[15:43] <danilos> the proper way to merge something would be: (cd shared-accordionoverlay && bzr pull lp:~yellow/launchpad/accordionoverlay && bzr merge my-branch && bzr ci -m "Merge my branch doing foo-bar." && bzr push)
[15:44] <gary_poster> well, that's still a race condition, just a shorter one, yeah>
[15:44] <danilos> and never, ever use push --overwrite :)
[15:45] <danilos> gary_poster, I am suspecting push --overwrite is what happened here
[15:46] <gary_poster> ah :-/
[15:47] <benji> gary_poster: push succesful
[15:49] <gary_poster> benji: "No revisions to pull."  Maybe wrong destination?
[15:49] <gary_poster> (I used "bzr pull :parent" and then "bzr pull lp:~yellow/launchpad/accordionoverlay/" just for apranoia)
[15:49] <gary_poster> paranoia
[15:49] <benji> gary_poster: yep, wrong destination; I guess I should do it the way danilos described instead of pusning directly, so that'll take second
[15:50] <danilos> that's the problem of an override in locations.conf, I'd love a solution to that (not even --remember helps :()
[15:56] <benji> gary_poster: this time for sure
[15:57] <gary_poster> benji, seems to have worked :-)
[15:57] <gary_poster> thanks
[15:57] <benji> np
[16:30]  * danilos -> off, tty tomorrow
[16:34] <gary_poster> bye danilos, thank you
[16:55] <bac> danilos: i didn't use overwrite so i figured i was ok
[17:01] <benji> gary_poster: do you know how much progress danilos made on the save button?  Are you doing the Unsubscribe link?
[17:01] <gary_poster> no, and yes, benji
[17:02] <benji> gary_poster: ok, I figured that if he didn't make much (or his work was publicly available) I would pick it up
[17:03] <gary_poster> I suspect he would have told us if it were publicly available.  I have no idea as to his progress. :-/  If you have something else valuable to tackle, that might make sense.  Otherwise I might be able to come up with ways to divide up mine if you wanted.
[17:08] <benji> k
[17:12] <gary_poster> benji, what is the minimum I have to do to get my changes to structural-subscription.js used?  rebuild the js somehow?  do I have to restart LP?
[17:13] <benji> gary_poster: make jsbuild
[17:13] <benji> (and reload the page of course)
[17:13] <gary_poster> I don't have to restart?
[17:15] <benji> nope
[17:15] <gary_poster> cool thanks
[17:15] <benji> I assume the resources are either served by apache or are "resources" in the zope sense and since the server is in developer mode they are reloaded on every request
[17:16] <gary_poster> right, cool
[17:16] <gary_poster> Does thismean anything to you?
[17:16] <gary_poster> https://bugs.launchpad.dev/firefox/+bug/1/+subscriptions
[17:16] <_mup_> Bug #1: Microsoft has a majority market share <iso-testing> <ubuntu> <Clubdistro:Confirmed> <Computer Science Ubuntu:Invalid by compscibuntu-bugs> <EasyPeasy Overview:Invalid by ramvi> <GNOME Screensaver:Won't Fix> <Ichthux:Invalid by raphink> <JAK LINUX:Invalid> <The Linux OS Project:In Progress> <metacity:In Progress> <OpenOffice:In Progress by lh-maviya> <Tabuntu:Invalid by tinarussell> <Tivion:Invalid by shakaran> <Tv-Player:New> <Ubunt
[17:16] <gary_poster> meh
[17:16] <gary_poster> uncaught exception: [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIXMLHttpRequest.setRequestHeader]"  nsresult: "0x80004005 (NS_ERROR_FAILURE)"  location: "JS frame :: https://bugs.launchpad.dev/+icing/rev12438/build/launchpad.js :: _setHeaders :: line 29595"  data: no]
[17:16] <gary_poster> Line 0
[17:16] <gary_poster> benji ^^^
[17:16] <gary_poster> running to lunch now though :-P
[17:18] <benji> nope; the client sets some X headers to pretend to be using PUT, that'd be my first guess.  Why it's not working I don't know.
[18:06] <gary_poster> k thanks
[18:31] <benji> do we expect the YUI tests to fail when we run "xvfb-run ./bin/test --layer=RegistryWindmillLayer -cvvt test_yuitests"?
[18:33]  * gary_poster would expect not, but expects/hopes bac would have a better idea
[18:33] <bac> hi
[18:34] <bac> benji: i would expect them to pass but i haven't tried in a while
[18:34] <bac> i've just been loading up in a browser
[18:34] <bac> i'll try now.
[18:34] <benji> It may not be a test failure as much as a test error: AssertionError: Test harness or js failed.
[18:40] <benji> gary_poster: I guess I need to recruit a new RM now; I suppose an email to lp-dev is the way to go.
[18:41] <gary_poster> benji, sounds about right.  if there are no replies, Francis/the team leads will bustle about I expect
[18:41] <bac> benji: that's a great CYA error message
[18:41] <benji> gary_poster: k
[18:41] <benji> bac: heh
[18:41] <bac> i got it too
[18:43] <bac> benji: it is pretty bad.  it means it got no yui test results
[18:43] <benji> bad indeed
[18:45] <gary_poster> benji, if you have more than one subscription on the page, they are all numbered 0.  (e.g., edit-0, unsubscribe-0).  I'm looking into it, but giving you a chance now to tell me in case you've already fixed it or are working on it
[18:45] <benji> gary_poster: that's a new one
[18:45] <gary_poster> cool
[18:47] <benji> gary_poster: is that on the bug subscriptoin listing?  I don't see that behavior.
[18:48] <gary_poster> benji, yes.  the reason why is that you restart link_id to be 0 for each subscription_info, but you expect link_id to be unique in wire_up_edit_links.  I see why you did it, but it doesn't work well for finding thigs by id, the way it's done now
[18:49] <benji> ah!
[18:50] <benji> yeah, I'd be happy for us to find a better way
[18:50] <benji> until then you could make the counter a global and not reset it
[18:50] <gary_poster> cool, looking into it
[18:54] <gary_poster> benji, so here's an odd one.  I am successfully sending "DELETE /api/devel/firefox/+subscription/name16/+filter/1" to the server, and getting back a 200, but they are not actually deleted. :-/
[18:54] <benji> bac: are you investgating the YUI test failure further or shall I take it on?
[18:54] <gary_poster> I guess I'll have to pdb in the publisher, 'cause I have no idea what else to do
[18:54] <bac> benji: i'm looking righ tnow
[18:57] <benji> k
[19:08] <benji> I find the use of "constants" in structural-subscription.js overdone.  E.g., option.set(INNER_HTML, team.title);
[19:13] <bac> benji: some i lifted and probably too many.  others are useful.
[19:14] <benji> EXPANDER_COLLAPSED and     EXPANDER_EXPANDED = '/@@/treeExpanded',
[19:14] <bac> i think the pattern is there b/c JS will silently let you use the wrong string literal
[19:14] <benji>  oops
[19:14] <benji> EXPANDER_COLLAPSED and EXPANDER_EXPANDED make sense as constants
[19:15] <benji> silently?
[19:16] <gary_poster> you can set an attr on a dom node and JS won't complain if you are setting innrHTML rather than innerHTML, I believe he means
[19:17] <benji> that sounds a lot like how Python will let you set an attribute on an object and won't complain if you are setting innrHTML rather than innerHTML
[19:46] <bac> benji: i had turned off output to the console for debugging.  that's why the testrunner died.
[19:47] <benji> bac: interesting; let me know when the fix is available on ~yellow; thanks
[19:47] <bac> benji: i just pushed a new version to ~yellow but have not been able to verify it.  i'll be afk for a bit so if you could try it out that would be helpful
[19:47] <benji> cool, will do
[19:48] <bac> benji: test just finished.  seems to work.
[19:48] <benji> k
[20:20] <benji> Does anyone know of a way to run a subset of the YUI tests?
[20:21] <gary_poster> I think I've heard that you can't.  but you probably shouldn't go by my hearsay.
[20:21] <benji> I hope it's not true.
[20:22] <gary_poster> deryck is gone by now...bac is the only person I'd know to ask who might be around at this hour
[20:22] <gary_poster> I *assume* deryck is gone now
[20:22] <gary_poster> gary, source of assumptions and hearsay :-P
[21:00] <bac> benji: no, you cannot run a subset within a group
[21:00] <bac> i.e. you have to run all registry at once
[21:00] <benji> ok; thanks for the info
[21:05] <bac> gary_poster: next to deryck, sinzui has been most involved in yui-test stuff.
[21:21] <gary_poster> bac, ah good to know thanks
[21:22] <bac> gary_poster: plus sinzui works extra late now!
[21:31] <gary_poster> heh, even better
[21:45] <gary_poster> night all