=== Rinchen` is now known as Rinchen === Ursinha is now known as Ursinha-zzz === salgado-afk is now known as salgado === Ursinha-zzz is now known as Ursinha === salgado is now known as salgado-lunch === salgado-lunch is now known as salgado [18:58] moo [18:59] :-) [18:59] ah what the hey [18:59] #startmeeting [18:59] Welcome to this week's Launchpad development meeting. For the next 45 minutes or so, we'll be coordinating Launchpad development. [18:59] Meeting started at 13:03. The chair is Rinchen. [18:59] Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE] [18:59] cluck [18:59] thunk [18:59] moo [19:00] me [19:00] squeek [19:00] oh yeah [19:00] [TOPIC] Roll Call [19:00] New Topic: Roll Call [19:00] me [19:00] cluck [19:00] me [19:00] me [19:00] oink [19:00] me [19:00] me [19:00] me [19:00] me [19:00] thunk [19:00] me [19:00] the launchpad farm [19:00] baa [19:00] me [19:00] releases team is here [19:00] even though we're excused! [19:00] Translations won't be here [19:01] me [19:01] bjorn and francis are excused [19:01] me [19:01] mthaddon is also excused [19:01] me [19:01] barry, can you report on foundations for me [19:01] jtv and danilo are on a sprint [19:01] Rinchen: sure [19:01] me [19:02] intellectronica, can you check on the bugs team please [19:02] foundations is here too [19:02] rockstar ping? [19:02] leonardr: ping [19:02] me [19:02] ok code is here [19:02] leonardr, meeting? [19:02] me [19:02] me [19:02] cprov: ping [19:02] apart from leonardr, that is. :) [19:02] no we're complete [19:02] foundations is here [19:02] soyuz? [19:02] now [19:02] I saw al-maisan. cprov? bigjools ? [19:02] one missing, Celsooooo? [19:03] code is here [19:03] thanks [19:03] [TOPIC] Agenda [19:03] New Topic: Agenda [19:03] me [19:03] you'll notice that mrevell is no longer reporting on his sections by design [19:03] these will now be brought up on demand [19:03] * Next meeting [19:03] * Actions from last meeting [19:03] * Oops report (matsubara/ursinha) [19:03] * Critical Bugs (Rinchen) [19:03] * Bug tags [19:03] * Operations report (mthaddon/herb/spm) [19:03] * DBA report (stub) [19:03] * Sysadmin requests (Rinchen) [19:04] * New packages required (salgado) [19:04] * user affecting issue (intellectronica) [19:04] [TOPIC] Next meeting [19:04] New Topic: Next meeting [19:04] next week same time [19:04] I won't be here [19:04] k, thanks [19:04] anyone else [19:05] Francis will as well [19:05] [AGREED] same time same place on the 14th. flacoste and matsubara are excused [19:05] AGREED received: same time same place on the 14th. flacoste and matsubara are excused [19:05] [TOPIC] Actions from last meeting [19:05] New Topic: Actions from last meeting [19:05] there are none recorded [19:06] [TOPIC] Oops report (matsubara/ursinha) [19:06] New Topic: Oops report (matsubara/ursinha) [19:06] hi all [19:06] * Ursinha waves [19:06] 5 bugs for today: 174480, 252695, 251569, 255816 and 246591 [19:06] (rockstar, bring your boat - flash floods here today) [19:06] Someone of foundations is needed to take a look at bug 255816. Anyone? [19:06] Launchpad bug 255816 in launchpad "ComponentLookupError accessing /manage" [Undecided,New] https://launchpad.net/bugs/255816 [19:07] two bugs for salgado: bug 252695 and bug 251569, how are these? [19:07] Launchpad bug 252695 in launchpad "+peoplelist taking too long to render and timing out" [Undecided,In progress] https://launchpad.net/bugs/252695 [19:07] Launchpad bug 251569 in launchpad "UnicodeEncodeError when trying to search in launchpad/people/+index" [Undecided,Confirmed] https://launchpad.net/bugs/251569 [19:07] i can look at 255816 [19:07] barry, nice, thanks [19:07] Ursinha, 252695 is on PQM [19:07] Ursinha, didn't have a chance to look at the other [19:08] salgado, when you have the time, please :) [19:08] barry, notice that the fix might be similar to whatever we did to fix bug 54944 [19:08] Launchpad bug 54944 in launchpad "ComponentLookupError accessing ++skin++ page" [Low,Invalid] https://launchpad.net/bugs/54944 [19:08] matsubara: thanks [19:08] ok [19:08] bug 246591, thumper, have you checked this out with mwhudson? [19:08] Ursinha: Bug 246591 on http://launchpad.net/bugs/246591 is private [19:08] grrr [19:09] Ursinha: he hasn't been online since we chatted last night [19:09] thumper, oh [19:09] Ursinha: I'll chase this morning [19:09] thumper, ok, thanks [19:09] the last one [19:09] intellectronica, have news on bug 174480? [19:09] Launchpad bug 174480 in blueprint "Person's +roadmap page contains blueprints they're not assigned to" [Undecided,New] https://launchpad.net/bugs/174480 [19:10] Ursinha: sorry, not yet [19:10] intellectronica, would be appreciated too :) [19:10] [AGREED] barry to look at 255816, salgado has fix for 252695 in PQM, salgado to look at 251569, thumper to poke mwh about 246591, intellectronica to take on 174480. Thanks guys! [19:10] AGREED received: barry to look at 255816, salgado has fix for 252695 in PQM, salgado to look at 251569, thumper to poke mwh about 246591, intellectronica to take on 174480. Thanks guys! [19:10] that's all folks [19:10] thanks! [19:10] thanks all! [19:11] [TOPIC] Critical Bugs (Rinchen) [19:11] New Topic: Critical Bugs (Rinchen) [19:11] [LINK]https://bugs.edge.launchpad.net/launchpad/+bug/251869 [19:11] needs an owner [19:11] [LINK]https://bugs.edge.launchpad.net/malone/+bug/253970 [19:11] Edwin, how is this progessing [19:11] LINK received: https://bugs.edge.launchpad.net/launchpad/+bug/251869 [19:11] LINK received: https://bugs.edge.launchpad.net/malone/+bug/253970 [19:11] and I've already spoken to jtv about [19:11] [LINK] https://bugs.edge.launchpad.net/rosetta/+bug/255758 [19:11] Launchpad bug 251869 in launchpad ""not allowed here" while merging to accounts" [Critical,Confirmed] [19:11] LINK received: https://bugs.edge.launchpad.net/rosetta/+bug/255758 [19:11] Rinchen: Error: This bug is private [19:11] Starting next week, QA will be taking over this section! Yippee :-) [19:11] MootBot: Error: This bug is private [19:11] Rinchen: Error: This bug is private [19:11] MootBot: Error: This bug is private [19:11] EdwinGrubbs, ^^ [19:12] salgado, I know you have a lot on your plate. Is there someone who could look at 251869 though? [19:12] it's marked as CRITICAL [19:12] I'm not so sure it is [19:12] that's exactly what I was going to say [19:12] I don't agree it's critical [19:13] Rinchen: It has already been cherry picked. Sorry I forgot to mark the ticket Fix Released. [19:13] it has prevented a couple users from merging their accounts, and in both cases a LP admin was able to do the merge for them [19:13] EdwinGrubbs, excellent. Please include the RF number in there if it is not already. [19:14] ok salgado I've lowered that one [19:14] ok, that's it from me. [19:14] Anything else before I move on? [19:15] [TOPIC] Bug Tags [19:15] New Topic: Bug Tags [19:15] we have one [19:15] https://help.launchpad.net/TaggingLaunchpadBugs [19:15] two actually [19:15] first up, mrevell - tour tag [19:15] Hello. We have bugs filed against the launchpad-documentation project that cover several things - e.g. user guide, tour, and so on. [19:16] It would be handy to be able to group together anything relating to the tour as we then hand the changes off to a specific developer/outside designer. [19:16] i think the tour should be a product [19:16] +1 [19:16] sinzui, on the tag or the product suggestion? [19:16] intellectronica: Why would a product be more suitable? [19:17] It doesn't have separate source code [19:17] We don't need a tag, the tour is autonomous from launchpad apps [19:17] mrevell: because it's not a subclass of bugs of any one lp product. it's a pretty self contained piece of functionality [19:17] I think mrevell's point is that it already has a product, called launchpad-documentation [19:18] it is /more/ separate than answers or bus [19:18] but there are other items that use that product as well [19:18] that's not the same thing [19:18] and he'd like to have a way of keeping them separate [19:18] is that right mrevell ? [19:18] the tour isn't really documentation, it's more marketing [19:18] and we update and review the tour differently form code [19:18] Yes Rinchen. I'm thinking of also suggesting "inline-help" and "user-guide" tags in the future. [19:18] ok, let's not get ahead of ourselves :-) [19:19] Ideally, where a change to Launchpad code affects what the tour should say, the same branch should update that part of the tour at the same time. [19:19] intellectronica: It's docu,mentation for prospective users :) [19:19] inline-help and user-guide are documentation bugs, i agree [19:19] thumper, do you have any comments? [19:20] about a product for the tour? [19:20] I think we won't have that many bugs on the tour anyway, so that doesn't justify having its own product [19:20] thumper, yes...or the tag. [19:20] I don't think the current lp projects should be projects [19:20] so I'm -1 on a product, +1 on a tag [19:21] I'm +1 on the tag, -1 on the product as well (but I'm biased :-) [19:21] sorry for mixing products and projects there [19:21] mrevell, do we really have a lot of bugs that would require a tag (let alone a product)? [19:21] thumper: i don't look forward to a day when i'll have to dig out the relevant bugs from a long list of all lp bugs [19:21] you didn't include any examples which is why I ask [19:22] intellectronica, so fix the bugs that make tagging unnecessarily difficult :-) [19:22] :) [19:22] +1 mpt [19:22] Rinchen: The tour bugs come when there's a major tour update. So, there were a few bugs after the most recent roll-out - but it is a *few*, ten maybe fifteen at most. [19:22] The longer those bugs go unfixed, the more people are tempted to do silly things like splitting the same bunch of source code into separate "projects" [19:22] Rinchen: But they come at one time. [19:22] I suggest a tag so that it's easy for me to look at what needs fixing on the tour and then I can go to our external designer and get a quote. [19:23] ok [19:24] while i'd prefer a tag, i think that mrevell should ultimately decide on this one, since he's managing this project, and he will benefit (or suffer) from the change the most [19:24] given that the amount of bugs are not very high and it currently fits well within it's existing product, I don't think a new product is the right thing in this particular instance [19:24] I also do not think a tag would be warranted but I have "been there, done that" when dealing with the tour and the provider so I'm +1 on a tag for it's existing product [19:25] intellectronica, well, he did. He wants a tag :-) [19:25] JFDI [19:25] thumper: my thoughts exactly :) [19:25] +1 [19:25] ok. so carried [19:25] thanks all for your input [19:25] [AGREED] tour tag for the launchpad-documentation product approved. mrevell to update the tags page [19:25] AGREED received: tour tag for the launchpad-documentation product approved. mrevell to update the tags page [19:26] ok, for tag #2... [19:26] matsubara, rca [19:26] one of the things we decided to do during the sprint is to have a root cause analysis for critical bugs, and we would use a bug report to hold information about the RCA. so the tag is basically to help us group those together. I'm ok on re-proposing this tag once we have the process in place and a initial RCA bug as an example. [19:27] it's an interesting idea, but can we pick something other than an abbreviation? [19:27] barry: rooted? [19:27] so the team leads spoke about RCAs on last week's call [19:27] and the TL's agreed we should pilot this [19:27] and the QA group is going to do this for Critical bugs (only) [19:27] thumper: sounds like pwnd :) [19:27] thumper: maybe root-cause? [19:28] the process needs to be updated a bit so...stay tuned and we'll have that out to everyone [19:28] Rinchen: I like root-cause better than rca too [19:28] barry, fine by me. [19:28] thumper: Yeah, I guess Root Cause Analysis has a different flavour in some dialects. [19:28] abentley: :p [19:28] Any objections? [19:28] ok. thanks [19:28] Rinchen: only to rca, not the concept [19:29] [AGREED] root-cause tag approved. matsubara to update the tags page. [19:29] AGREED received: root-cause tag approved. matsubara to update the tags page. [19:29] [TOPIC] Operations report (mthaddon/herb/spm) [19:29] New Topic: Operations report (mthaddon/herb/spm) [19:30] * Rinchen pokes herb [19:30] ok [19:30] well [19:30] we'll move along then [19:31] [TOPIC] DBA report (stub) [19:31] New Topic: DBA report (stub) [19:31] The trunk will be open for database landings tomorrow, and the remaining db patch reviews done assuming this conjunctivitis doesn't get bad. [19:31] One landing will be the branch that gives us master and slave stores to play with. [19:31] You can explicitly use the slave store to speed things up when your code doesn't need to write to the db and doesn't mind if the data is slightly lagging. I'm sure we can all think of many examples that will benefit from using this. [19:31] You can explicitly use the master store when you need to make modifications or the data absolutely has to be up to date. [19:31] Existing code all uses the default store, which is set by the publisher based on the type of request - read only requests will get the slave store as their default, which should offload at least 30% of our load to the replica databases (when they are live). [19:31] oot. [19:32] This is great news stub [19:32] any questions for stub? [19:32] stub: what's the name of the slave store? [19:32] stub: any idea what the delay will be like getting updates from the master to the slave(s)? [19:32] getUtility(IStoreSelector).get(LPMAIN_STORE, SLAVE_FLAVOR) [19:32] stub: thx [19:33] thumper: 2 seconds to minutes - we won't know until we see it under real load. [19:33] * thumper nods [19:33] (which we will do before switching the load balancing on) [19:34] stub, running this on demo or staging ahead of time and asking the lp community to test this would be a brilliant idea [19:34] * thumper wonders about post redirects [19:34] Yes, but that still isn't real load. It is a hint, but not a true picture. [19:34] if we have a post that goes to writable store, which does a redirect post saving to a get, will that go to a copy that doesn't have the update? [19:34] stub, does the master/slave negotiation for requests know about @safeget? [19:34] thumper: The current load balancing implementation will keep connections using the master store for 5 minutes after a POST request [19:35] cool [19:35] sinzui: No, because I don't know about it either. [19:35] any more questions for stub? [19:36] sinzui: There is at least one hole in the algo at the moment, so it wouldn't work if we switched it on today (webservice requests all need the master at the moment). This branch is landing the infrastructure though, and enough for testing on demo and staging. [19:37] sinzui: @safeget Sounds like something else the load balancing needs to be aware of as well. [19:37] I meant @safe_action that we use with get requests. [19:38] I was wondering if those submits will be using master when I think they should always use the slave [19:38] sinzui: It depends if we can make an inteligent decision that early in the publication. [19:39] thanks stub. I'm going to move on.... [19:39] in the interest of time [19:39] [TOPIC] Sysadmin requests (Rinchen) [19:39] Is anyone blocked on an RT or have any that are becoming urgent? [19:39] New Topic: Sysadmin requests (Rinchen) [19:39] Rinchen: there is one [19:39] Rinchen: but I don't know the number [19:39] Rinchen: I can't remember the numbers right now but I have a couple for private PPAs [19:39] last week it was 31340, 31296, and 31389 [19:40] Rinchen: it was about moving a staging code import box to production environment [19:40] ok, if you guys could email those to me please I'll see what I can do [19:40] * thumper nods [19:40] sprinting this week so it's been rather hard for me to chase those [19:40] thanks [19:40] [TOPIC] New packages required (salgado) [19:40] New Topic: New packages required (salgado) [19:41] anything for me this week? [19:41] ok, thanks salgado [19:41] so, let's slow things down a little ;-) [19:41] [TOPIC] user affecting issue (intellectronica) [19:41] New Topic: user affecting issue (intellectronica) [19:42] * Rinchen pokes intellectronica [19:42] in discussions with the ubuntu community, it has come to my attention that one issue that makes life very difficult for them, is launchpad being slower than they think is usable [19:42] ouch [19:43] it occured to me, that we often don't know that pages become unusably slow until they start timing out [19:43] we here this from folks in China as well. We have experimented with non-ssl connections but it has not improved anything greatly [19:43] (or until users report bugs) [19:43] i think it's db queries in most cases, not the transport [19:44] We are still chasing hard timeouts. Ideally these would be 0 and we are chasing soft timeouts instead. I think many of us tend to think of soft timeouts as normal or maybe early warnings rather than problems that need fixing. [19:44] so i have no idea how to tackle this, but would like to invite you all to think about this and maybe start a discussion on what we can do to track the speed of requests and improve things before they become serious problems [19:45] yeah, we bring those soft time outs up from time to time, but they are postponed as not yet critical [19:45] I know on the code side, a usability point is the number of clicks / edits needed [19:45] so it is more of a workflow thing [19:45] rather than a webapp speed thing [19:45] matsubara: yeah, we can think of those as usability issues, rather than critical bugs [19:45] thumper: no, i think they are talking about page load times, not interaction [19:46] intellectronica: oh, ok [19:46] thumper: Rationally, yes. Emotionally, high latency feels depressing. [19:46] I have read that people who complain about slow page load times think that a site has become much faster when the design has improved but the speed has not [19:46] * thumper is used to slowish pages from NZ [19:47] translations were hoping for AJAX to make it's page feel faster. [19:47] I suspect slow pages are those bugs that will never be looked at given our current priorities. Maybe now 2.0 is out we can look at polishing what we have over driving new features? [19:47] intellectronica, there was a little discussion about pulling the page times from the Apache logs. That could give you some hard data. [19:47] mpt: well, they were talking about this yesterday quite a lot, so obviously this hasn't affected their perception :) [19:47] obviously what hasn't? [19:47] mars: that, i think, is a really good thing to do. especially if it's done periodically and graphed [19:48] mpt: obviously the new design hasn't changed the user's perception of speed [19:48] the problem with load times it that it doesn't account for delay incurred over the wire. [19:48] pages load for me in the USA about 10 times slower than in London [19:48] intellectronica, I wouldn't expect it to, the 2.0 changes are tiny usability-wise [19:48] Rinchen: sure, but given that there's little we can do about the transport, why worry about it? [19:48] yep. I don't remember if there is a way to pull the full page load time though - not just the HTML, but scripts, images, etc. in aggregate. [19:49] intellectronica, because I think a good portion of the issue is geographically induced [19:49] mpt: indeed. and i agree that in-page interaction would improve things /a lot/ [19:49] we still serve the same amount, but depending on where you are, it may be fast (London) or slow (China) [19:49] Rinchen: so maybe we should aim at researching that too? [19:49] intellectronica, btw, response times could also become a big issue when we add more AJAX. [19:50] mars: how so? [19:50] I've had some initial conversations with upper management about that in fact. But yes, we should definitely look into ways of improving that [19:50] sure, it's AJAX, it's snappy, but that doesn't help if the XHR takes 1000ms to run :( [19:50] mars, ajax will reduce the amount of unnecessary queries you do. I do agree slow ajax is even worst [19:50] (and hi everyone) [19:50] mars: well, you won't be waiting on the entire page, as you do now [19:51] intellectronica, yes, true [19:51] My advice at the moment is that everyone here consider this topic for a bit and bring up ideas to your team leads (and also intellectronica). [19:52] Some of our pages carry a lot of data which can cause a lot of queries. When optimising for fewer queries it's still easy to not improve the speed because the code becomes the slow part, so we need to be mindful of both code speed and number of queries. [19:52] We have a TL meeting coming up in a few weeks. It would be an interesting time to discuss it [19:52] It's worse when an AJAX request goes slowly because you can't easily reload the page to start again. [19:52] intellectronica: Sometimes JavaScript itself can take a long time to load. [19:53] abentley: you mean js runtime? that depends on the client, but we should never reach the point where this can be an issue [19:53] thank intellectronica for bringing this up. I happen to think it's very important [19:53] intellectronica: No, I mean the JavaScript code for a particular web site. [19:54] I'd like to table the JS discussions until later. Anything else for intellectronica before we close? [19:54] ok then. [19:54] Thank you all for attending this week's Launchpad Developer Meeting. See the channel topic for the location of the logs. [19:54] #endmeeting [19:54] Meeting finished at 13:58. [19:55] thanks Rinchen [19:55] Cheerio everyone. [19:55] thanks Rinchen [19:55] ta [19:55] bye! === cprov is now known as cprov-afk === salgado is now known as salgado-afk