Wikimedia Release Engineering Team/Offsites/2018-12-Long Beach/Topics

Let's list all the things you want to talk about!

Topic proposals

 * Vote "+1" by adding your initials to the (interest: ) parenthetical


 * Team Social Norms a la https://www.mediawiki.org/wiki/Wikimedia_Technical_Engagement/Team_Social_Norms (interest: gjg, ž, thc, dzd, liw)


 * l10nupdate RFC: https://phabricator.wikimedia.org/T158360 (interest: gjg, )


 * Zuul dependent pipeline https://phabricator.wikimedia.org/T94322 (interest: gjg, thc, anm)
 * see also: https://docs.google.com/document/d/1Sdqe5vCWu5UOVWIFyL_9vhzwMfwZzsRe2WP0uHn6pms/edit#


 * CI data gathering, planning, and purposefulness (interest: gjg, thc, anm, dzd, liw)
 * tl;dr: how can we get better at being data driven with our CI changes without alienating our non-team contributors and/or be reactive to the needs of others in a timely manner?


 * Zuul.v2 is no longer supported upstream (interest: thc, gjg, anm, dzd, liw)
 * we have effectively forked at this point, not ideal
 * Jenkins Gearman plugin unsupported
 * v3 vs jenkins
 * how to address jjb and zuul layout debt?
 * if we stick with jjb, should we write/enforce coding conventions and complementary linters?


 * Jenkins "shifting-gears" (interest: thc, gjg, anm, dzd, liw)
 * https://jenkins.io/blog/2018/08/31/shifting-gears/
 * k8s jenkins vs breaking changes release vs nothing to support legacy installs?

(Antoine: Zuul v2 obsolete and Jenkins shifting gear are tightly coupled topic. It is all about: which software stack to use in the future).


 * how do we manage the complexity of our CI/CD systems? (interest: liw)
 * probably ties into all the other topics


 * zuul/layout.yaml debt (interest: thc, liw)
 * so many pipelines
 * so many templates
 * opportunities for consolidation/debt cleanup
 * how do we test pipelines/templates and CI in general?


 * rethink test suite execution strategy (interest: dzd, liw)
 * we run all test suites for all package-manager/php/db flavors. should we?
 * what's the ideal test runner flow (a directed graph with parallel tasks) for satisfying coverage without redundancy? can quibble/jobs be refactored to implement it?
 * currently at 12 different variations. each new flavor increases load geometrically

setup-docker-quibble-castor-load setup-docker-quibble-zuul-prepare setup-docker-quibble-submodules VisualEditor setup-docker-quibble-submodules Wikibase setup-docker-quibble-mw-install setup-quibble-npm-ls PHPUnit (without db) QUnit Selenium PHPUnit (with db) setup-docker-quibble-castor-load setup-docker-quibble-zuul-prepare setup-docker-quibble-submodules Wikibase setup-docker-quibble-submodules VisualEditor setup-docker-quibble-mw-install setup-quibble-npm-ls PHPUnit (without db) QUnit Selenium PHPUnit (with db)
 * random example: https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/Wikibase/+/465578/
 * Same tests, different extensions
 * Ran wmf-quibble-vendor-mysql-hhvm-docker (https://integration.wikimedia.org/ci/job/wmf-quibble-vendor-mysql-hhvm-docker/7817/consoleFull )
 * Ran quibble-vendor-mysql-hhvm-docker (https://integration.wikimedia.org/ci/job/quibble-vendor-mysql-hhvm-docker/20370/consoleFull )


 * Antoine's Spreadsheet: https://docs.google.com/spreadsheets/d/1Fmcj3gwbUj9r0M8WI2W1lRjUC4XaznWZJ4kOeELmcgg/edit#gid=0
 * And patch: https://gerrit.wikimedia.org/r/#/c/integration/quibble/+/427099/


 * Gerrit and releases in a post-chad world (interest: thc, gjg, mm, liw)
 * (Antoine: arent we supposed to hand it off to the mediawiki team?)


 * Train automation goals planning (interest: thc, ž, gjg, anm, dzd, mm, liw)
 * One push deploy button!
 * Mukunda is making progress on scap swat


 * scap vs https://pythonclock.org/ (interest: thc, mm, liw)


 * Dev Productivity: Outcome 1: Local development is unified with testing and production (interest: gjg, ž, dzd, mm, thc, liw)
 * what are we doing here


 * IRL Keysigning party! (if needed) (interest: liw)
 * within team and across teams?