On Sat, Oct 24, 2009 at 3:43 PM, Chad <innocentkil...@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. _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
