I suspect the idea is to lean more on our quality assurance infrastructure e.g. browser tests which I fully welcome.
The more developed they become the less chance of regressions making it to code let alone our projects.
When I joined 3 years ago we had no quality assurance infrastructure and now we've got things in a great place. They still need a little fine tuning but this should help us iron out the kinks by forcing us to rely on them more and push out better code. On 28 May 2015 3:53 pm, "Risker" risker.wp@gmail.com wrote:
This is strictly a question from an uninvolved observer. Does this schedule provide for sufficient time and real-time/hands-on testing before changes hit the big projects?
An IRC discussion I was following last evening suggested to me that the first deploy (to test wikis and mw.org) probably did not get sufficient hands-on testing/utilization to surface many issues that would be significant on production wikis, which means only 24 hours on smaller non-wikipedia wikis, hoping that any problems will pop up before it's applied to dewiki, frwiki and enwiki.
I recognize the challenges in balancing continuous improvement and uptime - but if problems aren't surfaced before they hit wikipedias simply because the changes aren't activated by user actions or the problems aren't reported quickly enough, then it's probably going to make more work at the other end of the chain, with more likelihood that changes will need to be rolled back or patches having to be written on the fly. I have a lot of admiration for all of you who address these unplanned situations (it really is impressive to watch!), but I'd hate to see a lot of people constantly being pulled away from other tasks to problem-solve downtimes on big projects.
Risker/Anne
On 28 May 2015 at 07:51, Dan Garry dgarry@wikimedia.org wrote:
Awesome! This will make many teams very happy since they'll be moving faster.
What's the criteria by which you will evaluate the success of this?
Thanks, Dan On 27 May 2015 10:19 pm, "Greg Grossmeier" greg@wikimedia.org wrote:
Hi all,
Starting the week of June 8th we'll be transitioning our MediaWiki + Extensions deployment cadence to a shorter/simpler one. This will begin with 1.26wmf9.
New cadence: Tuesday: New branch cut, deployed to test wikis Wednesday: deployed to non-wikipedias Thursday: deployed to Wikipedias
This is not only a lot simpler to understand ("wait, we deploy twice on Wednesday?") but it also shortens the time to get code to everyone (2
or
3 days from branch cut, depending on how you count).
== Transition == Transitions from one cadence to another are hard. Here's how we'll be doing this transition:
Week of June 1st (next week):
- We'll complete the wmf8 rollout on June 3rd
- However, we won't be cutting wmf9 on June 3rd
Week of June 8th (in two weeks):
- We'll begin the new cadence with wmf9 on Tuesday June 9th
I hope this helps our users and developers get great new features and fixes faster.
Greg
endnotes:
- The task: https://phabricator.wikimedia.org/T97553
- I'll be updating the relevant documentation before the transition
-- | Greg Grossmeier GPG: B2FA 27B1 F7EB D327 6B8E | | identi.ca: @greg A18D 1138 8E47 FAC8 1C7D |
Engineering mailing list Engineering@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/engineering
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l