[18:57]  * Rinchen prays to the buggy intel driver not to crash during the meeting.
[18:59]  * Rinchen continues to pray to the buggy intel driver not to crash during the meeting.
[18:59] <Ursinha> Rinchen, use irssi :P
[19:00] <Ursinha> if you're talking about the video one..
[19:00] <Rinchen> that won't help with my external display crashes :-(
[19:00] <Rinchen> #startmeeting
[19:00] <Rinchen> Welcome to this week's Launchpad development meeting. For the next 45 minutes or so, we'll be coordinating Launchpad development.
[19:00] <MootBot> Meeting started at 13:03. The chair is Rinchen.
[19:00] <MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
[19:00] <Rinchen> [TOPIC] Roll Call
[19:00] <MootBot> New Topic:  Roll Call
[19:00] <Rinchen> moo
[19:00] <mars> moo
[19:00] <Ursinha> me
[19:00] <adeuring> me
[19:00] <flacoste> me
[19:00] <bac> me
[19:00] <salgado> me
[19:00] <gmb_> me
[19:00] <mrevell> me
[19:00] <flacoste> barry, sinzui are on leave
[19:00] <jtv> me
[19:00] <Rinchen> apologies from gavin, barry, curtis....
[19:01] <matsubara> me
[19:01] <Rinchen> mpt?
[19:01] <BjornT> me
[19:01] <flacoste> EdwinGrubbs, mars, leonardr: ping
[19:01] <leonardr> me
[19:01] <mars> flacoste, moo?
[19:01] <flacoste> mars: moo doesn't count ;-)
[19:01] <mars> flacoste, sorry, couldn't help myself :)
[19:01] <mars> me
[19:01] <EdwinGrubbs> me
[19:01] <Rinchen> next week is "cluck"
[19:01] <jtv> ผม
[19:01] <flacoste> Foundations is here
[19:01] <Rinchen> thanks
[19:02] <flacoste> Rinchen: i'll miss next two meetings
[19:02] <intellectronica> me
[19:02] <herb> me
[19:02] <Rinchen> thumper won't make it today
[19:02] <cody-somerville> me
[19:02] <mpt> yo
[19:02] <mpt> me
[19:02] <BjornT> Bugs is here
[19:02] <kiko-phony> me
[19:02] <Rinchen> ok, releases is here
[19:02] <Rinchen> code is sprinting so they won't be here
[19:02] <Rinchen> jtv, danilo coming?
[19:03] <Rinchen> and no stub. :-( I even emailed him
[19:03] <jtv> Rinchen: not sure, forgot about the time so only just woke up again
[19:03] <Rinchen> k
[19:03] <Rinchen> [TOPIC] Agenda
[19:03] <MootBot> New Topic:  Agenda
[19:03] <Rinchen>  * Next meeting
[19:03] <Rinchen>  * Actions from last meeting
[19:03] <Rinchen>  * Oops report (Matsubara)
[19:03] <Rinchen>  * Critical Bugs (Rinchen)
[19:03] <Rinchen>  * Bug tags
[19:03] <Rinchen>  * Operations report (mthaddon/herb/spm)
[19:03] <Rinchen>  * DBA report (stub)
[19:03] <Rinchen>  * Sysadmin requests (Rinchen)
[19:03] <Rinchen>  * New packages required (salgado)
[19:03] <Rinchen>  * A top user-affecting issue (mrevell)
[19:03] <Rinchen>  * Doc Team report (mrevell)
[19:03] <Rinchen> plus
[19:03] <Rinchen> Introduce Reinhard Tartler as the new MOTU liaison - mrevell
[19:03] <Rinchen> #
[19:03] <Rinchen> Store OOPSes for Unauthorized exceptions - salgado
[19:03] <Rinchen> #
[19:04] <Rinchen> Bug triage & the triage status - kiko
[19:04] <Rinchen> librarian upload concerns - kiko
[19:04] <kiko-phony> cool
[19:04] <Rinchen>  
[19:04] <Rinchen> action packed mtg
[19:04] <kiko-phony> heh
[19:04] <mrevell> Rinchen: Damn, sorry, I thought the MOTU-liaison thing was off the agenda. that's old.
[19:04] <Rinchen> no worries, we can skip that one
[19:04] <Rinchen> [TOPIC] Next meeting
[19:04] <MootBot> New Topic:  Next meeting
[19:04] <Rinchen> Aug 7th. Same time, same channel.
[19:04] <flacoste> i'll miss next two meetings
[19:05] <mrevell> I'll be sprinting :)
[19:05] <mpt> I'll probably be here, but I won't be taking part
[19:05] <jtv> Translations'll be sprinting too
[19:05] <Ursinha> me too
[19:05] <mrevell> goodbye mpt
[19:05] <mrevell> mpt: thanks for all the fish
[19:05] <BjornT> i'll miss the next meeting
[19:05] <Rinchen> ok, releases team will try to be there :-)
[19:06] <Rinchen> ok. Kiko you don't want to skip next week do you? :-)
[19:06] <kiko-phony> nooooo
[19:06] <kiko-phony> I'll be here
[19:06] <Rinchen> [AGREED] Aug 7th. Same time, same channel.
[19:06] <MootBot> AGREED received:  Aug 7th. Same time, same channel.
[19:06] <Rinchen> k
[19:07] <Rinchen> [TOPIC] Actions from last meeting
[19:07] <MootBot> New Topic:  Actions from last meeting
[19:07] <Rinchen> nothing was entered from last week
[19:07] <kiko-phony> stub!
[19:07] <Rinchen> so I'll assume it was just salgado to file a bug about the store OOPSes :-)
[19:07] <stub> me
[19:07] <salgado> and I haven't done that
[19:07] <salgado> will do today
[19:07] <Rinchen> thanks salgado
[19:08] <Rinchen> [TOPIC] Oops report (Matsubara)
[19:08] <MootBot> New Topic:  Oops report (Matsubara)
[19:08] <Rinchen> and I will add Ursinha there too
[19:08] <Ursinha> Rinchen, thanks
[19:08] <matsubara> Ursinha is handling that :-)
[19:08] <Ursinha> ok
[19:08] <Ursinha> i have some timeout bugs here
[19:08] <Ursinha> bug 252695
[19:09] <Ursinha> can anybody please take a look at it? guess it's foundations one
[19:09] <Rinchen> I wonder, is there any value in retaining +peoplelist?
[19:09] <flacoste> salgado can you take care of it sometimes while i'm away?
[19:09] <flacoste> Rinchen: crawlers
[19:10] <salgado> flacoste, sure thing
[19:10] <Rinchen> googlebot ftw. ok
[19:10] <Ursinha> ok, next one, specworkload bug, bug 124205
[19:10] <flacoste> Rinchen: didn't you read, cuil is the next big thing ;-)
[19:10] <flacoste> bac is handling that one
[19:10] <Ursinha> flacoste, haha
[19:11] <mpt> flacoste, I don't think that's really a reason
[19:11] <bac> Ursinha: in review
[19:11] <BjornT> flacoste: aren't all the interesting people linked to anyway?
[19:11] <mpt> flacoste, because if someone's worth indexing, they'll be linked to from plenty of other pages in LP
[19:11] <flacoste> BjornT: good point
[19:11] <Ursinha> bac, ok, thanks
[19:11] <flacoste> salgado: acceptable fix is to remove the page ;-)
[19:11] <Rinchen> ln -s +peoplelist ~rinchen and be done with it ;-)
[19:11] <salgado> consider it done, then
[19:12] <Rinchen> Ursinha, any other bugs for today?
[19:12] <Ursinha> yes
[19:12] <Ursinha> bug 252709, the roadmap page
[19:12] <flacoste> another page that we could get rid of
[19:12] <Ursinha> it's timing out a lot, and it was suggested in bug 174480 to get rid of it
[19:12] <Rinchen>  +roadmap, a wonderful idea that we never expanded on
[19:12] <intellectronica> again?
[19:13] <Rinchen> at this juncture I'm +1 to remove +roadmap
[19:13] <Rinchen> it is not providing the value we had intended originally
[19:13] <intellectronica> +1, since it's quite hard to optimise, and not a very useful or popular page
[19:13] <cprov> err, I didn't say "me", sorry
[19:14] <Rinchen> BjornT, can intellectronica do the honours there?
[19:14] <BjornT> Rinchen: sure
[19:15] <Rinchen> thanks BjornT  and intellectronica
[19:15] <Ursinha> ok
[19:15] <Ursinha> the next
[19:15] <Ursinha> ok, one for bugs now, i suppose: bug 252674
[19:15] <Ursinha> it's a bug on malone, too many timeouts because of large queries
[19:15] <kiko-phony> Rinchen, intellectronica: you sure the mysql guys aren't using +roadmap?
[19:16] <intellectronica> kiko-phony: i can find out before killing it, just to make sure
[19:16] <Rinchen> intellectronica, I can help you with the email on that. Ping me post meeting!
[19:16] <BjornT> Ursinha: has that been happening lately? it looked like an intermittent problem
[19:17] <BjornT> Ursinha: i.e, usually those queries are fast to run
[19:17] <Ursinha> BjornT, the timeouts are strange, the oopses show low sql AND non-sql times
[19:18] <Ursinha> it's been happening quite frequently
[19:18] <kiko-phony> intellectronica, mtaylor is the guy to ask, on #launchpad
[19:18] <BjornT> Ursinha: right, and it should be because the query takes a really long time. do you have an example of such an oops for today/yesterday?
[19:18] <Rinchen> several in the bug report
[19:19] <Ursinha> oh, not on hands now, sorry
[19:19] <BjornT> Ursinha: ok. i'm asking since all the oops in the bug report are around the same time
[19:19] <Ursinha> BjornT, found one: https://devpad.canonical.com/~matsubara/oops.cgi/2008-07-31/F2030
[19:21] <BjornT> Ursinha: ok, thanks. i'm going to have to check with the losas to get more information
[19:21] <Ursinha> ok, thanks BjornT
[19:21] <Ursinha> the last one
[19:21] <Ursinha> bug 251569
[19:21] <Ursinha> guess i've mentioned that one with salgado
[19:22] <Ursinha> salgado, sorry, didn't have the time to look at it closely
[19:22] <Ursinha> can you do that for me?
[19:22] <kiko-phony> Ursinha, it might be better to reping the foundations guys on monday or tuesday once they've done the API announcement
[19:22] <salgado> Ursinha, yes, I can have a look at it next week
[19:22] <kiko-phony> Ursinha, right now they are scrambling to get that done
[19:22] <Rinchen> [AGREED] salgado to handle 252695, bac to handle 124205, intellectronica to handle 174480, bjorn to talk to losas about 252674, salgado to handle 251569
[19:22] <Ursinha> kiko-phony, ok
[19:22] <MootBot> AGREED received:  salgado to handle 252695, bac to handle 124205, intellectronica to handle 174480, bjorn to talk to losas about 252674, salgado to handle 251569
[19:22] <kiko-phony> Ursinha, and they are likely to forget everything they're saying they will do by then :)
[19:22] <Ursinha> kiko-phony, ok, thanks :)
[19:23] <Rinchen> anything else Ursinha ?
[19:23] <Ursinha> Rinchen, guess that's all folks
[19:23] <Ursinha> thanks all
[19:23] <Rinchen> thanks Ursinha
[19:23] <Rinchen> [TOPIC] Critical Bugs (Rinchen)
[19:23] <Rinchen> https://bugs.edge.launchpad.net/launchpad/+bug/253217
[19:23] <Rinchen> needs an owner
[19:23] <MootBot> New Topic:  Critical Bugs (Rinchen)
[19:23] <Rinchen> flacoste, please update the status on
[19:23] <Rinchen> https://bugs.edge.launchpad.net/launchpad/+bug/252673
[19:23] <Rinchen> flacoste, and also milestone if appropriate please
[19:24] <Rinchen> it looks like leonardr has been working on 253217
[19:24] <intellectronica> Rinchen: leonardr has been working on a fix for the first one
[19:24] <intellectronica> duh
[19:24] <flacoste> Rinchen: i updated both of them
[19:24] <Rinchen> Thanks
[19:24] <leonardr> i'm responding to salgado's review
[19:24] <leonardr> it's almost ready to go in
[19:25] <Rinchen> that's it from me. Thanks for resolving the other criticals on the list earlier.
[19:25] <Rinchen> [TOPIC] Bug tags
[19:25] <MootBot> New Topic:  Bug tags
[19:25] <Rinchen> we have one from matsubara
[19:25] <Rinchen> https://help.launchpad.net/TaggingLaunchpadBugs
[19:25] <Rinchen> pqm-analyzer
[19:25] <Rinchen> This is for the atomic pqm analyzer that kiko wrote that we're trying to get setup in the DC
[19:25] <kiko-phony> flacoste, you did? :)
[19:25] <matsubara> I'm not fussed about that tag, but I want something to group bugs related to the kiko's APA tool
[19:26] <kiko-phony> matsubara, does it have bugs in it??
[19:26] <flacoste> kiko-phony: refresh
[19:26] <kiko-phony> flacoste, woo! thanks :)
[19:26] <intellectronica> why not have a product for it?
[19:26] <flacoste> +1
[19:26] <flacoste> less bugs for me to triage :-)
[19:26] <kiko-phony> intellectronica's on the ball
[19:26] <Rinchen> There are two questions that I've been debating.  A new product and having PQM manage the code
[19:26] <kiko-phony> new product, not sure about PQM management
[19:27] <flacoste> until it's deployed, not sure it's worth it
[19:27] <kiko-phony> it's right now two files.. :) no tests!
[19:27] <Rinchen> at this point I was trying to be flexible :-)
[19:27] <flacoste> not like there were any tests to run yet anyway
[19:27] <flacoste> PQM != flexible
[19:27] <kiko-phony> ken
[19:27] <Rinchen> I meant, that's why I didn't do either :-)
[19:28] <matsubara> ok. so no tag and create a new product. fine by me.
[19:28] <Rinchen> Any objections to creating a new product and not a tag?
[19:28] <kiko-phony> DO IT
[19:28]  * matsubara wonders if I should do the same with oops-tools
[19:28] <kiko> matsubara, probably
[19:29]  * Ursinha agrees on doing the same to oops-tools
[19:29] <Rinchen> [AGREED] create new product of the APA instead of using a tag.
[19:29] <MootBot> AGREED received:  create new product of the APA instead of using a tag.
[19:29] <Rinchen> matsubara, can you please update the tag page?
[19:29] <matsubara> sure Rinchen. thanks everyone
[19:29] <stub> oops-tools should be a tag since it is part of Launchapd, but you knew I would say that :)
[19:30] <Rinchen> [TOPIC] Operations report (mthaddon/herb/spm)
[19:30] <MootBot> New Topic:  Operations report (mthaddon/herb/spm)
[19:30] <herb> Early morning Tuesday (2008-07-29) we rolled out 2.0 at r6771.
[19:30] <herb> Late in the day Tuesday (2008-07-29) we re-rolled 2.0 at r6773 to catch some important bug fixes.
[19:30] <herb> All week we've been fighting the dreaded "app server dying" bug. Bug 247227.
[19:30] <herb> Other than that it's been a quiet week. That's it from mthaddon, spm and me forthis week.
[19:30] <kiko> herb, has anyone been looking at that with you?
[19:31] <herb> kiko: not really, no.
[19:31] <kiko> herb, okay. how much is this being a problem for production?
[19:31]  * kiko #@@!
[19:32] <herb> kiko: if you take a look at the bug it shows how many times we've had to deal with a downed app server.  happens almost daily.
[19:32] <herb> and we have seen it multiple times in a day.
[19:32] <kiko> herb, can we do something to figure out what it's doing when it dies I wonder
[19:32] <kiko> flacoste, stub: any ideas of possible instrumenting we could do?
[19:33] <stub> For it to die like that, something is messing up in C code. And I'm utterly useless at that stuff.
[19:33] <flacoste> python dying is kind of out of my compentcy
[19:33] <flacoste> kiko: we need barry for that
[19:33] <flacoste> well, he might have an idea
[19:33] <Rinchen> herb, we still have yet to see this on edge?
[19:33] <flacoste> or lifeless
[19:34] <stub> or second jamesh back for a bit ;)
[19:34] <herb> Rinchen: correct.  so far just staging and production.
[19:34] <kiko> herb, flacoste, stub: well, hang on. are we saying it dies in a horrible SEGV or similar?
[19:34] <flacoste> kiko: yes
[19:34] <kiko> herb, and not an OOM?
[19:34] <herb> kiko: not an oom
[19:34] <kiko> herb, can't we run one instance inside gdb?
[19:35] <herb> I suspect we could.
[19:35] <kiko> it would be a bit slower but since it's so reliable it'd eventually crash.. or at least we'd know that we could move everything to gdb and fix the problem <wink>
[19:35] <Rinchen> we could address that by using staging
[19:35] <kiko> herb, do you want assistance doing this? I could add a make target I guess
[19:35] <Rinchen> that would then not impact production users
[19:35] <kiko> good point joey
[19:35] <herb> well, it's not reliable in the sense that we know which app server will die in any particular day. :)
[19:35] <kiko> herb, how often does it die on staging?
[19:35] <Rinchen> I find it very odd that we don't see this on edge. What is different about edge over staging and lpnet?
[19:35] <stub> The load for a start
[19:36] <herb> we've seen it die a couple of times on staging in the last couple of weeks.
[19:36] <kiko> staging isn't very loaded, is it?
[19:36] <Rinchen> linkchecker
[19:36] <kiko> which hasn't run properly for the past weeks
[19:36] <kiko> i.e. look at the staging oops reports
[19:36] <stub> But it has run?
[19:36] <Rinchen> matsubara, Ursinha - please look into the linkchecker issue
[19:36] <matsubara> it's running, yes.
[19:36] <kiko> not completely
[19:36] <kiko> the OOPS reports we get are very sparse
[19:37] <kiko> it's not hitting any bug pages, for instance
[19:37] <stub> Well... it won't if it crashes the staging servers ;)
[19:37] <kiko> stub, it doesn't crash them every day though :-(
[19:37] <kiko> anyway
[19:37] <matsubara> there's only one instance running. I disable the translations.staging.launchpad.net one as that one was causing OOM on devpad.
[19:37] <Rinchen> we can fire up staging under gdb and pound it. we're good at loading up staging :-)
[19:37] <matsubara> disabled, I mean
[19:37] <kiko> herb, do you want assistance doing this gdb thing? I could add a make target I guess
[19:37] <kiko> matsubara, it's not hitting any bugs pages, regardless.
[19:38] <kiko> matsubara, or if it is, then we need to lower the soft timeout threshold
[19:38] <kiko> because we're not getting any oopses
[19:38] <herb> kiko: I can do it.  would prefer some direction to make sure I'm doing it right.
[19:38] <kiko> and very few 404s
[19:38] <matsubara> kiko: I'll look into it
[19:38] <kiko> herb, okay, I'll test on my local box after the meeting and then ping you.
[19:38] <herb> kiko: cool.  thanks.
[19:38] <Rinchen> Thanks gents + lady
[19:38] <Rinchen> anything else for herb ?
[19:38] <kiko> matsubara, the 404s are the hint to me. we normally get hundreds. we now get tens
[19:39] <Rinchen> [TOPIC] DBA report (stub)
[19:39] <MootBot> New Topic:  DBA report (stub)
[19:39] <stub> After the earlier cleanups, the Session database had way too much empty space so I trashed the session tables. This logged everyone out but meant no downtime needed to cleanthings up and we are back within our free space map settings.
[19:39] <stub> I've got more disk space on Chokecherry. Yay. I will be abusing demo.launchpad.net in earnest - any objections speak now.
[19:39] <stub> There is a branch due to land as soon as I fix a few failing tests and get Edwins approval that changes things so we have four Storm Stores instead of the current single store. The load balancing algorithms between the launchpad master and slave stores will be tested on demo.launchpad.net. The other two stores - authdb master and slave - will not be active when the branch lands.
[19:39] <stub> The envisaged roadmap is to test load balancing between a single master and slave while finishing of the scripts needed to maintain a replicated production database environment. The initial rollout may have a single replica set or two replica sets (lpmain and authdb), although either model the appserver will be accessing everything through a single master/slave pair of Stores (ie. authdb master and authdb slave will remain unused).
[19:39] <stub> And that is all my incoherent ramblings for now.
[19:40] <kiko> stub, what are you abusing demo for?
[19:41] <kiko> ah, I see
[19:41] <Rinchen> stub, do you have a general timeframe when we can move past the single pair of stores?
[19:41] <stub> Seeing how Launchpad works with a real data set and talking to both a master and slave replica
[19:41] <kiko> gotcha, yeah, your final paragraph made it very clear
[19:41] <kiko> stub, this is awesome news, I'm thrilled to see this progress
[19:41] <Rinchen> yeah me too. I'm excited for this all to land and be turned up
[19:42] <stub> Rinchen: Not long I think. Next cycle?
[19:42] <Rinchen> Great! I'll keep the champagne on ice then.  :-)
[19:42] <Rinchen> anything else for stub?
[19:42] <Rinchen> thanks stub
[19:42] <kiko> yes
[19:42] <stub> The trick with the authdb master and slaves becoming active is updating the code to actually use them - that is all the screens on login.launchpad.net for a start I think
[19:43] <kiko> stub, what do you make of the librarian timeouts we're getting?
[19:43] <stub> We are getting Librarian timeouts?
[19:43] <kiko> stub, when people upload larger files, it pretty consistently dies and gives us a 503
[19:43] <kiko> it's only on uploads -- downloads work reliably
[19:43] <kiko> (well, I hope -- we don't have OOPSes there)
[19:43] <matsubara> stub: something like this https://pastebin.canonical.com/7785/
[19:43] <stub> I'd say there is an exception in the Librarian log file that needs to be looked at.
[19:44] <kiko> herb, but there isn't, is there?
[19:44] <herb> nope
[19:44] <herb> the librarian log file is less than good.
[19:44] <stub> Bad gateway is from Apache
[19:44] <herb> and doesn't seem to be logging anything related to uploads.
[19:45] <stub> So Apache is not passing the huge request through to the Librarian.
[19:45] <kiko> stub, only sometimes, it works!
[19:45] <kiko> hmph
[19:45] <Rinchen> there is an apport bug reported with a 503 as well and I suspect the cause of that is related to what we're seeing. Both are large uploads
[19:45] <kiko> this affects us with apport and file uploads
[19:45] <kiko> for file uploads I'd propose using sftp://
[19:45] <kiko> but for apport..
[19:46] <kiko> stub, any clue where we could start looking if it is indeed an apache issue?
[19:46] <stub> 503 or 502? The pastbin is a 502. There might be two bugs if you are getting two different codes.
[19:47] <kiko> good point
[19:47] <stub> Check the Apache logs to see if there is anything useful in there for that request
[19:47] <Rinchen> 502 sorry
[19:47] <kiko> thanks
[19:47] <Rinchen> https://bugs.edge.launchpad.net/apport/+bug/114962
[19:48] <stub> Otherwise, not sure. We might have to instrument the Librarian to log all the responses it sends out or stick in some sort of a sniffer in the middle.
[19:48] <kiko> stub, okay, I'll do some googling.
[19:48] <kiko> Rinchen, what's the apport bug id, have it handy?
[19:48] <stub> My guess would be the Librarian is taking too long to store the file and give a response, and Apache is giving up waiting.
[19:48] <Rinchen> kiko, in fact I do. :-)  read up a few lines
[19:49] <stub> There will be some Apache tuning knobs for those timeouts we can poke
[19:49] <kiko> thanks Rinchen
[19:49] <Rinchen> anything else for stub?
[19:50] <Rinchen> thanks stub
[19:50] <Rinchen> [TOPIC] Sysadmin requests (Rinchen)
[19:50] <Rinchen> Is anyone blocked on an RT or have any that are becoming urgent?  I know about 31340, 31296, and 31389.
[19:50] <MootBot> New Topic:  Sysadmin requests (Rinchen)
[19:50] <Rinchen> ok then
[19:50] <Rinchen> [TOPIC] New packages required (salgado)
[19:50] <MootBot> New Topic:  New packages required (salgado)
[19:51] <salgado> anything for me this week?
[19:51] <salgado> please say NO
[19:51] <salgado> or don't say anything. :)
[19:51] <salgado> Rinchen, I'm done. :)
[19:51] <Rinchen> :-)
[19:51] <kiko> salgado, well
[19:51] <kiko> salgado, wanted to check with you
[19:51] <kiko> I saw that we placed a request for xsltproc this week
[19:51] <salgado> yesterday, to be precise
[19:51] <kiko> salgado, was this brought up last meeting?
[19:52] <salgado> no, it wasn't
[19:52] <kiko> should it have been?
[19:52] <salgado> it should, but we didn't know about it at that time, I think
[19:52] <salgado> flacoste, when did we decide to use xsltproc?
[19:52] <kiko> I just want to understand if this is something we just discovered, or some piece of the process that's busted
[19:52] <salgado> I first heard about it being a dependency yesterday
[19:53] <flacoste> we discussed it some time ago, and then toyed with it last week
[19:53] <kiko> because IS are understandably unhappy about having to do last-minute package installs on all our servers
[19:53] <flacoste> but it was only this week that it was clear it becomes a build-time dependancy
[19:53] <flacoste> i could work around it for a while
[19:53] <flacoste> commit the file to bzr and only generate it on demand
[19:53] <kiko> flacoste, okay. in the future, if you "play around with it" then request it -- the lead time is important
[19:53] <flacoste> until that is deployed
[19:54] <kiko> flacoste, that might have to be done -- depends on what Rinchen tells us
[19:54] <Rinchen> I'll know more tomorrow morning.
[19:54] <kiko> flacoste, it's better to request and then not need it than to request too late, ok?
[19:54] <flacoste> kiko: let's do it
[19:54] <flacoste> no need for IS to be more pissed-off at us
[19:54] <flacoste> kiko: got it
[19:54] <kiko> thanks
[19:54] <kiko> guys please
[19:54] <kiko> lead time on package installations
[19:55] <kiko> no fucking around or Rinchen and I get in big trouble with the man
[19:55] <kiko> over and out
[19:55] <flacoste> Rinchen: i'll work around it
[19:55] <flacoste> Rinchen: so you can lower the priority of the thing
[19:56] <Rinchen> That about that sums up our issue with dependencies.....
[19:56] <Rinchen> thanks salgado kiko and flacoste
[19:56] <Rinchen> [TOPIC] A top user-affecting issue (mrevell)
[19:56] <MootBot> New Topic:  A top user-affecting issue (mrevell)
[19:56] <mrevell> Hello people of Planet Earth.
[19:56] <mrevell> This week has been relatively quiet in terms of user-affecting issues. However, we have had some comments from people who felt we could have done more to explain the changes to the Launchpad web interface's layout.
[19:56] <mrevell> We've already highlighted the main changes on the blog but not where each item has moved to. So, mpt, if you have some time tomorrow it'd be great if we could have a chat about producing a more comprehensive step by step guide to the changes, if you feel that's appropriate.
[19:56] <mrevell> Thanks Rinchen.
[19:56] <mpt> ok
[19:56] <Rinchen> [TOPIC] Doc Team report (mrevell)
[19:56] <MootBot> New Topic:  Doc Team report (mrevell)
[19:56] <kiko> part of the problem is that the changes are not all complete
[19:57] <Rinchen> indeed
[19:57] <mrevell> kiko: Right
[19:57] <kiko> it's a consequence of being agile, in a sense, and also a consequence of being late :)
[19:57] <Rinchen> it'll be hard to get a step by step done
[19:57] <Rinchen> but a summary should be easy enough
[19:57] <mrevell> Rinchen: Right, okay, well I'll talk to both you and mpt tomorrow about it.
[19:57] <mrevell> thanks
[19:57] <mrevell> Docs:
[19:57] <mrevell> This week the big docs-related story is the release of the tour. We've had some good community feedback, both in terms of people who like and also people who've made helpful suggestions as to where we can improve it.
[19:57] <mrevell> I've done another pass on the text today, correcting some typos. We're also going to look at some possible design improvements over the next few weeks.
[19:57] <mrevell> I'm going to be planning the next stage of the tour's evolution over the next week or so. If you have any comments, please let me know.
[19:57] <Rinchen> although I wonder if anyone will read it
[19:57] <mrevell> If there are no questions, it's back to the Rinchenator.
[19:57] <kiko> mrevell, why don't you use bzr to manipulate the tour?
[19:58] <kiko> won't that be much easier than giving patches to mats?
[19:58] <stub> I was very impressed, and I generally find things like the tour really sucky wearing my antisocial user hat.
[19:58] <kiko> (on the UI, I think people's concerns are more about the process than with the actual changes)
[19:58] <mrevell> kiko: matsubara has passed me a bzr branch that we'll work with now. the original reason was that I don't have RF access.
[19:58] <kiko> stub, yeah, I liked it a lot, and wgrant did too :)
[19:58] <mrevell> heh
[19:58] <cprov> :)
[19:58] <mrevell> stub: I'm glad you found it impressive, thanks.
[19:58] <kiko> mrevell, you should request that -- no reason from me why you shouldn't
[19:59] <Rinchen> mrevell, yeah, go talk to your manager about requesting that ;-)
[19:59] <mrevell> okay, thanks kiko. Rinchen, I'll bend your ear about that tomorrow :)
[19:59] <mrevell> heh
[19:59] <Rinchen> anything else for mrevell ?
[19:59] <matsubara> kiko, mrevell: I think it'd not hurt to give RF access to mrevell. I could still land the changes for him but it'd make the patches passing much easier
[19:59] <kiko> matsubara, yeah, I didn't make that policy up!!
[19:59] <kiko> but I can sure shoot it down
[20:00] <kiko> Rinchen, anything else? going for a world record? :)
[20:00] <Rinchen> [TOPIC] Bug triage & the triage status - kiko
[20:00] <MootBot> New Topic:  Bug triage & the triage status - kiko
[20:00] <kiko> okay
[20:00] <kiko> very quickly
[20:00] <kiko> triaged is being kinda inconsistently across our projects
[20:00] <kiko> let's be consistent in using a reasonable meaning
[20:00] <kiko> and the TLs proposal for a reasonable meaning is
[20:00] <Rinchen> (the triaged status that)
[20:01] <Rinchen> (is)
[20:01] <kiko> we understand enough about the problem
[20:01] <kiko> not know the solution -- just that the problem the user is experiencing is well-understood
[20:01] <kiko> when you look at a bug
[20:01] <kiko> you should do one of two things
[20:01] <kiko> if it's not well-understood, mark it incomplete, and ask a question
[20:01] <kiko> if it's well-understood, mark it triaged
[20:01] <kiko> if it's in the wrong LP project, change the project
[20:02] <kiko> that's three things. but YKWIM
[20:02]  * kiko runs
[20:02] <mpt> "we understand enough about the problem" to do what, exactly?
[20:02] <matsubara> so, triaged is a developer only or not?
[20:03] <kiko> mpt, we understand the problem to the developer's/triager's satisfaction.
[20:03] <mpt> to start fixing it straight away?
[20:03] <kiko> no
[20:03] <mpt> to assign it to a person?
[20:03] <mpt> to give it an accurate Importance?
[20:03] <stub> Know enough to stop logging OOPS ids?
[20:03] <kiko> just that the problem is well-understood, that the reporter doesn't need to provide any further information to describe it
[20:03] <mpt> ok
[20:03] <mpt> So how is that different from Confirmed?
[20:03] <matsubara> isn't that what confirmed is for?
[20:03] <flacoste> anybody can confirm bugs
[20:04] <kiko> it's officially set
[20:04] <kiko> that's the difference
[20:04] <kiko> (confirmed has its days counted if I have my way!!)
[20:04] <intellectronica> confirmed might go away at some point. it's just an indication that users really do experience this bug
[20:04] <Rinchen> currently we go from new -> confirmed -> maybe triaged -> in progress.     Confirmed doesn't help us devs though because we might still be missing information required to understand the problem.
[20:04] <kiko> +1 for me toos
[20:04] <mpt> So "New" means "Unconfirmed", and "Triaged" means "Confirmed", and "Confirmed" means "don't use me".
[20:04] <cody-somerville> maybe s/confirmed/open ?
[20:04] <matsubara> lol
[20:05] <kiko> cody-somerville, maybe s/confirmed// :)
[20:05] <intellectronica> mpt: not really
[20:05] <mpt> A bug can be "New" and be really really old, and a bug can be "Triaged" without having ever been triaged.
[20:05] <kiko> no
[20:06] <kiko> if a bug is in triaged, someone who's official has looked at it and marked it so
[20:06] <kiko> agreed with New.
[20:06] <intellectronica> triaged means (i think) - confirmed and investigated and will be scheduled for fixing
[20:06] <salgado> intellectronica, I thought confirmed meant that
[20:06] <kiko> if you are a developer or a launchpad triager
[20:06] <kiko> don't use confirmed
[20:06] <kiko> use triaged
[20:07] <intellectronica> salgado: no, i think confirmed just means "yes, this bug really does happen"
[20:07] <Rinchen> originally we had intended for triaged to me RTC... but in practice for bugs it's hard to get to RTC just by looking at the bug.  If we understand the nature of the problem, that will allow us to develop an approach to fix it
[20:07] <Rinchen> so triaged becomes "we know what we should do" but it doesn't imply the bug is RTC yet
[20:07] <Rinchen> Agile dictates it may not be RTC until you play with the code a bit
[20:07] <salgado> kiko, I think most devs don't know about that
[20:07] <intellectronica> Rinchen: RTC?
[20:08] <Rinchen> Ready to Code
[20:08] <intellectronica> oh right
[20:08] <kiko> salgado, that's why i brought this up!
[20:08] <mpt> Launchpad currently has 4 untriaged Triaged bugs. :-)
[20:08] <kiko> but now that I have spent 10 minutes of our time on the topic I'll send an email to the list to solidify this. :)
[20:09] <Rinchen> great!
[20:09] <Rinchen> and we've already talked about the librarian with stu!
[20:09] <Rinchen> so guess what time it is?
[20:09] <flacoste> #endmeeting
[20:09] <stub> beer o'clock!
[20:09] <bac> T+24?
[20:09] <Rinchen> bingo!
[20:09] <Rinchen> Thank you all for attending this week's Launchpad Developer Meeting. See the channel topic for the location of the logs.
[20:09] <Rinchen> #endmeeting
[20:09] <MootBot> Meeting finished at 14:12.
[20:09] <intellectronica> thanks Rinchen
[20:09] <Rinchen> the Rinchenator
[20:09] <Rinchen> lol
[20:10] <kiko> phew
[20:10] <Rinchen> I so wanted to /nick but figured mootbot would freak out
[20:10] <mrevell> thsnks Rinchen
[20:10] <kiko> this was more fun than usual!!