Brion Vibber wrote:
There's a couple possible ways to handle this:
- Have a read-write copy that periodically repopulates its dataset from
a live site. Probably pretty safe.
- Have a read-only configuration pulling live data from the live
database on the main server. Hopefully safe if no information-leakage bugs, but less to test.
Both of these options have the same problem as test.wikipedia.org: You can't use them for real, therefore people won't. The only thing that would keep people actively beta-testing is by letting them use the new code on the live database.
- Have a read-write configuration using live data with alternate new
code. Potentially very unsafe.
It would be "potentially very unsafe" only if you place completely untested code on it. I thought the idea was to place code on it that would otherwise have already gone out to the live site. Surely it's much safer to beta-test it first than to push it live immediately. In other words, I see it as an _addition_ to the development process you are already using, and it would catch problems such as the CSS/JavaScript one you mentioned before it goes live.
At one point, LiveJournal introduced a system whereby you can choose to use either the latest stable code (the default for everyone), or the beta-test code (users had to explicitly set this). They did this by setting a cookie, and the cookie would cause their internal proxies to choose the right server with the right version of the code. Do you think something like that could be implemented on Wikipedia? This has two huge benefits: * It would work for all Wikimedia sites, not just Wikipedia, much less just the English Wikipedia; and * People wouldn't get so upset anymore about seeing problems because they have explicitly opted in for beta-test, and (ideally) would be aware that the general public isn't seeing the problem, while at the same time being encouraged to report the problem so that it can be fixed before the general public gets to see it.
Does this make sense to you? Please ask if anything about the above is unclear.
Timwi