recruited volunteer testers & developers re Postgres, Narayam & WikiBhasha, Wikimania got comments on the unit testing doc Requests for comment/Unit testing got new developers into the IRC bug triage (finally taking advantage of OpenHatch) got some Wikia people signed up for commit access helped notetake etherpad:GenEng-Dev-2011-07-06 talked with Guillaume about our Wikimania presentations GLAM communication continuing responsibilities -- triage, OTRS, GSoC, followup with new volunteers & with parser team WMF administrative work: travel prep, expenses, annual review
Big TODOs this week: manage& collect GSoC evaluations, make a good dent in my Wikimania talk, continue some Postgres recruiting, and do some code review research/suggestions -- specifically, look at Splinter (Bugzilla plugin that helps with code review) and write up a "how Launchpad does it" doc. re Splinter -- Mark wants to see it. Priyanka would have been the one to install that. We need to figure out who will do Bugzilla sysadmin maintenance. Mark does web admin, but we don't have real sysadmin resources. Maybe Chad? Maybe ops?
- In a nutshell: Wikimania preparation & project pages
- In a nutshell: caught up on e-mail; now: Wikimania preparation & project pages
re getting help from volunteers -- Guillaume wants to finish gradual cleanup around end of July, hopefully before that, and then we can best make use of volunteer help We have begun having one central mediawiki.org page on every engineering project, as of summer/fall 2010. We've iterated towards appropriate format/template for providers & readers of info. Guillaume is cleaning them up -- they've grown messy -- and in a week or two, we'll have a proper set of project pages, clean & helpful for people who want to find more info & for domain experts to share it. there's a new template. Please use when creating a new project page! Template:Wikimedia engineering project page once everything's settled, will publicize to wikitech-l.
Last week: w:en:User:MarkAHershberger/Weekly_reports/2011-07-11 This week's priorities:
- for 1.18 deployment blockers: delegate responsibility for fixing each blocker to a developer (except for tricky squid caching bug), taking care not to put too much work on any one person
- for 1.18 code review backlog: we're at about < 150 revisions in trunk for 1.18 that need to be reviewed. Would be good to get that below 100 for this week.
- run IRC triage around caching issues, grab Tim, Ariel, Reedy, Bryan Tong Minh, and Brion; ask Sam & Ariel for what volunteers to grab, and maybe grab Domas
When Mark has time:
- secondary goal for this week: for code review backlog metrics: grab Rob's code & make it more accurate? get rid of the doubling http://toolserver.org/~robla/crstats/crstats.trunkall.html
- tertiary goal? "how long does it take to get a bug resolved?"
- plan some of next week's triages, recognizing that some remote people will be in SF
HipHop package a few patches debian maintenance deployment blockers one major problem looking at this week: thumbnail purge & squid cache. Rob asks: whom will you ask to do the caching triage? Tim, Ariel, Reedy, Brion & Bryan Domas? maybe Rob says it boils down to the list of bugs you'll be looking at. The right bugs will interest him. Domas -- interested mostly in SQL? well, generally interested in performance. His expertise is mainly MySQL, but interests extend into performance in general. That extends to caching and purging, probably, but timing will be tough. He's in Eastern Europe. 2, 3 am his time? Sumana suggests: invite him anyway.
Last week: Development process improvement/7-8 July 2011 Meeting Main project to work on out of that: 1) getting through code review backlog. focus on first. getting process working well, getting to & staying at zero 2) continuous integration. first, integrate some tools we've already got for moving -- checking validity of a commit against a set of tests. We have some post-commit hook tests, some standalone. We want to make it so all tests we have get checked -- are routinely part of the check. 3) a bunch of other ideas down the road towards bottom, Erik's continuous responsibility to make sure certain things don't get sideswiped by other tasks/activities/emergencies. Clarify what's really urgent. We want to increase deployment frequency -- deploy once a week? Pretty optimistic. But way more frequently than now. If deploying takes less friction, we can do it more frequently. We've IDed some things we need to do to make that work. e.g. staffing? shell scripts to push whole code base out -- that set of tools is not very robust. If there's ever an error, it's buried in noise the tool generates. Too many warnings. Too many false positives. This week: Hiring Working with Aaron in SF (for quite a while!) (filling in for Priyanka) Reviews Planning Code Review training
will be in SF with face-to-face people & visiting remote people looking at ways of recording it, nominal remote participation, but more importantly, get training materials out of it. this is a real training, instruction. working on presentations UI review security review & those presentations -- we can leverage those materials at hackathons, etc. so do not feel too bad for missing this one here. format: some lectures & some hands-on practice. Some time talking through various review documents, people's code review philosophies. Brion's surprising attitude not necessariy shared by others! So a result: better understanding of everyone's approaches. Maybe ways we can be faster at it. Brion feels it's not about insuring correctness, but about understanding code well enough so if it breaks, you can go back to that line of code & then do the debugging 2.5 hrs booked for it, may extend to 3.
blogging: perenially on his TODO list, but only if he can get to it.
working on research proposal. Talking with Rob, will send another email this week. She's revised request. Better to stay outside or have WMF support it?