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