[11:51] hi how we cancel an attachement before save change to s"end only message ? [11:54] ther no way must i post bug about launchpad under launchpad ? [11:55] benje: this is the meeting channel, please ask in #launchpad [11:55] ok sorry [11:55] that's ok === mrevell is now known as mrevell-lunch === salgado-afk is now known as salgado === salgado is now known as salgado-lunch === salgado-lunch is now known as salgado === mrevell is now known as mrevell-dinner === jt1 is now known as jtv === mrevell-dinner is now known as mrevell [19:00] #startmeeting [19:00] Welcome to this week's Launchpad development meeting. For the next 45 minutes or so, we'll be coordinating Launchpad development. [19:00] Meeting started at 13:05. The chair is Rinchen. [19:00] Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE] [19:00] [TOPIC] Roll Call [19:00] New Topic: Roll Call [19:00] oink [19:00] me! [19:00] moo [19:00] me [19:00] me [19:00] me [19:00] me [19:00] me [19:00] me [19:00] me [19:00] me! [19:00] me [19:00] me [19:00] me [19:01] me [19:01] mrevell? [19:01] me [19:01] me [19:01] sorry [19:01] me [19:01] welcome beuno! [19:01] me [19:01] apologies from diogo [19:01] me [19:01] Releases Team is here [19:01] bugs team is here [19:01] (will be seeing diogo later today) [19:01] EdwinGrubbs: ping [19:02] mars: ping [19:02] Rinchen: flacoste will not be here [19:02] thanks barry [19:02] bugs team here? foundations? [19:02] leonardr: ping [19:03] translations? [19:03] soyuz? [19:03] Rinchen: danilos sends apologies [19:03] mr [19:03] me [19:03] thanks jtv - translations here [19:03] Rinchen: seems like a few of our guys are missing [19:03] me [19:03] Rinchen: cprov @ debconf, al-maisan is MIA === thumper_laptop is now known as thumper [19:03] ok, code is here [19:03] soyuz ok. [19:04] alrighty then [19:04] [TOPIC] Agenda [19:04] New Topic: Agenda [19:04] * Next meeting [19:04] * Actions from last meeting [19:04] * Oops report (matsubara/ursinha) [19:04] * Critical Bugs (Rinchen) [19:04] * Bug tags [19:04] * Operations report (mthaddon/herb/spm) [19:04] * DBA report (stub) [19:04] * Sysadmin requests (Rinchen) [19:04] * New packages required (salgado) [19:04] [TOPIC] Next meeting [19:04] New Topic: Next meeting [19:04] me [19:04] same time next week. Anyone not available? [19:05] I am not available. [19:05] ok, thanks abentley [19:05] Rinchen: i may not be, not sure yet [19:05] barry, ok, update the mtg agenda please when you know [19:05] [TOPIC] Actions from last meeting [19:05] New Topic: Actions from last meeting [19:05] Rinchen: will do [19:06] there were none. [19:06] [TOPIC] Oops report (matsubara/ursinha) [19:06] New Topic: Oops report (matsubara/ursinha) [19:06] * Ursinha waves [19:06] Bugs for today: 252674 and 174480, two timeouts, two for bugs team [19:06] BjornT, did you have the time to look at bug 252674? [19:06] Bug 252674 on http://launchpad.net/bugs/252674 is private [19:06] bugs/+index timeout problem [19:06] Ursinha: 174480 is in pqm [19:07] intellectronica, cool, thanks [19:07] Ursinha: sorry, no. is it still happening? [19:07] BjornT_, yes [19:07] Ursinha: can you please add some recent oops to the bug report? [19:08] BjornT_, ok, i'll append some more [19:08] thanks [19:08] np [19:08] that's all for now, thanks guys [19:08] Ursinha, how did the oopses look yesterday given the high DB load? [19:08] thanks Ursinha [19:09] mthaddon, pretty much the same [19:09] Ursinha, interesting - ok, thx [19:09] mthaddon, np [19:09] [TOPIC] Critical Bugs [19:09] New Topic: Critical Bugs [19:09] Only one critical bug not Fix Commited yet, yay! [19:09] [LINK] https://bugs.edge.launchpad.net/launchpad-bazaar/+bug/255886 [19:09] but it's now playing on pqm, so soon will be Fix Commited, thanks mwhudson [19:09] LINK received: https://bugs.edge.launchpad.net/launchpad-bazaar/+bug/255886 [19:09] Error: This bug is private [19:09] Error: This bug is private [19:10] that's all [19:10] awesome [19:10] thanks Ursinha [19:10] [TOPIC] Bug tags [19:10] New Topic: Bug tags [19:10] we have 2 requests [19:10] (something to mention later, pqm's queue is moving reaaaaally slowly atm) [19:10] https://help.launchpad.net/TaggingLaunchpadBugs [19:10] mwhudson, herb is doing a CP [19:10] mthaddon: i mean more generally [19:10] first one is for jml for the tag of Stacking [19:11] thumper, you have this one? [19:11] me [19:11] mthaddon: it was only 8th in the queue when i submitted ~20 hours ago... [19:11] mwhudson, https://devpad.canonical.com/~joey/pqm.html isn't much slower than normal [19:11] ok, this is to help us identify any bugs to do with the new way we are dealing with branches [19:11] >> we'll do PQM in a sec [19:12] ai, I hate my timezone === kiko-fud is now known as kiko [19:12] I'm +1 on the stacking tag. I can see a need for this. [19:12] that sounds fine [19:12] stacking seems a bit too general, though [19:13] how about branch-stacking? [19:13] that's ok with me [19:13] sounds good [19:13] +1 [19:13] yes, i like that better too [19:13] sounds good, as i'm going to make the same complaint about the next proposed tag :) [19:13] So am I [19:13] And I'm proposing it... [19:13] oh mwhudson ! Hi, didn't see you [19:14] [AGREED] branch-stacking tag approved. mwhudson to update wiki page [19:14] AGREED received: branch-stacking tag approved. mwhudson to update wiki page [19:14] Rinchen: er [19:14] Heh [19:14] Rinchen: it was jml who proposed the tag, but ok [19:14] oops! [19:14] next up, gmb with the upstream tag. gmb can you explain how this is different from bugwatch? [19:14] me [19:14] Right. [19:14] lol [19:14] So, the name is far, far too general and needs to be revised. [19:14] I stand corrected mwhudson [19:14] Skipping past that... [19:15] mwhudson, I'll do it then [19:16] gmb: how about 'upstream-support'? [19:16] This tag would be for organising bugs that relate to our upstream relations work (so maybe upstream-relations would work as a name). The example I've given is of a bug with the upstream report, but I'm intending for it to be used by the community team or anyone who needs us to implement a feature specifically geared towards making our (and by extension Ubuntu's) work with upstream more streamlined. [19:16] intellectronica: Yes, that would work. [19:17] or 'upstream-requirement'. more accurate but less catchy [19:17] can you give some example bugs? [19:17] Let me dig some up. They're all upstream report related ATM. [19:18] bug #255050 on the wiki [19:18] Launchpad bug 255050 in launchpad "Statistical columns on the upstream report should turn green for values of 90% and above" [Medium,Fix committed] https://launchpad.net/bugs/255050 [19:18] bugs 249517 255050 249814 256969 would be examples [19:18] Launchpad bug 249517 in launchpad "The upstream report should be tracking all open tasks" [High,Fix committed] https://launchpad.net/bugs/249517 [19:18] intellectronica, hmmm, upstream-requirement is a bit too general [19:18] gmb, is this simply for the report or plugins as well [19:18] gmb, why not 'ubuntu-upstream-relations' or something like that? [19:18] kiko: well, but this tag is quite general [19:18] kiko: That would work well, yes. [19:19] I mean, actually say what it is [19:19] or upstream-relations-requirement [19:19] something like that [19:19] Rinchen: I'm intending it to be used organisationally for all ubuntu upstream relations work. [19:19] i don't like -relations. nobody outside the project will understand what it's about [19:19] intellectronica, it's okay -- that's why I said ubuntu-relations-requirement [19:19] yeah, that makes sense [19:19] it makes it very obvious that it's a tag to be used by people who know what that means. :) [19:19] kiko, too long. Something shorter? [19:19] Rinchen, why? [19:20] I think long is fine in this case. [19:20] it's a very special tag to be used in a very specific circumstance [19:20] kiko: A relations requirement sounds like I have to take it to dinner before I get to have relations with it. [19:20] so is oops-tools ;-) [19:20] +1 on ubuntu-upstream-relations [19:20] ok, ok, I'll bend [19:20] ubuntu-upstream-relations works for me. [19:20] any objections to the tag or tag name? [19:21] ok then.. [19:21] [AGREED] ubuntu-upstream-relations tag approved. gmb to update the wiki [19:21] AGREED received: ubuntu-upstream-relations tag approved. gmb to update the wiki [19:21] Thanks. [19:21] and in my best Steve Jobs voice... [19:21] there's one more thing [19:22] kiko and I have talked and we would like to do away with the bug tag section of the weekly meeting [19:22] and hold these discussions on the mailing list [19:22] +1 [19:22] +1 [19:22] +1 [19:22] +1 [19:22] any objections would require some rework [19:22] +1 [19:22] +1 meelion [19:22] +1 [19:22] +1 [19:22] +1 [19:22] * Rinchen laughs. [19:22] +1 [19:22] I think that section is so nitpicky even I can't take it much longer [19:22] Ok, I get the hint/ [19:22] and I'm a nitpicker [19:23] at heart [19:23] [AGREED] death to bug tags section. Use the mailing list instead. [19:23] AGREED received: death to bug tags section. Use the mailing list instead. [19:23] [TOPIC] Operations report (mthaddon/herb/spm) [19:23] New Topic: Operations report (mthaddon/herb/spm) [19:23] Late Sunday (2008-08-10) Cherry pick of r6818 to the scripts server. [19:23] Early yesterday (2008-08-13) Cherry picked r6836 to PPA server and FTP master, and r6842 to lpnet* and edge* [19:23] A cherry pick for r6846 and r6850 is in queue right now and will be deployed after the meeting. [19:23] Bug 247227 (App servers dying) continues to be an issue. There have been some updates to the bug and we've been capturing debugging information. But the root cause has not yet been isolated. [19:23] Bug 247227 on http://launchpad.net/bugs/247227 is private [19:23] I'm on holiday on Monday. [19:23] That's it from Tom, Steve and me unless there are any questions. [19:24] I'm still concerned with 247227 [19:24] * herb is too [19:24] what else can we do here to get more information? [19:24] would an strace help? [19:25] kiko ^^ [19:25] kiko's suggestion in the report would help! [19:25] We can trigger it. I think we need someone with the right -fu to trace down the fault point rather than boucing between admins and our suggestions. [19:26] i am (for my sins) reasonably experienced in debugging python with gdb [19:26] thx for volunteering! [19:26] so if we end up in a gdb prompt when i'm around, please bug me [19:26] mwhudson: we have a backtrace that was captured yesterday [19:26] we don't run gdb interactively [19:26] oh [19:27] herb, I think running it interactively would really help [19:27] herb, and, if an actual engineer or I could do the interaction, it would be MUCH better. [19:27] i can give you some more interesting stuff to run non-interactively then :) [19:27] let's talk about it after the meeting [19:27] gdb has a remote debugging thingy doesn't it? [19:27] mwhudson: ok [19:27] I realize I am being a heretic at suggesting that an ENGINEER might actually be able to TOUCH the software he wrote [19:27] but hey, it's august the 14th [19:27] * kiko winks [19:27] kiko: it's not about the software it's about the servers. :) [19:28] Think of the servers! [19:28] herb, I don't know the difference :) [19:28] Thinks of the service. :-D [19:28] stub: hehe [19:28] kiko, that's why herb and I have a job [19:28] kiko: it is the 15th here [19:28] mthaddon, well.. unless you can debug yourself, this is really a suboptimal arrangement for this specific crisis. [19:29] thumper, you live in the future. You are the exception [19:29] I hope mwhudson can help further, but I do think that there is no big deal in having engineers able to access the servers in situations that warrant it. [19:29] kiko, I think we're being pretty accommodating here - I was just meaning we have a job because you don't know the difference between software and servers :) [19:29] and by not allowing this, we're all plastered. [19:29] same team, same side [19:29] fight nice [19:29] :-) [19:30] kiko, I think you're over-estimating that - we're doing everything you ask of us - and thx Rinchen [19:30] thanks mwhudson for volunteering [19:30] * mwhudson goes to find his scripts, which funnily enoiugh are on vostok... [19:30] mthaddon, I disagree vehemently, but it is not to say I don't appreciate your effort [19:30] [ACTION] mwhudson to get with mthaddon to see if we can super-charge gdb to give us better diagnostic info on the staging. [19:30] ACTION received: mwhudson to get with mthaddon to see if we can super-charge gdb to give us better diagnostic info on the staging. [19:31] anything else for the OSAs? [19:31] ok, moving on [19:31] thanks herb and mthaddon [19:32] [TOPIC] DBA report (stub) [19:32] New Topic: DBA report (stub) [19:32] We were getting a high DB load yesterday, apparently from multiple copies of some scripts running. I guess these where old ones before we had decent locking helpers. Load is back to normal now. [19:32] The script we need to run to open Intrepid for translations is increasing load enough to push some of our expensive pages (such as the bugs.launchpad.net front page) over the hard limit, causing timeouts. [19:32] We have a few options to proceed, including trying again with some tweaked tuning settings (may require bouncing PG), making the code that is being unfriendly to other processes more friendly (but slower), or scheduling some downtime while the unfriendly section of code needs to run - we think half an hour including some slack. [19:32] My read-only-launchpad branch is still blocked getting through PQM - no chance to look further today. As far as I have got, it seems that for my branch only in the PQM environment the Librarian reconnection code isn't working, instead causing the Librarian to hang. I'll need to instrament the librarian and run tests or do some manual tests stepping through the librarian code with pdb to get further - yay :-P [19:32] There are still a two post-cuttoff reviews to do - one soyuz and one from Barry that isn't in my wiki queue. The soyuz (lucille) one isn't showing up on the merge status cgi - not sure why (pushed to devpad?). [19:32] stub: crap, i'll put it in the queue right now. apologies [19:32] stub: What's the status of my review? [19:33] stub: the lucille one is just a permission change, not sure why it's not showing up [19:33] That would be the one I didn't see above my queue... [19:34] bigjools: If it is just permissions, I don't need to see it. [19:34] ah ok [19:34] abentley: I do yours too now I see it :) [19:34] stub: Thanks. [19:35] stub, do you need someone to help with the read-only branch? [19:35] And that is my example to kiko on a place we use message_id without storing the message... [19:35] stub, lucille? [19:35] I'll yell for help if I need twisted hand holding [19:35] stub, or.. something else? [19:36] stub, I've had a similar problem with the librarian before in my local tree [19:36] kiko: There are soyuz scripts still connecting as the 'lucille' db user. [19:36] stub, and that's relation to message_id? :) [19:37] kiko: https://devpad.canonical.com/~jamesh/pending-reviews/abentley/launchpad/better-threading/full-diff [19:37] stub, oh, abentley's branch. sorry, you really tricked me there! [19:37] kiko: I just mentioned it in my bug because I was reminded by that branch I was supposed to review. [19:37] I like the funky caps in that patch [19:38] Its 1:40am tomorrow. Its confusing. Deal. [19:38] stub, hmm. wonder why we don't store that message, actually. thumper? [19:38] why should we store the whole email? [19:39] it serves no purpose [19:39] If it is auto generated, there isn't much point. [19:39] it will never be looked at [19:39] * thumper agrees with stub [19:40] anything else for stub before we move on? [19:40] ok, thanks stub [19:40] intellectronica apologises - he's lost his connection and will be back when possible. [19:40] [TOPIC] Sysadmin requests (Rinchen) [19:40] New Topic: Sysadmin requests (Rinchen) [19:40] so I have a question [19:41] for herb and mthaddon [19:41] normally I track rt's in this section [19:41] ask for ones that need some attention [19:41] ? [19:41] Do you guys feel that you could do this section? [19:41] as in, we come to the OSAs with RT prioritization [19:42] and for help in RT scheduling? [19:42] Rinchen, actually, it's very useful to know which RTs you feel need prioritization [19:42] mthaddon, right. Right now I hope on the IS channel and poke elmo [19:42] mthaddon, I'm curious if you think the OSAs would be a better choice. [19:42] so this would be your section and we could poke you [19:42] vs me poking on the IS channel [19:42] it has some drawbacks and some positives. [19:43] Rinchen, it's better to not use us as RT proxies, but to work directly with IS - we can certainly help priortise RTs that need it, but otherwise we end up as middle men which isn't efficient for anyone [19:43] ok, thanks mthaddon [19:43] Is anyone blocked on an RT or have any that are becoming urgent? [19:43] * beuno would like RT 31420 [19:43] Rinchen: the two I emailed you about last week [19:43] ok beuno I'll have a look at it [19:43] thanks Rinchen [19:44] hmm, bigjools. Ok, I'll touch base again with IS on those. [19:44] ta [19:44] Rinchen, is the xlstproc stuff sorted? [19:44] our documentation is/was pretty out of date the last time I looked into it [19:44] AFAIK we're generating the docs manually [19:44] not that I've seen. :-( [19:45] ok, you know about that already [19:45] I'll go through the priority list again today and make sure our tickets are correctly set [19:45] [ACTION] Joey to review RT ticket Priorities in RT to ensure they are accurate. [19:45] ACTION received: Joey to review RT ticket Priorities in RT to ensure they are accurate. [19:46] [TOPIC] New packages required (salgado) [19:46] New Topic: New packages required (salgado) [19:46] anything for me? [19:46] congratulations [19:46] ha ha [19:46] * stub points at the clock [19:46] thanks Rinchen. please move on before kiko remembers of something. ;) [19:47] ok, thanks salgado. I've been pinging folks as RT's come in and ensuring they have submitted bugs for you [19:47] 100% compliance so that was great [19:47] which leads me to one last topic for today that was not on the agenda [19:47] salgado, hmm, I just remembered [19:47] * Rinchen pauses for kiko [19:47] salgado, I should thank you for the quick updates to meta-lp-deps the past week :) [19:47] kiko, you're welcome! [19:48] [TOPIC] Weekly meeting agenda [19:48] New Topic: Weekly meeting agenda [19:48] so... [19:48] kiko and I have chatted briefly [19:49] and we both agree we'd like to make some progressive changes to the agenda of this meeting [19:49] what I'd like to know at this moment is if there are any suggested topics that you feel can be done on email and not during the meeting? [19:49] the topic list again is: [19:49] * Next meeting [19:49] * Actions from last meeting [19:49] * Oops report (matsubara/ursinha) [19:49] * Critical Bugs (Rinchen) [19:49] * Bug tags [19:49] * Operations report (mthaddon/herb/spm) [19:49] * DBA report (stub) [19:49] * Sysadmin requests (Rinchen) [19:49] * New packages required (salgado) [19:49] bug tags is gone [19:50] i guess in a perfect world, the 'report' sections could be done on list and then just talked about in here [19:50] I'm going to combine oops and critical bugs into one section [19:50] Rinchen, nice, i was going to suggest that [19:50] mwhudson, good idea [19:50] but that may require unlikely amounts of discipline [19:51] it is nice though to have the reports during this meeting [19:51] Shouldn't "New packages required" be handled elsewhere? [19:51] sinzui, I am inclined to agree [19:51] sinzui, the only reason we do it here is to remind people [19:51] yep, new packages could go offline [19:51] yeah, and pasting in the reports to the channel doesn't take long at all [19:51] in case they have forgotten [19:51] the problem is that they have been forgotten a lot in the past, so we tried to use this to discipline ourselves [19:51] I also think that RT's can be done offline. People can just ping me. [19:51] if that need is no longer served, then let's evict it [19:52] Do we have any criteria for things that should be discussed interactively, vs things that should be discussed in a ML? [19:52] kiko, it's been good this past week but that's the first time I recall it being done consistently. [19:52] abentley, that's the real crux there. [19:52] abentley, things discussed interactively should be relevant to most of the audience here [19:52] abentley, so changes in policy, new experiments being run, interesting anecdotes you found during the week, code bloopers and gotchas, etc [19:53] abentley, there's a discipline side to this meeting that I generally would like to minimize -- this is the new packages stuff, the OOPS crapola, etc [19:53] In truth, it's possible to take the entire existing agenda and do it via the mailing list. [19:53] and keep this meeting for special topics of interest. [19:54] at least, that is my feeling at the moment [19:54] well.. I think we don't need to trash all of it, but I agree we can minimize the filler [19:54] kiko: What you're saying sounds to me like a series of presentations-- very different from what we have now, but potentially quite useful. [19:55] Another option might be to have each team summarize their past week? [19:55] thumper, BjornT_, jtv?, anyone else with opinions? [19:55] abentley, I would like our team to drive the meeting more [19:55] abentley, I don't like the idea of status reports as much as I like the idea of anecdotes [19:55] +1 [19:55] status reports sounds "discipline" [19:55] what I want is "knowledge and experience sharing" [19:55] +1 abentley [19:56] kiko: maybe each team can drive in round robin, and present interesting things they're working on, or discovered, etc. [19:56] kiko, so a "what's new in reviews" section for the entire team? [19:56] Each team will have some experience to share. [19:56] it might be nice to have a "good news" item that we do on the TL call [19:56] Rinchen, +1 [19:56] mars, yeeeah, something like that [19:57] mars, "lowlights in code reviews" etc (shocker! but mostly joking) [19:57] This is a public forum. Is there a risk of exposing our "trade $ecret$"? [19:58]