On Sat, Oct 24, 2009 at 3:43 PM, Chad <innocentkiller(a)gmail.com> wrote:
As we are all very aware, it is long past time for
branching 1.16 for release.
Tim, as our release manager, has stated previously that the current state of
trunk is in no condition to be a release; I'm inclined to agree.
It's just shy of 6 months since 1.15 was branched, and we've had over 8000
commits since then, including 3 branches completed and merged. That is a hell
of a lot of code, and a hell of a lot of code to review. I've been thinking,
and I've mentioned it in a few places to some people, that perhaps it's time
for a code freeze prior to branching.
We were in a similar situation for 1.15, and the way we solved that is
by branching from the last revision used on Wikimedia. In practice,
all our testing happens by means of deploying to Wikimedia and seeing
what happens. It would definitely be a bad idea to release any code
that hasn't been working on Wikimedia for a while (at least, if it's
meant to be used on Wikimedia). So I don't think a code freeze will
actually accelerate the release at all -- at most, it will mean more
revisions get released in 1.16 instead of 1.17.
The only advantage I can see in a code freeze is to try forcing devs
to spend their time fixing bugs instead of adding features. I'm not
sure that will work very well, and I'm not sure it would be valuable
if it did. Fixing a bug isn't inherently more valuable than adding a
feature. Adding a good feature can be worth much more than fixing a
minor bug. The only type of bug that really needs to be fixed in a
particular release (and isn't so serious that it would be fixed
anyway) is an intra-release regression -- that's good to fix before
release because fewer regressions mean more people willing to upgrade.
Any other type of bug fix could just as well be pushed to the next
release.
So that's MHO. It might be useful to flag bugs that are regressions
from 1.15, and make sure those specifically are fixed, but I don't
think there's much use in a proper code freeze. AFAICT, other
projects do code freezes only so that testers have something stable to
find bugs in -- but we already do all our testing intra-release on
Wikimedia. I don't think this particular development paradigm will
work well for us.