replace :bb:src: with sphinx's extlinks

master/docs/bbdocs/ext.py

@@ -174,22 +174,6 @@ def make_index(name, localname):
                 dict(name=name, localname=localname))
 
 
-class SrcRole(object):
-
-    """
-    A role to link to buildbot source on master
-    """
-
-    def __call__(self, typ, rawtext, text, lineno, inliner,
-                 options={}, content=[]):
-        node = nodes.reference('', '')
-        node['refuri'] = (
-            'https://github.com/buildbot/buildbot/blob/master/%s' % text)
-        node['reftitle'] = title = '%s' % text
-        node.append(nodes.literal(title, title))
-        return [node], []
-
-
 class BBDomain(Domain):
     name = 'bb'
     label = 'Buildbot'
@@ -295,9 +279,7 @@ class BBDomain(Domain):
         'event': XRefRole(),
         'rtype': XRefRole(),
         'rpath': XRefRole(),
-        'index': XRefRole(),
-
-        'src': SrcRole()
+        'index': XRefRole()
     }
 
     initial_data = {

master/docs/conf.py

@@ -115,7 +115,8 @@
 
 extlinks = {
     'bug': ('http://trac.buildbot.net/ticket/%s', 'bug #'),
-    'pull': ('https://github.com/buildbot/buildbot/pull/%s', 'pull request ')
+    'pull': ('https://github.com/buildbot/buildbot/pull/%s', 'pull request '),
+    'src': ('https://github.com/buildbot/buildbot/blob/master/%s', None)
 }
 
 # -- Options for HTML output ---------------------------------------------------

master/docs/developer/cls-forcesched.rst

@@ -86,7 +86,7 @@ new parameter types or hacking the existing types.
 
            A list of types that the parameter conforms to. These are used by the
            jinja template to create appropriate html form widget.  The available
-           values are visible in :bb:src:`master/buildbot/status/web/template/forms.html`
+           values are visible in :src:`master/buildbot/status/web/template/forms.html`
            in the ``force_build_one_scheduler`` macro.
 
     .. py:attribute:: default

master/docs/developer/cls-www.rst

@@ -1,7 +1,7 @@
 Web Server Classes
 ==================
 
-Most of the source in :bb:src:`master/buildbot/www` is self-explanatory.
+Most of the source in :src:`master/buildbot/www` is self-explanatory.
 However, a few classes and methods deserve some special mention.
 
 Resources

master/docs/developer/data.rst

@@ -202,9 +202,9 @@ Adding Resource Types
 +++++++++++++++++++++
 
 You'll need to use both plural and singular forms of the resource type; in this example, we'll use 'pub' and 'pubs'.
-You can also follow an existing file, like :bb:src:`master/buildbot/data/changes.py`, to see when to use which form.
+You can also follow an existing file, like :src:`master/buildbot/data/changes.py`, to see when to use which form.
 
-In :bb:src:`master/buildbot/data/pubs.py`, create a subclass of :py:class:`ResourceType`::
+In :src:`master/buildbot/data/pubs.py`, create a subclass of :py:class:`ResourceType`::
 
     from buildbot.data import base
     class Pub(base.ResourceType):
@@ -282,7 +282,7 @@ In :bb:src:`master/buildbot/data/pubs.py`, create a subclass of :py:class:`Resou
 Like all Buildbot source files, every resource type module must have corresponding tests.
 These should thoroughly exercise all update methods.
 
-All resource types must be documented in the Buildbot documentation and linked from the bottom of this file (:bb:src:`master/docs/developer/data.rst`).
+All resource types must be documented in the Buildbot documentation and linked from the bottom of this file (:src:`master/docs/developer/data.rst`).
 
 Adding Endpoints
 ++++++++++++++++
@@ -375,7 +375,7 @@ For example, if an endpoint implements pagination, then it must also completely
 Adding Messages
 +++++++++++++++
 
-Message types are defined in :bb:src:`master/buildbot/test/util/validation.py`, via the ``message`` module-level value.
+Message types are defined in :src:`master/buildbot/test/util/validation.py`, via the ``message`` module-level value.
 This is a dictionary of ``MessageValidator`` objects, one for each message type.
 The message type is determined from the first atom of its routing key.
 The ``events`` dictionary lists the possible last atoms of the routing key.
@@ -409,10 +409,10 @@ Returning to the pub example::
             # ...
             self.produceMessage(pub, 'taps-updated')
 
-Update methods should be documented in :bb:src:`master/docs/developer/data.rst`.
+Update methods should be documented in :src:`master/docs/developer/data.rst`.
 They should be thoroughly tested with unit tests.
-They should have a fake implentation in :bb:src:`master/buildbot/test/fake/fakedata.py`.
-That fake implementation should be tested to match the real implementation in :bb:src:`master/buildbot/test/interfaces/test_data_connector.py`.
+They should have a fake implentation in :src:`master/buildbot/test/fake/fakedata.py`.
+That fake implementation should be tested to match the real implementation in :src:`master/buildbot/test/interfaces/test_data_connector.py`.
 
 .. _Adding-Fields-to-Resource-Types:
 

master/docs/developer/database.rst

@@ -1565,9 +1565,7 @@ handled through the model.
     ``master.db.model.buildrequests``, and columns are available in its ``c``
     attribute.
 
-    The source file, :bb:src:`master/buildbot/db/model.py`, contains comments
-    describing each table; that information is not replicated in this
-    documentation.
+    The source file, :src:`master/buildbot/db/model.py`, contains comments describing each table; that information is not replicated in this documentation.
 
     Note that the model is not used for new installations or upgrades of the
     Buildbot database.  See :ref:`Modifying-the-Database-Schema` for more
@@ -1646,7 +1644,7 @@ fake classes in ``master/buildbot/test/fake/fakedb.py``.  Non-DB Buildbot code
 is tested using these fake implementations in order to isolate that code from
 the database code, and to speed-up tests.
 
-The keys and types used in the return value from a connector's ``get`` methods are described in :bb:src:`master/buildbot/test/util/validation.py`, via the ``dbdict`` module-level value.
+The keys and types used in the return value from a connector's ``get`` methods are described in :src:`master/buildbot/test/util/validation.py`, via the ``dbdict`` module-level value.
 This is a dictionary of ``DictValidator`` objects, one for each return value.
 
 These values are used within test methods like this::
@@ -1673,28 +1671,19 @@ To make a change to the schema, first consider how to handle any existing data.
 When adding new columns, this may not be necessary, but table refactorings can
 be complex and require caution so as not to lose information.
 
-Create a new script in :bb:src:`master/buildbot/db/migrate/versions`, following
-the numbering scheme already present.  The script should have an ``update``
-method, which takes an engine as a parameter, and upgrades the database, both
-changing the schema and performing any required data migrations.  The engine
-passed to this parameter is "enhanced" by SQLAlchemy-Migrate, with methods to
-handle adding, altering, and dropping columns.  See the SQLAlchemy-Migrate
-documentation for details.
-
-Next, modify :bb:src:`master/buildbot/db/model.py` to represent the updated
-schema.  Buildbot's automated tests perform a rudimentary comparison of an
-upgraded database with the model, but it is important to check the details -
-key length, nullability, and so on can sometimes be missed by the checks.  If
-the schema and the upgrade scripts get out of sync, bizarre behavior can
-result.
-
-Also, adjust the fake database table definitions in
-:bb:src:`master/buildbot/test/fake/fakedb.py` according to your changes.
-
-Your upgrade script should have unit tests.  The classes in
-:bb:src:`master/buildbot/test/util/migration.py` make this straightforward.
-Unit test scripts should be named e.g.,
-:file:`test_db_migrate_versions_015_remove_bad_master_objectid.py`.
+Create a new script in :src:`master/buildbot/db/migrate/versions`, following the numbering scheme already present.
+The script should have an ``update`` method, which takes an engine as a parameter, and upgrades the database, both changing the schema and performing any required data migrations.
+The engine passed to this parameter is "enhanced" by SQLAlchemy-Migrate, with methods to handle adding, altering, and dropping columns.
+See the SQLAlchemy-Migrate documentation for details.
+
+Next, modify :src:`master/buildbot/db/model.py` to represent the updated schema.
+Buildbot's automated tests perform a rudimentary comparison of an upgraded database with the model, but it is important to check the details - key length, nullability, and so on can sometimes be missed by the checks.
+If the schema and the upgrade scripts get out of sync, bizarre behavior can result.
+
+Also, adjust the fake database table definitions in :src:`master/buildbot/test/fake/fakedb.py` according to your changes.
+
+Your upgrade script should have unit tests.  The classes in :src:`master/buildbot/test/util/migration.py` make this straightforward.
+Unit test scripts should be named e.g., :file:`test_db_migrate_versions_015_remove_bad_master_objectid.py`.
 
 The :file:`master/buildbot/test/integration/test_upgrade.py` also tests
 upgrades, and will confirm that the resulting database matches the model.  If

master/docs/developer/tests.rst

@@ -152,24 +152,19 @@ like the following at the end of each test module::
 Mixins
 ------
 
-Buildbot provides a number of purpose-specific mixin classes in
-:bb:src:`master/buildbot/util`.  These generally define a set of utility
-functions as well as ``setUpXxx`` and ``tearDownXxx`` methods.  These methods
-should be called explicitly from your subclass's ``setUp`` and ``tearDown``
-methods.  Note that some of these methods return Deferreds, which should be
-handled properly by the caller.
+Buildbot provides a number of purpose-specific mixin classes in :src:`master/buildbot/util`.
+These generally define a set of utility functions as well as ``setUpXxx`` and ``tearDownXxx`` methods.
+These methods should be called explicitly from your subclass's ``setUp`` and ``tearDown`` methods.
+Note that some of these methods return Deferreds, which should be handled properly by the caller.
 
 .. _Fakes:
 
 Fakes
 -----
 
-Buildbot provides a number of pre-defined fake implementations of internal
-interfaces, in :bb:src:`master/buildbot/fake`.  These are designed to be used
-in unit tests to limit the scope of the test.  For example, the fake DB API
-eliminates the need to create a real database when testing code that uses the
-DB API, and isolates bugs in the system under test from bugs in the real DB
-implementation.
+Buildbot provides a number of pre-defined fake implementations of internal interfaces, in :src:`master/buildbot/fake`.
+These are designed to be used in unit tests to limit the scope of the test.
+For example, the fake DB API eliminates the need to create a real database when testing code that uses the DB API, and isolates bugs in the system under test from bugs in the real DB implementation.
 
 The danger of using fakes is that the fake interface and the real interface can
 differ.  The interface tests exist to solve this problem.  All fakes should be
@@ -180,7 +175,7 @@ compared.
 Type Validation
 ---------------
 
-The :bb:src:`master/buildbot/test/util/validation.py` provides a set of classes and definitions for validating Buildbot data types.
+The :src:`master/buildbot/test/util/validation.py` provides a set of classes and definitions for validating Buildbot data types.
 It supports four types of data:
 
  * DB API dictionaries, as returned from the ``getXxx`` methods,

master/docs/developer/www.rst

@@ -39,8 +39,8 @@ This allows frontend developers and users to build custom components for the web
 
 Python development and AngularJS development are very different processes, requiring different environment requirements and skillsets.
 To maimize hackability, Buildbot separates the two cleanly.
-An experienced AngularJS hacker should be quite comfortable in the :bb:src:`www/` directory, with a few exceptions described below.
-Similarly, an experienced Python hacker can simply download the pre-built web UI (from pypi!) and never venture near the :bb:src:`www/` directory.
+An experienced AngularJS hacker should be quite comfortable in the :src:`www/` directory, with a few exceptions described below.
+Similarly, an experienced Python hacker can simply download the pre-built web UI (from pypi!) and never venture near the :src:`www/` directory.
 
 URLs
 ~~~~
@@ -556,7 +556,7 @@ A running buildmaster needs to be able to find the JavaScript source code it nee
 This needs to work in a variety of contexts - Python development, JavaScript development, and end-user installations.
 To accomplish this, the grunt build process finishes by bundling all of the static data into a Python distribution tarball, along with a little bit of Python glue.
 The Python glue implements the interface described below, with some care taken to handle multiple contexts.
-The :bb:src:`www/grunt.js`, :bb:src:`www/setup.py`, and :bb:src:`www/buildbot_www.py` scripts are carefully coordinated.
+The :src:`www/grunt.js`, :src:`www/setup.py`, and :src:`www/buildbot_www.py` scripts are carefully coordinated.
 
 
 Hacking Quick-Start

master/docs/manual/cfg-statustargets.rst

@@ -58,12 +58,10 @@ Change Hooks
     Tihs section corresponds to the WebStatus, which has been removed.
     The content remains here for a later move to another location.
 
-The ``/change_hook`` url is a magic URL which will accept HTTP requests and translate
-them into changes for buildbot. Implementations (such as a trivial json-based endpoint
-and a GitHub implementation) can be found in :bb:src:`master/buildbot/status/web/hooks`.
-The format of the url is :samp:`/change_hook/{DIALECT}` where DIALECT is a package within the
-hooks directory. Change_hook is disabled by default and each DIALECT has to be enabled
-separately, for security reasons
+The ``/change_hook`` url is a magic URL which will accept HTTP requests and translate them into changes for buildbot.
+Implementations (such as a trivial json-based endpoint and a GitHub implementation) can be found in :src:`master/buildbot/status/web/hooks`.
+The format of the url is :samp:`/change_hook/{DIALECT}` where DIALECT is a package within the hooks directory.
+Change_hook is disabled by default and each DIALECT has to be enabled separately, for security reasons
 
 An example WebStatus configuration line which enables change_hook and two DIALECTS::
 

master/docs/manual/customization.rst

@@ -680,7 +680,7 @@ When the tests are finished, trial emits a long line of `======` and then some l
 We want to avoid parsing these trailing lines, because their format is less well-defined than the `[OK]` lines.
 
 A simple version of the parser for this output looks like this.
-The full version is in :bb:src:`master/buildbot/steps/python_twisted.py`.
+The full version is in :src:`master/buildbot/steps/python_twisted.py`.
 
 .. code-block:: python
 

master/docs/relnotes/0.8.6.rst

@@ -184,9 +184,8 @@ Features
   all the triggered builds. This URL is displayed in the waterfall and build
   details. See :bug:`2170`.
 
-* The :bb:src:`master/contrib/fakemaster.py`` script allows you to run arbitrary
-  commands on a slave by emulating a master.  See the file itself for
-  documentation.
+* The :src:`master/contrib/fakemaster.py`` script allows you to run arbitrary commands on a slave by emulating a master.
+  See the file itself for documentation.
 
 * MailNotifier allows multiple notification modes in the same instance.  See
   :bug:`2205`.
@@ -219,6 +218,4 @@ Git log itself:
 Older Versions
 --------------
 
-Release notes for older versions of Buildbot are available in the
-:bb:src:`master/docs/release-notes/` directory of the source tree, or in the archived
-documentation for those versions at http://buildbot.net/buildbot/docs.
+Release notes for older versions of Buildbot are available in the :src:`master/docs/release-notes/` directory of the source tree, or in the archived documentation for those versions at http://buildbot.net/buildbot/docs.

master/docs/relnotes/0.8.7.rst

@@ -261,5 +261,5 @@ Git log itself:
 Older Versions
 --------------
 
-Release notes for older versions of Buildbot are available in the :bb:src:`master/docs/relnotes/` directory of the source tree.
+Release notes for older versions of Buildbot are available in the :src:`master/docs/relnotes/` directory of the source tree.
 Starting with version 0.8.6, they are also available under the appropriate version at http://buildbot.net/buildbot/docs.

master/docs/relnotes/0.8.8.rst

@@ -151,7 +151,7 @@ git log itself:
 Older Versions
 --------------
 
-Release notes for older versions of Buildbot are available in the :bb:src:`master/docs/relnotes/` directory of the source tree.
+Release notes for older versions of Buildbot are available in the :src:`master/docs/relnotes/` directory of the source tree.
 Newer versions are also available here:
 
 .. toctree::

master/docs/relnotes/0.8.9.rst

@@ -178,9 +178,9 @@ Features
 
 * Added zsh and bash tab-completions support for 'buildbot' command.
 
-* An example of a declarative configuration is included in :bb:src:`master/contrib/SimpleConfig.py`, with copious comments.
+* An example of a declarative configuration is included in :src:`master/contrib/SimpleConfig.py`, with copious comments.
 
-* Systemd unit files for Buildbot are available in the :bb:src:`master/contrib/` directory.
+* Systemd unit files for Buildbot are available in the :src:`master/contrib/` directory.
 
 * We've added some extra checking to make sure that you have a valid locale before starting buildbot (#2608).
 
@@ -369,7 +369,7 @@ git log itself:
 Older Versions
 --------------
 
-Release notes for older versions of Buildbot are available in the :bb:src:`master/docs/relnotes/` directory of the source tree.
+Release notes for older versions of Buildbot are available in the :src:`master/docs/relnotes/` directory of the source tree.
 Newer versions are also available here:
 
 .. toctree::

master/docs/relnotes/index.rst

@@ -271,7 +271,7 @@ git log itself:
 Older Versions
 --------------
 
-Release notes for older versions of Buildbot are available in the :bb:src:`master/docs/relnotes/` directory of the source tree.
+Release notes for older versions of Buildbot are available in the :src:`master/docs/relnotes/` directory of the source tree.
 Newer versions are also available here:
 
 .. toctree::