Greg Grossmeier wrote:
== What are the drawbacks of two-weeks? ==
These are mostly known by everyone so I'll just simply state the most obvious one :-)
It takes up to 2 weeks for new features/bug fixes to be rolled out to the various Wikimedia wikis.
This is not a bad thing, though. Two weeks is a helluva lot better than it could be (or has been). :-)
These conversations get a little murky when we're discussing deployments. I feel like there's a distinction between MediaWiki core and extension general fixes and upgrades versus new features and functionality being deployed to Wikimedia wikis. I think everyone agrees that the faster we can get bug fixes in, the better. But when it comes to triaging and prioritizing features and enabling certain features by default... does such a distinction exist outside my mind?
The reason I ask about a distinction is that there have been a lot of changes to Wikimedia wikis lately and likely more to come, as the Wikimedia Foundation has gotten larger and has more dedicated tech resources. Overall, this is great. But big new features come with big changes, and these changes sometimes need a bit of breathing room. I've read a lot of pushback lately against rapid changes (usurping usernames, getting rid of the new message indicator, etc.). A lot of this seems mostly outside the scope how often to deploy (and I don't want to shift the focus of this thread), but it gets confusing (to me, at least) to make a distinction between new code/features on Wikimedia wikis and how often to branch MediaWiki core/extensions.
MZMcBride