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)