Wikimedia Release Engineering Team/201415Q4

Top accomplishments from last quarter (Q3)

 * mediawiki-selenium 1.0, the "Environment Abstraction Layer" allows browser tests to handle multiple users and multiple wikis, which is very difficult otherwise.
 * Beta Cluster stability - Able to test wide-impact changes (eg: changing the apache user to www-data) before applying to production
 * Voting unit and acceptance tests for MW-Vagrant! - https://phabricator.wikimedia.org/T89489, https://phabricator.wikimedia.org/T76627
 * Scap automation improvements (including security patch management)
 * Rubocop jobs are now voting - https://phabricator.wikimedia.org/T84979
 * Upgrade to RSpec version 3.
 * 100% adoption of the browser test framework in every repository.

Goals staying over

 * Isolated CI Instances
 * MW Releases (not much longer)
 * Team process improvements (culmination hopefully at our team offsite)
 * Ongoing QA (Editing/Mobile)

One we should have "done" by April 1st

 * Beta Cluster stability (aka: staging cluster)

"New" Ideas

 * Code review migration to Phabricator
 * This is huge culturally (and maybe big technically) and would probably need to be a Top X project.
 * https://phabricator.wikimedia.org/T18


 * Rethinking deployment tooling and process
 * https://phabricator.wikimedia.org/T89945 (MW process)
 * https://phabricator.wikimedia.org/ToBeCreated Tooling
 * see: http://etherpad.wikimedia.org/p/futureofdeployments
 * This is probably a longer than 1 quarter goal
 * People: Mukunda, Chad, Tyler


 * Turn the releasing of MW tarballs into one click (plus signing)
 * who: Chad, ???


 * https://phabricator.wikimedia.org/T84942 - We're unable to properly run continuous integration on our extension, if it depends on Composer modules which are not already checked out in the mediawiki-core/vendor repo.


 * https://phabricator.wikimedia.org/T78739 - We really need support in Vagrant to enable a second instance of the mediawiki-core code, using the fundraising branch. The "multiwiki" role only diverges at the extension and configuration level. Not having this blocks us from getting any casual developers either from WMF or volunteers and keeps fr-tech in a silo as a result.

Spike the possibility of new types of testing:


 * https://phabricator.wikimedia.org/T90884 Automated Visual testing
 * https://phabricator.wikimedia.org/T90177 Automated native mobile app testing