Aryeh Gregor wrote:
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 think the devs who were already inclined to fix bugs will fix bugs,
and the rest of the devs will just have a holiday. We would be
crossing our fingers and hoping that they'd come back at the end of
the freeze.
So yes, I think the only way to do it is to branch and then to do a
campaign of bugfix merges. If we branch early, then there will be less
features to review and fix bugs in. If we branch later, then we get a
fully featured 1.16 release with a minimal divergence from trunk.
That's the trade-off as I see it.
Anyway, if nobody is going to work on reviewing and fixing Michael's
code other than me, then it's going to be a while yet before we're in
a fit state to branch. It became pretty clear during the recent staff
meeting that I'm going to be pretty busy during the next couple of
weeks. I have to:
* Review a ton of usability initiative code and oversee its deployment.
* Review some fundraising code and make sure that a copious number of
fixes get done, then have it ready to deploy within a week.
* Do some DBA work, since it seems that I'm the only staff member who
knows MySQL.
* Fulfill my commitment to have SecurePoll ready for an arbcom
election. Roger Davies has just sent me a list of features that he
wants implemented before Friday UTC.
* Move house (removalists coming on Friday)
So I certainly won't have any time to work on the rest of MediaWiki in
the next week, and maybe not in the week after that either.
-- Tim Starling