=== Ursinha is now known as Ursinha-afk === gary-lunch is now known as gary_poster [13:21] hey bac. I am checking out the add widget. It is looking good. Even the help text presentation is good enough for now. I strongly suspect you are aware of all of these, but I have a few notes as I click around. [13:22] 1) until we have a better approach implemented, I suggested including the ellipsis (or "[more options]"?) at the end of "are added or changed in any way" and "bugs must match this filter" when they are not expanded. [13:23] 2) We should consider including the "-" feature of tag matching in the tag help. I say consider because I'm not sure that introducing the complexity here is worth it, but it is a thought I have. [13:24] 3) the importances don't look like they are sorted yet. They ought to be. [13:26] 4) It looks to me like we need some padding within the primary div of each accordion pane. Just a bit. Right now it looks just a hair cramped to me on the edges. [13:27] 5) If you select a team from the team dropdown, the radio button for "One of the teams you administer" should be selected IMO [13:27] 6) "filter out comments" is selected initially. I don't think it should be. [13:28] 7) You mentioned the Cancel button visual oddity. I agree, but it is a low priority. [13:28] That's it. You probably have all of those, but I wanted to be explicit about them. [13:28] bac benji gmb, mumble/kanban/weekly call in 2 [13:29] oh meh, I didn't do my action items :-( [13:29] or file my expenses :-( [13:30] ok [13:30] yoohoo gmb [13:30] gmb no aqui [13:30] he emailed me to say he had to be out [13:30] oh! [13:31] ok [13:31] 1 sec and I'll be there [13:53] http://www.amazon.com/Waltzing-Bears-Managing-Software-Projects/dp/0932633609 [14:45] anyone up for an informal team-based bookmooch? [14:57] bac, you mean trading books around? I'd be up for that, but I've been getting a lot of my books these days as e-books, which don't loan that well unless I remove the DRM, which I have been tempted to do but have not gotten around to. [14:57] I actually can loan my current project management e-book 'cause it is not DRMed. [14:57] I have some SciFi/Fantasy real books I'd love to share/loan/give to whoever is interested [16:20] gary_poster: i meant, mainly, books for work like the one benji referenced [16:20] cool [16:20] gary_poster: plus you can now loan kindle books. but only one per book's lifetime [16:21] s/one/once [16:21] yeah, which is freaking insane [16:21] and it is only for certain books AIUI [16:22] I have these on Kindle right now...I'm at various stages of reading them [16:22] Crucial Confrontations [16:22] The Non-Designer's Design Book [16:23] Flexible Web Design: Creating Liquid and Elastic Layouts with CSS [16:23] Manage It! [16:23] The last one is the one I suspect is similar in part to Waltzing with Bears [16:24] Oh, and Manage It! is an epub, not Amazon [16:24] REST in Practice [16:25] Introducing HTML 5 [16:25] I'm kinda done with those two. Maybe. [16:25] I have a few dead-tree books that someone might be interested in: Relase It!, Waltzing with Bears, Peopleware (I suspect everyone's already read it), Managing Humans [16:25] And I hope to get back to and Teach Yourself Electricty and Electronics [16:26] I'd be interested in Peopleware (I've heard about it so much I feel like I've read it) and Waltzing with Bears, but it would be silly to claim those right now [16:26] given the rest of my list [16:26] :) === bac` is now known as bac [16:30] I updated https://dev.launchpad.net/yellow with notes from today's call and also sent out an email about it since almost half our number were missing [16:31] I sent an email to Francis about the schedule slip; no word back yet. [16:32] Also, as a reminder and so folks know, our baby is due April 22, which is getting surprisingly close when you think in terms of weeks. [16:37] gary_poster: do you know what kind of paternity leave you'll be taking? [17:08] benji, I expect around 1 week. no more than 2 [17:09] I don't envy the sleepless nights [17:10] :-) [17:42] hi benji are you currently working on structural_subscription.js? if so, it might be good for us to coordinate. i'm still trying to work out all of the merge issues and fear what may happen if it is still a moving target. [17:44] bac: yep, I'm working on it, but at a very slow pace at the moment (trying to debug something) [17:45] ok [18:08] benji: i just pushed a new rev to bzr+ssh://bazaar.launchpad.net/~yellow/launchpad/accordionoverlay/. this version fixes all of the merge issues i could find. you may want to exercise it manually to ensure your stuff still works [18:08] benji: note i do have one known but not understood failure in my test. [18:09] bac: thanks; I'll also attempt a merge from there a little later so we can keep in sync [18:09] k [18:37] gary_poster: Question on the 'add a filter when creating a subscription' bit": is that enforced in the DB? I need to add a "don't create an initial filter" flag to addBugSubscription. [18:37] no, it is not, benji [18:37] cool [18:38] will that be across separate transactions? [18:38] IOW, it will conceivably lead to subscriptions without filters? [18:38] If so, I'm concerned by it. [18:39] given Murphy's Law, it will [18:39] right [18:39] so, I'd encourage considering another approach [18:41] unfortunately this is about the third one I've considered; if I had a way to know that a subscription was just created (the code lies if one wasn't and just returns the preexisting one) then I'd still have the race condition of someone else modifying the filter before I do [18:42] have we added any real requirement that subscriptions always have filters? if not, rescending that may be the best choice [18:42] can it return an identifier of what was created? [18:42] I wish Leonard were around because I'd like to run this problem by him [18:43] right now it returns a redirect to either the subscription that was just created or the pre-existing subscription with no hint as to which really happened [18:44] ok...so this is actually mixed with another problem [18:44] or, put another way, you encountering a practical ramification of a theoretical worry I've had before [18:44] I /guess/ I could add a response header to tell you what happened. That's really a shame though because the right way to do that is to return a different status code in that case, but the LP code "lies" about creating the subscription to lazr.restful which duitifully reports back "hey, I created it!" [18:44] what's that theoretical worry? [18:44] that can't be corrected? [18:45] re. correcting the lie: it could, but the API has acted that way since 2008. I felt that adding another API was a big step so shied away from that [18:46] theoretical worry is that the REST API reflects our model too well here. The fact that we want our users to think of filters as subscriptions is lost in the REST API. Another related problem is a card in the back log now: "Webservice deletion of filters on structural subscriptions needs thought" [18:47] indeed, we need something like the view layer [18:47] approach 1: since 2008: can the pertinent code change happen in the devel layer only? [18:48] the devel version I mean, sorry [18:48] this is a reasonable change to an API [18:48] and that's what that functionality is for [18:48] That said, back to the idea you started with... [18:49] hmm, I don't know how to spell that (or if it's possible) [18:49] we were trying to make every subscription have a filter in order to make things simpler for display and editing [18:50] if we simply state that our views will have to hide the situation from our users... [18:50] right... it might have backfired (or this could be easier in some circumstances than the other way) [18:50] you are going to be the one who has to pay the price primarily, either way [18:51] so you ought to have the freedom to make the decision [18:51] to go down this road, you'll need to be able to handle a structural subscription without any filters as if it had an empty filter [18:52] both for views and for edits [18:53] are those implications relatively clear, or would it be helpful for me to try and enumerate? [18:53] the kind of thing I mean: a structural subscription with a single "anything" filter and a structural subscription without any filters should be transparently identical from the perspective of working with your view and edit interface [18:54] gary_poster: quite clear [18:54] ok [18:54] gary_poster: what's our policy on write-on-read? [18:55] doing an accational w-o-r might make it really easy to deal with [18:55] w-o-r: don't do it if at all possible. We go so far as to enforce it with the DB [18:55] There is an escape hatch [18:56] but it is not liked [18:57] ok, thanks; I'll endeavor to avoid it then [18:58] cool. benji, if you decide conclusively to not require filter-per-subscription, it would be good to do it today, and then we need to clarify in bug 728818, bug 723999, and explicitly to Robert that this no longer needs to happen. [18:58] <_mup_> Bug #728818: Production and qastaging should have a filter for every structural subscription < https://launchpad.net/bugs/728818 > [18:58] <_mup_> Bug #723999: BugNomination:+edit-form structural subscriptions taking 4.8 seconds during nomination editing POST

< https://launchpad.net/bugs/723999 > [18:59] ok, I'll try to decide one way or the other today [19:01] gary_poster: do you think I'm unnecesarily avoiding adding an API? If so, that might be the best route. [19:02] decide one way or the other today: great, thank you benji. On a related topic, I'm about to start work on a branch to add the view with the subscriptions per taget. I'd like to know where to look at your punchlist too. [19:02] Danilo will be working for a half day before we start Monday, so you and/or I should communicate the goals and the punchlist to him as clearly as possible to him in an email before we leave today. [19:03] unnecessarily adding an API: thinking... [19:03] "It depends" :-) [19:03] gary_poster: https://pastebin.canonical.com/44626/ [19:04] :) [19:04] I feel like there's a pattern here that someone should have already worked out [19:04] ...someone at the door and I'm home alone, one sec [19:04] punchlist: tests of some sort are hard requirements too [19:04] cool [19:05] So API: [19:05] If the API can be argued to be an improvement, and a replacement of an old API, then I think it is fine. It would work like this: [19:05] (back) [19:06] ideally, new API would subsume old API [19:06] LP would only use new API [19:06] the new API would be exported in webservice as devel [19:06] and the old API would not be exported [19:07] However, it sounds like the planned change does not really warrant a change from the perspective of LP [19:07] it's webservice-specific [19:07] ...thinking about pattern for a sec... [19:08] well, there is a pattern, right? [19:08] and that's the API change you are talking about [19:08] if you are creating a new structural subscription [19:09] then send the right status [19:09] the pattern is this: I want to ensure that one object exists (the subscription) so I can add another object to it (the filter), but I really don't care about the container itself and in fact want a reference to the second object (the filter) [19:09] if it already existed, then send the right status [19:09] well, if you had the status [19:09] hmm, maybe I really want a "create a filter (and the subscription if it doesn't exist)" function [19:10] the thing is, if I had the status I wouldn't have any idea where the "parent" subscripton lives; I'd have to send a seperate request for that (or smuggle it which from a design standpoint is the same thing) [19:11] perhaps we should switch to voice channels [19:11] then you could say "make the structural subscription". Reply says "yeah I made it" or "it was already there". If "I made it" then use the first filter. If "it was already there" then make a filter. BTW, this must be for the adding story, not the editing story, right? [19:11] ok [19:11] I'll prepare to discuss this further. [19:11] though I have screaming children in the vicinity [19:11] :-) ok [19:11] let's Skype [19:13] k [20:25] gary_poster: here's my draft for Danilo: https://pastebin.canonical.com/44632/ [20:26] ack with you in a sec [20:30] benji, he will want to know what branch to get, to start with [20:30] ah, good call [20:32] If it were I, I also get confused on how to find/build the JS (assuming it is in a separate file). I'd like to know where to find it in the tree, and if I have to do anything build-wise for the changes to be seen [20:33] trivial typo: Unsubscriobe [20:33] For the unsubscribe link, I'd want to know what the heck to call--I'd have no clue [20:34] I don't know if he is as clueless as I in regards to our JS setup [20:34] IOW, does the task include writing a server side method that does what we need, and then exposing it? [20:34] Or does something already exist? [20:35] If the first, I'd need direction on how to do it, though there's a good chance he wouldn't. [20:35] If the second, tell me/him what it is :-) [20:35] benji ^^ [20:37] k, working on a revision [20:41] lesson of the day: if things happen via animation in JS you've got to wait in the test or they won't appear as modified. [20:41] duh [20:45] and I assume makes for slow tests too [20:49] :-) [21:42] bac, sorry :-P but I have a branch for you to look at. [21:42] benji, this is the branch that adds the equivalent "edit" page to the "unsubscribe in anger" page you have been working on. After this I'll just need to do the cargo culting. [21:42] https://code.launchpad.net/~gary/launchpad/add-target-subscription-page/+merge/53095 [21:42] relatively small at least [21:42] gary_poster: i was hoping to sneak by... [21:42] :-) sorry [21:42] * bac looks [21:43] gary_poster: cool [21:45] bac, benji, is it alright to merge devel into ~yellow/launchpad/accordionoverlay/ every now and then? [21:45] gary_poster: yes. now is a very good time as i think everything that is implemented is working [21:46] +1 [21:46] ok cool, I'll do it now, and then again hopefully once this branch lands [21:47] gary_poster: after Ash Wednesday you should be in the habit of writing the new year. s/2010/2011 [21:47] lol [21:47] sorry [21:48] bac, benji, what should I do after a merge to make sure everything is OK? start it up and go to the two respective pages and make sure they don't seem to fall over too obviously? [21:49] gary_poster: that'll work. you could also try registry/javascript/tests/test_structural_subscriptions.html [21:49] yep [21:49] ok cool thanks [21:49] remember you have to have launchpad.Edit ATM to see the link [21:50] so mark@example.com:test for firefox project [21:50] right, thank you [21:51] huh [21:52] someone lost some important changes to lib/lp/bugs/model/structuralsubscription.py [21:52] won't start [21:52] gary_poster: what does this ProxyFactory do? [21:52] not sure i've encountered it before [21:52] uh oh [21:53] bac, yeah, I want to advertise it as an alternate approach to utilities [21:53] It wraps the function in a proxy [21:53] which means that everything you get out of it is proxied [21:53] so if you have a function that anyone can call [21:53] but the results should be protected [21:54] then this is a simple pattern that does not require the overhead of our utilities [21:54] so it is wrapped with the normal security proxy? [21:54] (nor does it require overloading our already method-heavy model objects) [21:54] exactly [21:54] hmm, i'm confused as to what the old way would've looked like [21:55] did it just happen automagically? [21:55] You would have had to put it on a proxied utility or on a model object [21:55] functions would not be safe [21:55] because their output would not be proxied [21:56] ok, so none of the old school wiring has been done for this model class? [21:56] no, it has [21:56] if I understand you [21:56] I could move this to the model [21:56] and remove ProxyFactory [21:56] (and I will if you want) [21:56] and it would work fine [21:57] ah, this is a function not a method [21:57] right [21:57] that's the difference i was missing [21:57] but then I'd be adding a method to every bug target in the system [21:57] no, this approach looks fine [21:57] gotcha [21:57] cool [21:59] I'm not sure what to do about the missing changes from devel in accordionoverlay [22:00] ...I could try to find the diff between accordionoverlay and devel and go through them one by one and try to figure out what should really be there... [22:00] which sounds annoying and error-prone [22:00] but I'm honestly not sure what else I can do [22:00] OMG iPads on sale. BRB [22:00] :-) [22:00] gary_poster: do you think they were lost in my merge last night? [22:01] They were lost in some merge somewhere. I could revert and try merging devel back in? [22:01] but then how do we get back to where we are now? [22:02] * gary_poster laughs out loud at "Look its the lovable non-pedantic me." [22:02] what if you undid what you just merged [22:02] merge in devel [22:02] but that's what I did [22:02] well [22:02] I pulled in devel [22:02] and then merge in yellow-accordion paying special attention to that file [22:02] and I pulled in accordionoverlay [22:02] same diff [22:02] oh [22:03] is a pull like a commit. can you undo it? [22:03] not AFAIK [22:03] does it show up in bzr log? [22:03] but I check out the branch at a revision [22:03] np [22:03] no [22:03] pull means that my branch is identical in all ways to the ~yellow branch [22:04] remind me what our importer sorter is again, pls? [22:04] so you can undo the pull from yellow via revert or checkout [22:04] ok good idea [22:04] I'll give it a whirl [22:04] format-imports [22:05] ack thank you [22:05] but i'm concerned b/c our work in yellow is now bad [22:05] yeah, I'm not sure how things are starting for you guys [22:05] i haven't run it [22:05] just run test [22:05] s [22:06] you don't need to run it to do that? [22:06] no [22:06] just load the html file in a browser [22:06] it just exercises the JS [22:07] anything that would've been pulled from the server has to be provided in LP.cache, etc [22:07] I don't really understand which html file it is, but I won't worry you with it. I'll try to get this sorted out in the branch after I have gotten an ec2 land going with the branch reviewed (thank you, by the way) [22:08] yes, my branch is broken too [22:08] ack [22:10] gary_poster: what file do you think was affected? [22:11] lib/lp/bugs/model/structuralsubscription.py for one, at least [22:12] gary_poster: this is what happened to that file during the merge i did [22:12] http://pastebin.ubuntu.com/579035 [22:13] yeah, that's in reverse [22:13] (at least) [22:14] reverse? [22:14] It should add get_structural_subscribers [22:14] the paste seems to reflect the current state of the file, broken though it is [22:14] and remove get_structural_subscribers_for_bugtasks [22:15] and so on [22:15] ugh [22:25] gary_poster: i'm trying to revert to the pre-merge version of model/structural_subscribers.py and bugtask.py [22:26] bac, me too, but from the direction you suggested (reverting back to pre-problem-merge, merging devel, and then trying to reapply the non-problematic subsequent merges) [22:26] I think I missed something :-/ [22:27] i'm unclear how those changes got into the accordion branch in the first place [22:27] *or*, bac, "Merge from yellow. Many conflicts. Beware." is the merge that did the wrong thing [22:27] yes [22:27] (not merge from devel) [22:28] so I think yellow was the problem, not anything you did [22:28] well i guess i should've aborted when it looked funky [22:28] but i think there was a lot of valid funky stuff that had to be dealt with eventually [22:29] benji, it looks possible that you merged devel into yellow in an odd way, though that might not be true either. Does that ring any bells? [22:30] gary_poster: my server is up and running [22:30] bac, yay [22:30] gary_poster: why don't you stop what you're doing and undo the pull from yellow [22:30] undo the pull from yellow...I already did that by reverting? [22:30] i can push this new version and hopefully there aren't other things lurking in there [22:30] ok [22:31] bac, let me give you a test run to try first. one sec [22:31] ok [22:31] gary_poster: i was just proposing you can put your branch back to the pre-yellow catastrophe and then merge in the newly 'fixed' yellow [22:31] which i have not yet pushed [22:32] gary_poster: alternatively you may want to grab a current copy of yellow and look at the diff from the bad merge and see if there are other red flags [22:32] proposed test: this is bigger than you really need--it takes my machine a minute or two--but it's a pretty decent smoke test of these things [22:32] ./bin/test -vvt test_structuralsubscription [22:32] (I'm afraid that the tests might be hosed too) [22:33] ok [22:33] running [22:33] I'm trying what you are suggesting [22:34] (it took my vm 2 minutes 34.548) [22:35] tests are running, fans are on high [22:35] :-) [22:35] have you seen the chinese knock-off tablets have fans in them? that is not what i want in a tablet... [22:35] heh, no [22:36] my vm kicks your vm's ass [22:36] Ran 170 tests with 0 failures and 0 errors in 1 minutes 4.242 seconds. [22:36] damn, sure does [22:36] so, you think i should push this branch up to yellow? [22:36] is that parallels, or just a beefy computer? [22:36] yeah push away [22:36] VMware [22:36] me too [22:37] what computer is it? [22:37] oh, false alarm. it wasn't finished [22:37] * gary_poster was hoping not to feel the need to upgrade till next macbook pro revision ;-/ [22:37] ah yeah [22:37] Total: 240 tests, 0 failures, 0 errors in 2 minutes 34.548 seconds. [22:39] Total: 236 tests, 0 failures, 0 errors in 4 minutes 42.599 seconds. [22:39] dang, bac, is there a way to tell bzr "no, I don't want you to revert, I want you to just go back to the way things were two revisions ago--just forget it all!" [22:39] wow [22:39] (the four additional tests are the ones you just reviewed, I suspect) [22:40] there must be [22:40] so, damn, your machine is twice as fast as mine? [22:40] ...maybe? [22:40] it's pretty beefy, even for being 1.5 yrs old [22:40] mine is about the same [22:40] hmm [22:41] I've got 8G ram and ssd? [22:42] gary_poster: pushed to bzr+ssh://bazaar.launchpad.net/~yellow/launchpad/accordionoverlay/ [22:42] i've got 4G, SSD and 2.53 GHz core 2 duo [22:42] perhaps i'm starving my VM [22:43] I gave min e 2G [22:43] ugh, mine only has 512 [22:43] i should up that to 1G [22:43] ah-ha! [22:43] yeah, at least, maybe 1.5 [22:43] 2 is probably overkill [22:43] i only have the four [22:44] sure [22:44] anyway, i'm going to step away from the computer now [22:44] sounds good me too :-) [22:44] have a great weekend [22:44] have a good weekend