On Tue, Sep 21, 2010 at 10:18 AM, David Gerard dgerard@gmail.com wrote:
On 21 September 2010 18:09, Rob Lanphier robla@wikimedia.org wrote:
On Tue, Sep 21, 2010 at 9:36 AM, David Gerard dgerard@gmail.com wrote:
Arbitrarily declaring "release time!" from trunk for untested code means development is effectively forked between trunk-to-tarball and the WMF version.
No one is suggesting that we be completely arbitrary.
I didn't say "completely"; however, picking a release date with no consideration of baking the code in production does seem arbitrary.
I didn't say there would be no consideration of baking the code in production. In fact, one discussion I just had was finding out what the latest thinking was with respect to the production branch.
I think we can all agree that it doesn't make sense to cut a new release of MediaWiki until the ResourceLoader stabilizes. Here's the project page for that: http://www.mediawiki.org/wiki/ResourceLoader
I'll pester the crew responsible for that to put in a brief "roadmap" paragraph in there somewhere, but the gist of my understanding is that we're talking about deploying it December at the earliest (don't quote me on that).
The new installer is something that would be nice to get out sooner rather than later. I'm not saying we should, but we *could* conceivably branch 1.16wmf4 to create a 1.17 branch, port the new installer + plus whatever nicities are already ready to go to that branch, and start stabilizing that for a 1.17 release. I doubt that we should do this, though.
So, let's assume that the existing trunk (ResourceLoader and all) is a required part of 1.17. What's the earliest reasonable time we could expect to branch point for 1.17?
(This may then lead to the tarball being volunteer effort and the WMF version being paid effort, per Simetrical's note on the subject. I submit this might also turn out not to be a good idea.)
Regardless of who gets paid by whom for what, it seems like further detangling the WMF production release process from the MediaWiki release process might not be a bad idea.
Reifying the fork (so paid developers do WMF and volunteer developers do tarball, and never the twain shall meet again) - rather than fixing it - strikes me as a *terrible* idea, as someone with cause to use the tarball. The fairly obvious consequence of your plan is an unusable tarball no-one goes near.
I didn't say "paid developers do WMF and volunteer developers do tarball", nor did I mean that. WMF has no plans of getting out of the MediaWiki release process. I merely suggested that we don't necessarily have to have the same release process for the two. One thing that's easier about MediaWiki releases versus Wikimedia site releases is that MW releases lend themselves better to more traditional QA practices. I'm not saying (yet) that we're going to do this, but (for example) we could conceivably hire outside QA to run test passes on basic MediaWiki installs, and generally stabilize MediaWiki tarballs in a different fashion than we stabilize WMF site releases.
I found really basic bugs in 1.16 betas (e.g. an install bug that made it literally impossible to install on a fresh server) that destroyed my confidence in 1.16 and left me still installing 1.15.x by preference. I submit that making the tarball version even less tested than at present is not going to get more testing achieved, but less.
I don't think it's a matter of "more" or "less", but rather a question of dependencies. How much testing did the installer get by being deployed to production on Wikimedia sites? There is going to be code that doesn't get tested at all (e.g. installer, sqlite support) solely by virtue of being deployed in WMF production. So, what do we gain by putting an arbitrarily long lead time of sitting in production prior to releasing a MediaWiki tarball?
Any of the code actually gets tested and used before you shove out a tarball that you expect people to use.
What you've said in that last paragraph is "our testing is inadequate, so let's give up testing entirely."
No, I didn't. I suggested that the worst problems with MediaWiki releases may have less to do with how long they've been baking in production than we collectively seem to think, so insisting on baking them in production for a long time may merely slow things down without increasing the quality of the tarball release.
Rob