https://wikitech.wikimedia.org/wiki/Deployments/One_week
[tl;dr] My recommendation for us to switch to a one-week deploy is to use Robla's suggestion (Option B on the wiki page[0]) starting on Monday June 10th. This will coincide with the start of the MediaWiki 1.22wmf6 deployment on WMF servers.
Unless there are any major concerns with this proposal, I'll start modifying the relevant parts of the wiki (mostly https://wikitech.wikimedia.org/wiki/Deployments and https://www.mediawiki.org/wiki/MediaWiki_1.22/Roadmap#Schedule_for_the_deplo... ).
== Riding the Train ==
Now is the time to start getting more development teams to start riding the MW Core deploy train. If a one-week cycle/14 day lifespan (with the always possible important backports available) is something doable for your team right now, please do let me know. If it isn't, please let me know what would be "good enough". Would Option A have been?
== Reasoning for Option B ==
Although we strive to be a continuous integration and deployment house, we aren't quite there yet. With that in mind, having the space between deploying to test/test2/mediawiki.org and the non-WP project sites is beneficial.
Possible workarounds to this problem included having two deploy windows on Monday (in the Option A version); one for test/test2/mediawiki in the morning, with a few hours gap then one for all non-WP project sites. The gap would be used for both automated and manual tests. While the automated tests could be scheduled and completed in a reasonable time frame, counting on the QA team to complete manual tests and report bugs in a small window isn't a dependency we should have right now; manual tests still catch a lot of issues that the automated ones do not.
Going with Option B does already reduce our wmfXX branch lifespan from 24 days to 14 days. "Lifespan" being the number of days that any branch is live on any wiki (from the day it goes to test/test2/mediawiki to the day its "slot" is replaced with a new wmfXX branch). Limiting our testing time to get down to 10 days doesn't seem worth it yet.
== Future ==
To get us down to a quicker cycle (lifespan of 10 or fewer days) we'll need to do a bit more work on the QA/testing side of things (which involves everything from betalabs, to test/test2, to unit tests, to selenium, et al). We're on the right path, thankfully.
Greg