On Tue, Sep 21, 2010 at 10:18 AM, David Gerard <dgerard(a)gmail.com> wrote:
On 21 September 2010 18:09, Rob Lanphier
<robla(a)wikimedia.org> wrote:
On Tue, Sep 21, 2010 at 9:36 AM, David Gerard
<dgerard(a)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