Happy New Year everybody -- we survived 2011 and have another wacky fun year of MediaWiki goodness to look forward to in 2012!
As we roll over our calendars, let's not forget it's also getting towards time to roll out another MediaWiki release. 1.19's seen a lot of refactoring goodness, bug fixes, and improvements; we need to make sure we can get those improvements out to the public.
I'd like us to plan for a code freeze on trunk -- at least a feature & refactoring freeze -- starting within a few days to give us all a chance to tidy up, catch up with code review, and prepare for deployments.
The combinations of review, testing, and actual deployments are important parts of our quality control system; we know from past experience that long waits between deployments have lead to poorly-tested code getting pushed out long after they've fallen out of our collective memory, making bugs newly discovered in them harder to find.
I believe we've got some general plans to hit deployment in February; if we hit code slush this week or so that gives some time for everybody to catch up on review, do more thorough testing and -- perhaps most importantly of all -- make sure we have good documentation on what's changed and what needs to be tested and tried out by real humans!
Note that I'm recommending a slush/freeze on trunk rather than simply branching and doing review on the release branch because that's been hard to manage in the past. I think we really need to concentrate on release polish, especially making sure that we don't have unexpected regressions and that people know what to expect has changed in the user interface and in behavior. Even "small" features like the image rotation changes we landed in 1.18 can have surprising consequences, and need to be clearly on peoples' radar before they're irrevocable.
-- brion vibber (brion @ pobox.com / bvibber @ wikimedia.org)