BMO/Meetings/2013-05-13

it is a code push day for glob. many more fields are in bugzilla now.

shyam is still doing some IT work for BMO including whatever is happening in Phoenix but Jake Maul (:jakem) will be the primary interface after this quarter. web ops team is now 9 people (used to be 4)

mcote asks about a public elastic search database. jakem will be the new contact for that.

kyle - should IT or metrics be doing this? jakem - IT will be mcote - orange factor is moving from metrics to IT-managed. right now, kyle has bugzilla data and wants test data too. so it is a copy of the bugzilla database but with all the history too. only public bugs.

next quarter, responsibility for pushing changes shifts to web ops team. What effect will that have on timing - since glob works in the middle of the night . Asheesh mostly has been working on it.

kyle - elastic search now can use meta bugs to trace a tree of dependencies. we now can see bug dependencies over time. lawrence mandel has been asked to consider moving from hg to git. he wants to know how many patches are outstanding at any particular time, to be moved over. a lot of the patches just never get closed. They never get made obsolete, and they never get incorporated. if we look at things marked "ispatch" , maybe 50% of them never get closed. either closed, verified, fixed.

non-obsolete patches on open bugs.

dkl amuses us all by vidyo speeding up his voice. chipmunk time!

dkl asks over irc if they are all patches that have a question mark? or what? kyle thinks maybe they never get marked for review by the patch submitter. That seems likely. Could it be spelling "review" wrong? No, because it is in a dropdown. We all think it must be community contributors who don't know to mark the patch. If so maybe that could be a process improvement and is worth investigating.

glob: bug filed by ehsan last week that maybe bugzilla is getting slower. But no data. Looking at scl3 response times: they look the same. how do we investigate this if it is not a server problem but is a client side problem?

if there are a large number of people cc-ed then that can be slow. it isn't a simple thing to fix, though. And we are already focused on the right things by looking at performance and tracking flags. We are sending more component watching emails in the last 6 months or so. We could ask people to measure this in firebug and see what requests take a long time so we have some data.

• kyle's holiday Wed-Thurs-Fri this week
• next monday is a holiday in Canada so we will be meeting on Tuesday. The week after as well.