All,
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.
If we keep committing new code at the pace we've been going, we're never going to catch up on review, and the 1.16 final release is going to be even longer in coming. If, however, we can at least freeze trunk to new development, it could perhaps aid in the review/cleanup process associated with a release. Focusing solely on bugfixing/cleanup rather than trying to push even more new things into 1.16 allows us to cleanup 1.16 and get it in a state we're happy to release.
-Chad
On Sat, Oct 24, 2009 at 3:43 PM, Chad innocentkiller@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.
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
Tim Starling writes:
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
Yup. It seems you'll be quite busy. Can't another developer handle the fundraising code? Loks like the kind of thing that don't need a special prior knowledge, not being relevant *who* does it*. SecurePoll is also quite separate, but if you were with it, it may be better that you go on with it.
*If it's someone competent and trustable, of course.
Platonides wrote:
Can't another developer handle the fundraising code? Loks like the kind of thing that don't need a special prior knowledge, not being relevant *who* does it*. SecurePoll is also quite separate, but if you were with it, it may be better that you go on with it.
*If it's someone competent and trustable, of course.
Four Kitchens has been contracted to write the code, but they don't have much experience with MediaWiki extensions, so they need a fair bit of review and guidance. You can see the relevant code in extensions/DonationInterface.
-- Tim Starling
wikitech-l@lists.wikimedia.org