[Buildbot] #2340: [MOSS Project] Please Change 'Slave' terminology (was: Please Change 'Slave' terminology)

[Buildbot trac]

#2340: [MOSS Project] Please Change 'Slave' terminology
-----------------------------+--------------------
Reporter:  kimmers           |       Owner:
    Type:  enhancement       |      Status:  new
Priority:  patches-accepted  |   Milestone:  0.9.+
 Version:  master            |  Resolution:
Keywords:  moss              |
-----------------------------+--------------------
Changes (by dustin):

 * keywords:   => moss
 * version:  0.8.6p1 => master
 * milestone:  1.0.+ => 0.9.+


Old description:

> I am a manager at Cray Supercomputers, where we have recently started
> using Buildbot. Some of our employees have found the Master/Slave
> terminology offensive. Please consider changing this terminology to
> Master/Worker.

New description:

 I am a manager at Cray Supercomputers, where we have recently started
 using Buildbot. Some of our employees have found the Master/Slave
 terminology offensive. Please consider changing this terminology to
 Master/Worker.

 ----

 Some notes on how we communicate on this bug may be salient:

  * Buildbot does have a
 [https://github.com/buildbot/botherders/blob/master/policies/conduct.md
 code of conduct] - please be mindful of it when posting
  * By proposing this as part of the project's MOSS application, which has
 been funded, we have committed to making this change.  As such, arguments
 that Buildbot should not make this change are not particularly relevant.

 --Dustin

--

Comment:

 I think that the consensus here is on renaming "Slave" to "Worker" while
 leaving "Master" intact -- that addresses the request without the
 additional complexity of changing the master's name.

 I put some of my concerns in pull 1842, but it looks like that PR is stale
 now so I'll reiterate them here:

  * master/{slave,worker} compatibility is critical -- users with existing
 running buildslaves need to be able to interact with a new master.  If the
 package name changes (buildbot-slave -> buildbot-worker), then it's fine
 for the reverse to not work (that is, buildbot-worker need not be
 compatible with buildbot versions earlier 0.9.0, as those users can still
 install the latest (but older) buildbot-slave package)
   * this is trickier than it sounds, since the class names are a part of
 the PB protocol used for master/slave communication.  Another (not easy!)
 option is to complete the master/slave generalization and use that new
 protocol instead.
  * Documentation needs to be updated with some care.  As a stopgap, we've
 endeavored to use "buildslave" instead of "slave", but that should not
 turn into "buildworker".
  * required changes for users should be minimized and documented clearly
 in the release notes and `nine-upgrade.rst`.  For example, presumably
 `c['slaves']` is now `c['workers']` and is populated with `Worker`
 instances.  If the changes are more than a simple instruction, include
 compatibility and a warning rather than outright failing.
  * Developer API changes need to be documented individually in the release
 notes.  As above, prefer to warn and succeed rather than failing for un-
 upgraded code.
  * Modifications to the Data API do not require compatibility notes as
 there have been no Data API releases.  However, the AngularJS frontend
 needs to utilize the modified API correctly.
  * Include a DB migration to rename the buildslave table and any other DB
 names.

 As a MOSS project (and thus funded work) I will strengthen the
 compatibility requirement: where in any way possible, backward
 compatibility must be maintained, for configuration files, for existing
 custom buildsteps, and for network communication.

 Because of the compatibility considerations, a grep of the code for
 `/slave/` will continue to produce a number of hits.  However, a new
 install of Buildbot should run without any user-visible evidence of the
 term.  That includes database table names, Data API paths and fields, and
 any UI elements, as well as configuration files and documentation.

--
Ticket URL: <http://trac.buildbot.net/ticket/2340#comment:13>
Buildbot <http://buildbot.net/>
Buildbot: build/test automation