User:MarkAHershberger/Weekly reports/2011-12-26

I'm actually on vacation this week (the 26th), but I'm writing this weekly report now so I don't forget any details.


 * Bugzilla routine
 * To help myself not to fall behind in the bugs, I started using my Daily Log to record the number of bug emails I've read and the number of new bugs I've scanned. It has only been a week, but so far this is better at helping me keep on top of things.


 * 20% Time Code review
 * In addition to keeping the revision report updated, I've started taking over for Rob on asking developers to use their 20% time for code review. After talking to Rob, I hope better use the 20% time to work on bugs that come up.  I like the idea of asking the developers who've signed up for a day: “Hey, could you all tackle this bug?”


 * Bugzilla downtime
 * There were three instances of bugzilla downtime this past week. Two were planned — based on some db9 maintenance that was needed — but one was the result of “swapdeath” on the bugzilla webserver.  Today (2011-12-27 when I write this) there was a similar instance.  User:Reedy told me it was some report.cgi problems.  We disabled reporting today since those scripts were being triggered from an IP identified as a Sprint Wireless address in WHOIS.  I hope to look when I get back from my vacation.


 * Back-end upgrade problems
 * A “high level” issue that we need to resolve — better consideration of the effects of any change on the live site — has shown up the following three issues:
 * Excessive punctuation highlighting in wikidiff2
 * rsvg on scaler does not support styling the root element
 * Provide an interface to rotate an image
 * All problems will not be immediately apparent. As Tim notes in Bug #32601 comment #5:
 * I'm glad someone finally got around to filing bug 33331, 7 weeks after the deployment, letting us know what the actual problem is.
 * Still these problems are all related to code or infrastructure changes that could have benefited from more review. I'm not sure what this will look like or how to make it happen without really bogging down the deployment process, but more communication is needed.
 * One idea is to have something like WP:VPT (and the equivalent for each project) where upcoming changes would be announced and a post-upgrade wiki made available for testing.
 * Launchpad.net offers some inspiration here.  Aside from the main site, there is also a the staging site, a the QAstaging site.  All of these point to the same data hosted on different databases.  Staging is rolled back to the live database on a regular basis without warning.  This gives a realistic way to test changes against realistic data.
 * If we adopted something like this, then we could push releases to our staging server and announce them on WP:VPT (or similar) with the areas that we'd like people to test.
 * But before we've even gotten that far, we should be interacting with active community members to find things to test.
 * The thought here is that if we had mentioned the rotate image change to someone, then they would have asked “how does this affect already uploaded images when they need their thumbnails regenerated?” There is no guarentee that they would have asked, of course, but in a project as large and complex as ours, we need more eyes on the problem and more points of view.