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 _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
