| danilos | grepping for "subscribers" doesn't work that well when a class uses "subcriber" in the name instead :) | 12:28 |
|---|---|---|
| gary_poster | danilos, I approved your PDR goals | 13:23 |
| danilos | gary_poster, cool, thanks, is there any action required on my part? | 13:23 |
| danilos | I guess I'll just go and check | 13:23 |
| gary_poster | danilos, yeah, I think there is, but could be wrong | 13:23 |
| danilos | gary_poster, yep, I needed to counter-sign it (I added a comment that "I agree with your agreement with my objectives", for clarification ;)) | 13:24 |
| gary_poster | lol, thank you so much | 13:24 |
| danilos | gary_poster, btw, I have one question for the "other subscribers" list: for the directly subscribed persons/teams, do we check their mute status as well? | 13:25 |
| danilos | gary_poster, or is that assumed to be appropriately set with API return values? | 13:25 |
| gary_poster | danilos, they are currently set via API. I'm happy with you leaving that as is, or adjusting it to the pipeline approach. I'd be tempted to put off the pipeline approach to the end, in case it is unpleasant (with many pieces of code needing to be changed) but perhaps that is unnecessarily pessimistic | 13:27 |
| gary_poster | bac (are you feeling better?) benji danilos gmb, kanban now, call in less than 3 | 13:27 |
| gary_poster | ish | 13:27 |
| gary_poster | :-P | 13:27 |
| danilos | gary_poster, right, sounds good enough for me | 13:28 |
| gary_poster | cool thanks danilos | 13:28 |
| bac | gary_poster: yes-ish | 13:30 |
| gary_poster | bac, :-) ok, well glad you are better | 13:30 |
| gary_poster | #launchpad no longer has a /topic | 13:30 |
| bac | i see a topic | 13:31 |
| bac | are using linkinus? it has been screwy for me wrt topics | 13:31 |
| gary_poster | yeah, ok | 13:31 |
| gary_poster | Brad Friday, Benji Monday, Danilo Wednesday, Graham Tuesday, Gary Thursday | 13:40 |
| gary_poster | Gary will adjust IRC resp on wiki | 13:41 |
| gary_poster | Danilo/Graham: something Benji 3-4: Brad 4-5: Gary 11-12 | 13:44 |
| gary_poster | Launchpad Translators Group for Translation questions | 13:45 |
| danilos | gary_poster, that's a bit too broad, so to simplify, punt it to me and I'll reassign appropriately | 13:47 |
| gary_poster | Launchpad Translation Coordinators does that (David Planella) | 13:49 |
| bac | gary_poster: added sick leave to canonicaladmin | 13:50 |
| gary_poster | thanks bac, will go approve | 13:50 |
| gary_poster | approve | 13:51 |
| gary_poster | d | 13:51 |
| benji | gary_poster, a drive by: the more I think about it the more I wonder if we should try using an asynchronous transport for the services balkanization (and since we already have rabbitmq running it would be a good place to start) | 14:09 |
| gary_poster | benji, poolie said something similar, but I don't yet understand how async helps for building a page. ISTM you want results ASAP, and you don't want the overhead of async (rabbitMQ is lightweight compared to, say, zc.async, but heavyweight compared to not having async around at all, or zeroMQ would not have arisen AFAIK), | 14:13 |
| gary_poster | and in fact async doesn't buy you anything (AFAIK) that simple threaded requests to the publishers doesn't provide. Is there a quick way to explain what you mean? | 14:13 |
| danilos | haha, "balkanization" :) I'm rather sad that has become a "proper" word :/ | 14:14 |
| gary_poster | :-) :-/ | 14:15 |
| benji | I'm envisioning a scatter-gather type situation. Simple example: say there are parts of the page we can do without knowing who the user is and parts that we have to know, at the start of a request we could fire off one or more async requests to render the parts of the page that don't need user data, then fire off a synchronous (or async with a subscription to the response, or whatever) request to look up the user from their | 14:16 |
| danilos | gary_poster, as for async stuff, I am kinda with benji: there is stuff we know we can't do in whatever the time might be allotted for page rendering | 14:16 |
| benji | danilos: something you should know by now, just because I use it doens't mean it's proper ;) | 14:17 |
| danilos | gary_poster, and I imagine more things that might come up in the future, where we'd want to offer live status updates | 14:17 |
| danilos | benji, heh, actually, I've seen it used on BBC's web site, and defined in dictionaries, but never before seen anyone use it in a real non-political statement | 14:18 |
| gary_poster | benji: maybe. The same as you describe could be handled with other approaches, like the one I described, with lighter weight. Since we have to write integration for rabbitMQ and we are talking about simple thread use (the sort that Twisted can provide with deferred abstraction, even) for my alternate approach, I am not convinced it is a win. Maybe I'm wrong. | 14:22 |
| gary_poster | For what danilos says, with stuff we know we can't do in the time allotted for page rendering, sure, but that's a different story. A big part of instituting a constrained time for page rendering is to give a quick response time to the user. If you need to start something up separately, great, but you'll have to deliver it separately (e.g. with AJAX). I'm a big fan of async for things like that. | 14:22 |
| gary_poster | In general, though, I'm interested in JS/AJAX for page assembly | 14:23 |
| benji | gary_poster: can you quickly summarize the approach you described? | 14:23 |
| benji | I may have confused things by introducing page assembly. My understanding of Robert's intention is to break LP up into "services" that can be deployed independently. | 14:24 |
| gary_poster | ah ok | 14:24 |
| gary_poster | I'm in favor of rabbit MQ as being one of the tools we use for that purpose | 14:24 |
| gary_poster | But page assembly itself on the server is less convincing to me as a specific time when RabbitMQ/async is a good solution | 14:25 |
| gary_poster | summary: | 14:25 |
| benji | right, pretend my example was about API calls to fetch data, not page fragments | 14:26 |
| gary_poster | If we are not waiting to render a page until we get that data back, then I am +1 on async/RabbitMQ without further discussion | 14:27 |
| gary_poster | Let's say this is a Twisted app assembling the services. A request comes in. You immediately make threaded calls that talk to services to get pre-auth replies. Then you do a call to become authenticated; when that is done, you make more threaded calls to get post-auth replies. When all services have returned, or something has timed out, we assemble the page and send it back. | 14:27 |
| gary_poster | You could even do interesting things like "the reply isn't back yet; we'll stick in an AJAX thing to load this part of the page after the browser got it, using the results we've been working on already but that aren't ready yet" | 14:28 |
| gary_poster | You could use RabbitMQ for something like that, but it is heavyweight...*unless* you need coordinated transactionality. | 14:29 |
| gary_poster | Which is another thing I haven't seen discussed, actually. | 14:29 |
| benji | I'd worry about the "threaded" bit (and why would you need threads with Twisted?). | 14:31 |
| benji | otherwise that sounds like what I had in mind | 14:31 |
| gary_poster | (threads are reasonable tools if used in simple ways, and Twisted supplies the tools to use them.) But yeah, actually for network activity, you wouldn't need them with Twisted. You'd only need it if you needed to talk to something like a DB call (like a graph DB) that started up a separate process. So yeah, when you rip out the threads, that's even lighter weight. | 14:33 |
| benji | so, I'll mention one more thing and stop :) if we have a service for, say, managing bug notifications then we should build things so we can run several and load-balance/fail-over between them; that would be a good argument for using HTTP as the transport as we already have/know the tools to do that; plus we could easily add caching | 14:37 |
| gary_poster | Unless I misunderstand :-P I think I agree completely. I think that's the same kind of thinking that makes me want us to use REST-style communications. Does that sound like I'm on the right track? | 14:39 |
| benji | it does; I guess I should go read Robert's write up of this now that I've decided how we should implement it all ;) | 14:41 |
| gary_poster | :-) | 15:01 |
| gary_poster | ...and it's my CHR time! | 16:00 |
| bac | gmb: is my re-use of bug 777789 for the branch you just reviewed going to cause deployment problems? the first 'qa-bad' branch and its rollback haven't landed yet. hmmm. | 16:37 |
| _mup_ | Bug #777789: "Other subscriptions" description of direct team subscription makes no sense <qa-bad> <story-better-bug-notification> <Launchpad itself:Fix Committed by bac> < https://launchpad.net/bugs/777789 > | 16:37 |
| bac | s/landed/been deployed | 16:37 |
| gmb | bac: I don't know. I don't *think* so, but I usually find it better to file another bug and let qa-tagger track things there. | 16:38 |
| gmb | Because I've seen the qa-tagger do odd things to re-used bugs in the past. | 16:38 |
| bac | yeah, hindsight | 16:38 |
| bac | i guess i'll find out... | 16:39 |
| gmb | :) | 16:39 |
| * gary_poster stops doing CHR, 1:35 later | 17:35 | |
| gary_poster | I left a few projects for the next person | 17:35 |
| gary_poster | Hopefully this will go faster once we all get in the rhythm :-) | 17:36 |
| === Ursinha is now known as Ursinha-lunch | ||
| gary_poster | ...library/lunch... | 18:17 |
| * benji starts CHRapalooza | 20:01 | |
| * benji realizes he's an hour early bug goes ahead anyway. | 20:02 | |
| bac | benji: why do you say you're an hour early? i thought you had 3pm and i had 4pm | 20:12 |
| benji | bac: oh, you're right, I did my UTC math wrong | 20:12 |
| benji | Does anyone know if it's possible to delete a project? I have a question in which a user asks that their recently created project be deleted. The admin page lets me deactivate it. | 20:34 |
| benji | I assume that since LP tells me that the person that asked the question and the person that registered the project are the same, that it's safe to fulfill the request (i.e., there's no impersonation going on). | 20:35 |
| gary_poster | benji, yeah, delete request from user -> deactivate for us | 20:38 |
| gary_poster | and yes, I trust LP in that kind of way too | 20:38 |
| benji | gary_poster: thanks! | 20:38 |
| gary_poster | np | 20:38 |
| benji | done with CHR; other than having no idea what a couple of the ~registry tasks were talking about, that wasn't too bad | 20:55 |
| gary_poster | yeah, I had no idea what the ~registry was either :-P | 20:56 |
| gary_poster | I suppose I should fix that | 20:56 |
| gary_poster | I'll see if flacoste knows, since I'm about to talk to him anyway | 20:56 |
| gary_poster | oh. you probably saw this. This explains most or all of it to me | 20:57 |
| gary_poster | https://dev.launchpad.net/Registry/RegistryReview | 20:57 |
| benji | gary_poster: well, that page is part of the problem: the "Decline invitations to join a team." bit makes no sense; copy paste error perhaps? and the "Remove owned teams" section asking me to "investigate those you do not understand" isn't very helpful | 21:04 |
| benji | gary_poster: should we use bug heat to guide us in choosing bugs to work on? If so, I should look at https://bugs.launchpad.net/launchpad/+bug/740208 | 21:16 |
| gary_poster | benji, sorry on call since 4 will ping when off | 21:16 |
| benji | sure | 21:16 |
| === Ursinha-lunch is now known as Ursinha | ||
| gary_poster | benji, hi, reading...yeah, Francis said that the page maybe has had too many cooks lately. I'm supposed to work with Curtis to make sure that we understand it. It takes Curtis 15 min/day to do that work. He's an expert, so if it takes us 45 minutes, aggregated across all of us, over the day, that's probably not too bad, but we do all need to understand it. | 21:46 |
| gary_poster | benji: use bug heat: naah | 21:46 |
| gary_poster | I mean, if you want to | 21:46 |
| gary_poster | but the main goal should be speed | 21:46 |
| gary_poster | Secondary goal should be learning | 21:47 |
| gary_poster | Additional goals for you to determine :-) | 21:47 |
| gary_poster | but that bug would certainly be a nice one to fix, sure :-) | 21:47 |
| bac | hi benji -- did you do the 'project review' part? i'm just asking b/c i want to make sure i'm not missing anything. there are several projects there that should've been approved that pre-dated your shift. | 22:03 |
| benji | bac: I did, but it ended up being a no op (as far as I can tell) because all the projects had whiteboard entries that said things like "emailed them about our license policy" | 22:04 |
| bac | benji: yeah, but i saw about 5-6 that had GPL licenses that needed to be marked as approved | 22:04 |
| benji | I admit that I don't have a good feeling about my understanding of that page though | 22:04 |
| bac | benji: just want to ensure we're on the same card | 22:04 |
| bac | so, as it is now, there are only projects with "I don't know" | 22:05 |
| benji | I assumed (bad me) that the page was in reverse chronological order, so if the top few were handled, then they all must be | 22:05 |
| bac | benji: no, it is oldest at top. :( | 22:05 |
| benji | pfft, that's helpful | 22:05 |
| bac | hey at least it is all ajaxy now | 22:05 |
| benji | sounds like we need a bug about that with the "chr" tag | 22:05 |
| bac | much easier to deal with | 22:05 |
| * bac eods. bye. | 22:09 | |
| gary_poster | bye | 22:31 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!