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 <[email protected]> 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" <[email protected]> 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 > > [email protected] > > https://lists.wikimedia.org/mailman/listinfo/engineering > > > _______________________________________________ > Wikitech-l mailing list > [email protected] > https://lists.wikimedia.org/mailman/listinfo/wikitech-l > _______________________________________________ Wikitech-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitech-l
