Date: Mon, 02 Jan 2012 18:07:17 -0500
From: mhershberger(a)wikimedia.org (Mark A. Hershberger)
Subject: [Wikitech-l] Fixing bugs before deployment (was Re: Rolling
towards 1.19... scheduling a code freeze)
To: Wikimedia developers <wikitech-l(a)lists.wikimedia.org>
Chad <innocentkiller(a)gmail.com> writes:
On Sun, Jan 1, 2012 at 12:49 PM, Brion Vibber
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.
I'm all for it!
Sounds good. Want to say Friday's the date to
be "feature complete" to
give people the rest of this week?
Again, great idea.
One thing I would like to do is make sure
lists all user visible
changes. I almost said "all significant user visible changes", but then
someone might know of a user visible change, but not consider it
significant and neglect to put it in there.
I disagree having "all" visible changes listed would be useful. The
majority of all changes result in some visible change (however minor).
People who are interested in every change generally would already read
the RELEASE-NOTES. If we make a list of changes of roughly the same
scope as the release notes, it will probably have the same number of
readers as the RELEASE-NOTES (Which isn't a whole lot when it comes to
your average Wikimedia).
Personally I liked the major feature summary we did for 1.18 on the
Wiki page. It gave people just interested in "whats new", but not
interested in minor differences that don't make a that much of a
difference, something to look at. There's going to be a good portion
of the user base who are only interested in the highlights.
Starting next week, after the "feature complete" deadline that Chad has
proposed, I'd like to take a list of features to the different projects
and work them to try out the changes on a test deployment wiki.
I'm trying to be more proactive about this than we have been in the
past, so that bugs like the now-infamous EXIF rotation problem
) are spotted earlier and,
hopefully, dealt with *before* deployment.
I doubt that the issue could have been dealt with before deployment.
Most of us thought it was a fairly good idea, pre-release to the wilds
of Wikimedia Commons. In my opinion, the main failures in dealing with
that situation is that we didn't listen to the complaints when they
happened (they were fairly immediate upon deploying 1.18 if i recall),
but instead waited 2 months until someone decided to raise a fuss on
With that said, it would be great if we could catch everything before
deployment, but sometimes things will get through.
I need to start doing something similar with tool
upgrades, too. If I
hadn't been content to simply nag Ops about deploying rsvg upgrades or
recompiling wikidiff2 then bugs like "rsvg on scaler does not support
styling the root element" (https://bugzilla.wikimedia.org/31122
"Excessive punctuation highlighting in wikidiff2"
) might have been recognized
Some quick tests to make sure everything works ok should certainly be
done during upgrades, but even still, some things will get through
(For example the other rsvg bug - 33323 would be much harder to catch
from quick tests, and even the rsvg bug would probably have many files
that aren't visibly affected)
A message on the commons village pump whenever rsvg is updated would
be a good idea imho (since they are generally the folks who deal with
svgs and should know if something potentially changed, and people like
knowing when things change). At the end of the day though, unless you
are planning to visually inspect 100 000 odd svg images and compare
the before and after, I doubt you will catch all such bugs.