Στις 15-04-2011, ημέρα Παρ, και ώρα 18:41 -0700, ο/η Brion Vibber έγραψε:
One issue we see at present is that since we version and deploy core and extensions together, it's tough to get a semi-experimental extension into limited deployment with regular updates. Let's make sure that's clean and easy to do to; right now it's very easy to deploy experimental JavaScript into a gadget or site JS, but an extension may just sit idle in SVN for years, unusable in production even if it's limited, modular code because no one wants to deploy it. If there's interest it may get a prototype site, but if they only get used by the testing crew or when we ask someone to go and make some fake edits on them, they're not going to have all their bugs exercised.
Being able to do more self-directed prototype sites with the upcoming virtualization infrastructure should help with that, and for certain front-end things it should be possible to use JS whatsits to hook some of that code into live sites for opt-in or a/b testing -- further reducing dangers by removing the server-side variations and providing an instant switch-back to the old code.
I don't advocate just blindly updating the whole stack all the time; I advocate aiming for smaller pieces that can be run and tested more easily and more safely in more flexible ways.
As a power user willing to risk my neck to make things better, I want to be able to opt in to the "Wikipedia beta" and actually get an experimental new feature *on Wikipedia or Commons* a lot more often. As a developer, I want to be able to get things into other peoples' hands so they can test them for me and give me feedback.
The ability to easily test a feature, an extension or an update on a small percentage of users, based on opt-in, project/language or simple random percentage, is something that many shops have and that we should prioritize adding to our deployment toolkit. It's unrealistic to think that we will uncover all of the issues, even the serious ones, ourselves running on a test environment, or even on the cluster. Our users exercise this code in ways that aren't even on our radar, which is a good thing; let's make use of it.
FWIW I also support having a much more agressive testing, deployment and release schedule, for many of the reasons already described by others.
Ariel