[yt-svn] commit/yt: 2 new changesets

commits-noreply at bitbucket.org commits-noreply at bitbucket.org
Wed Apr 26 10:25:07 PDT 2017


2 new commits in yt:

https://bitbucket.org/yt_analysis/yt/commits/a816cf974397/
Changeset:   a816cf974397
Branch:      yt
User:        ngoldbaum
Date:        2017-04-25 23:54:49+00:00
Summary:     Update documentation for github transition
Affected #:  16 files

diff -r 634cc55bf0668d551109b3a35850bb6c369b47b4 -r a816cf974397f25253f0f700a43c8a253933db28 doc/source/about/index.rst
--- a/doc/source/about/index.rst
+++ b/doc/source/about/index.rst
@@ -16,7 +16,7 @@
 it has grown to handle any kind of data represented in a 2D or 3D volume.
 yt is an Python-based open source project and is open for anyone to use or
 contribute code.  The entire source code and history is available to all
-at https://bitbucket.org/yt_analysis/yt .
+at http://github.com/yt-project/yt .
 
 .. _who-is-yt:
 
@@ -31,7 +31,7 @@
 `our members website. <http://yt-project.org/members.html>`_
 
 For an up-to-date list of everyone who has contributed to the yt codebase,
-see the current `CREDITS <http://bitbucket.org/yt_analysis/yt/src/yt/CREDITS>`_ file.
+see the current `CREDITS <https://github.com/yt-project/yt/blob/master/CREDITS>`_ file.
 For a more detailed breakup of contributions made by individual users, see out
 `Open HUB page <https://www.openhub.net/p/yt_amr/contributors?query=&sort=commits>`_.
 

diff -r 634cc55bf0668d551109b3a35850bb6c369b47b4 -r a816cf974397f25253f0f700a43c8a253933db28 doc/source/analyzing/analysis_modules/halo_mass_function.rst
--- a/doc/source/analyzing/analysis_modules/halo_mass_function.rst
+++ b/doc/source/analyzing/analysis_modules/halo_mass_function.rst
@@ -4,7 +4,7 @@
 
    This module has been deprecated as it no longer functions correctly and is
    unmaintained.  The code has been moved to the `yt attic
-   <https://bitbucket.org/yt_analysis/yt_attic>`__. If you'd like to take it
+   <https://github.com/yt-project/yt_attic>`__. If you'd like to take it
    over, please do!
 
 Halo Mass Function

diff -r 634cc55bf0668d551109b3a35850bb6c369b47b4 -r a816cf974397f25253f0f700a43c8a253933db28 doc/source/analyzing/analysis_modules/star_analysis.rst
--- a/doc/source/analyzing/analysis_modules/star_analysis.rst
+++ b/doc/source/analyzing/analysis_modules/star_analysis.rst
@@ -3,7 +3,7 @@
 .. note::
 
    This module has been deprecated as it is unmaintained.  The code has been
-   moved to the `yt attic <https://bitbucket.org/yt_analysis/yt_attic>`__.
+   moved to the `yt attic <https://github.com/yt-project/yt_attic>`__.
    If you'd like to take it over, please do!
 
 Star Particle Analysis

diff -r 634cc55bf0668d551109b3a35850bb6c369b47b4 -r a816cf974397f25253f0f700a43c8a253933db28 doc/source/analyzing/analysis_modules/sunrise_export.rst
--- a/doc/source/analyzing/analysis_modules/sunrise_export.rst
+++ b/doc/source/analyzing/analysis_modules/sunrise_export.rst
@@ -3,7 +3,7 @@
 .. note::
 
    This module has been deprecated as it is unmaintained.  The code has been
-   moved to the `yt attic <https://bitbucket.org/yt_analysis/yt_attic>`__.
+   moved to the `yt attic <https://github.com/yt-project/yt_attic>`__.
    If you'd like to take it over, please do!
 
 Exporting to Sunrise

diff -r 634cc55bf0668d551109b3a35850bb6c369b47b4 -r a816cf974397f25253f0f700a43c8a253933db28 doc/source/analyzing/analysis_modules/two_point_functions.rst
--- a/doc/source/analyzing/analysis_modules/two_point_functions.rst
+++ b/doc/source/analyzing/analysis_modules/two_point_functions.rst
@@ -3,7 +3,7 @@
 .. note::
 
    This module has been deprecated as it is unmaintained.  The code has been
-   moved to the `yt attic <https://bitbucket.org/yt_analysis/yt_attic>`__.
+   moved to the `yt attic <https://github.com/yt-project/yt_attic>`__.
    If you'd like to take it over, please do!
 
 Two Point Functions

diff -r 634cc55bf0668d551109b3a35850bb6c369b47b4 -r a816cf974397f25253f0f700a43c8a253933db28 doc/source/analyzing/units/index.rst
--- a/doc/source/analyzing/units/index.rst
+++ b/doc/source/analyzing/units/index.rst
@@ -12,8 +12,8 @@
 and execute the documentation interactively, you need to download the repository
 and start the IPython notebook.
 
-You will then need to navigate to :code:`$YT_HG/doc/source/units` (where $YT_HG
-is the location of a clone of the yt mercurial repository), and then start an
+You will then need to navigate to :code:`$YT_GIT/doc/source/units` (where $YT_GIT
+is the location of a clone of the yt git repository), and then start an
 IPython notebook server:
 
 .. code:: bash

diff -r 634cc55bf0668d551109b3a35850bb6c369b47b4 -r a816cf974397f25253f0f700a43c8a253933db28 doc/source/developing/building_the_docs.rst
--- a/doc/source/developing/building_the_docs.rst
+++ b/doc/source/developing/building_the_docs.rst
@@ -19,9 +19,9 @@
 include a recipe in the cookbook section, or it could simply be adding a note
 in the relevant docs text somewhere.
 
-The documentation exists in the main mercurial code repository for yt in the
-``doc`` directory (i.e. ``$YT_HG/doc/source`` where ``$YT_HG`` is the path of
-the yt mercurial repository).  It is organized hierarchically into the main
+The documentation exists in the main code repository for yt in the
+``doc`` directory (i.e. ``$YT_GIT/doc/source`` where ``$YT_GIT`` is the path of
+the yt git repository).  It is organized hierarchically into the main
 categories of:
 
 * Visualizing

diff -r 634cc55bf0668d551109b3a35850bb6c369b47b4 -r a816cf974397f25253f0f700a43c8a253933db28 doc/source/developing/extensions.rst
--- a/doc/source/developing/extensions.rst
+++ b/doc/source/developing/extensions.rst
@@ -40,10 +40,10 @@
 
 A template for starting an extension module (or converting an existing set of
 code to an extension module) can be found at
-https://bitbucket.org/yt_analysis/yt_extension_template .
+https://github.com/yt-project/yt_extension_template .
 
 To get started, download a zipfile of the template (
-https://bitbucket.org/yt_analysis/yt_extension_template/get/tip.zip ) and
+https://github.com/yt-project/yt_extension_template/archive/master.zip ) and
 follow the directions in ``README.md`` to modify the metadata.
 
 Distributing Extensions

diff -r 634cc55bf0668d551109b3a35850bb6c369b47b4 -r a816cf974397f25253f0f700a43c8a253933db28 doc/source/developing/releasing.rst
--- a/doc/source/developing/releasing.rst
+++ b/doc/source/developing/releasing.rst
@@ -12,9 +12,8 @@
   once a month. These releases should contain only fixes for bugs discovered in
   earlier releases and should not contain new features or API changes. Bugfix
   releases should increment the ``PATCH`` version number. Bugfix releases should
-  *not* be generated by merging from the ``yt`` branch, instead bugfix pull
-  requests should be manually backported using the PR backport script, described
-  below. Version ``3.2.2`` is a bugfix release.
+  *not* be generated by merging from the ``master`` branch, instead bugfix pull
+  requests should be manually backported. Version ``3.2.2`` is a bugfix release.
 
 * Minor releases
 
@@ -25,7 +24,7 @@
   backwards-incompatible changes and should not change APIs.  If an API change
   is deemed to be necessary, the old API should continue to function but might
   trigger deprecation warnings. Minor releases should happen by merging the
-  ``yt`` branch into the ``stable`` branch. Minor releases should increment the
+  ``master`` branch into the ``stable`` branch. Minor releases should increment the
   ``MINOR`` version number and reset the ``PATCH`` version number to zero.
   Version ``3.3.0`` is a minor release.
 
@@ -36,7 +35,7 @@
   include arbitrary changes to the library. Major version releases should only
   happen after extensive discussion and vetting among the developer and user
   community. Like minor releases, a major release should happen by merging the
-  ``yt`` branch into the ``stable`` branch. Major releases should increment the
+  ``master`` branch into the ``stable`` branch. Major releases should increment the
   ``MAJOR`` version number and reset the ``MINOR`` and ``PATCH`` version numbers
   to zero. If it ever happens, version ``4.0.0`` will be a major release.
 
@@ -49,99 +48,25 @@
 As described above, bugfix releases are regularly scheduled updates for minor
 releases to ensure fixes for bugs make their way out to users in a timely
 manner. Since bugfix releases should not include new features, we do not issue
-bugfix releases by simply merging from the development ``yt`` branch into the
-``stable`` branch.  Instead, we make use of the ``pr_backport.py`` script to
-manually cherry-pick bugfixes from the from ``yt`` branch onto the ``stable``
-branch.
-
-The backport script issues interactive prompts to backport individual pull
-requests to the ``stable`` branch in a temporary clone of the main yt mercurial
-repository on bitbucket. The script is written this way to to avoid editing
-history in a clone of the repository that a developer uses for day-to-day work
-and to avoid mixing work-in-progress changes with changes that have made their
-way to the "canonical" yt repository on bitbucket.
-
-Rather than automatically manipulating the temporary repository by scripting
-mercurial commands using ``python-hglib``, the script must be "operated" by a
-human who is ready to think carefully about what the script is telling them
-to do. Most operations will merely require copy/pasting a suggested mercurial
-command. However, some changes will require manual backporting.
-
-To run the backport script, first open two terminal windows. The first window
-will be used to run the backport script. The second terminal will be used to
-manipulate a temporary clone of the yt mercurial repository. In the first
-window, navigate to the ``scripts`` directory at the root of the yt repository
-and run the backport script,
-
-.. code-block:: bash
-
-   $ cd $YT_HG/scripts
-   $ python pr_backport.py
-
-You will then need to wait for about a minute (depending on the speed of your
-internet connection and bitbucket's servers) while the script makes a clone of
-the main yt repository and then gathers information about pull requests that
-have been merged since the last tagged release. Once this step finishes, you
-will be prompted to navigate to the temporary folder in a new separate terminal
-session. Do so, and then hit the enter key in the original terminal session.
-
-For each pull request in the set of pull requests that were merged since the
-last tagged release that were pointed at the "main" line of development
-(e.g. not the ``experimental`` bookmark), you will be prompted by the script
-with the PR number, title, description, and a suggested mercurial
-command to use to backport the pull request. If the pull request consists of a
-single changeset, you will be prompted to use ``hg graft``. If it contains more
-than one changeset, you will be prompted to use ``hg rebase``. Note that
-``rebase`` is an optional extension for mercurial that is not turned on by
-default. To enable it, add a section like the following in your ``.hgrc`` file:
-
-.. code-block:: none
-
-   [extensions]
-   rebase=
-
-Since ``rebase`` is bundled with core mercurial, you do not need to specify a
-path to the rebase extension, just say ``rebase=`` and mercurial will find the
-version of ``rebase`` bundled with mercurial. Note also that mercurial does not
-automatically update to the tip of the rebased head after executing ``hg
-rebase`` so you will need to manually issue ``hg update stable`` to move your
-working directory to the new head of the stable branch. The backport script
-should prompt you with a suggestion to update as well.
+bugfix releases by simply merging from the development ``master`` branch into
+the ``stable`` branch.  Instead, we manually cherry-pick bugfixes from the from
+``master`` branch onto the ``stable`` branch.
 
 If the pull request contains merge commits, you must take care to *not* backport
-commits that merge with the main line of development on the ``yt`` branch. Doing
+commits that merge with the main line of development on the ``master`` branch. Doing
 so may bring unrelated changes, including new features, into a bugfix
-release. If the pull request you'd like to backport contains merge commits, the
-backport script should warn you to be extra careful.
+release.
 
-Once you've finished backporting, the script will let you know that you are done
-and warn you to push your work. The temporary repository you have been working
-with will be deleted as soon as the script exits, so take care to push your work
-on the ``stable`` branch to your fork on bitbucket. Once you've pushed to your
-fork, you will be able to issue a pull request containing the backported fixes
-just like any other yt pull request.
+Once you've finished backporting push your work to Github. Once you've pushed to
+your fork, you will be able to issue a pull request containing the backported
+fixes just like any other yt pull request.
 
 Doing a Minor or Major Release
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 This is much simpler than a bugfix release.  All that needs to happen is the
-``yt`` branch must get merged into the ``stable`` branch, and any conflicts that
-happen must be resolved, almost certainly in favor of the yt branch. This can
-happen either using a merge tool like ``vimdiff`` and ``kdiff3`` or by telling
-mercurial to write merge markers. If you prefer merge markers, the following
-configuration options should be turned on in your ``hgrc`` to get more detail
-during the merge:
-
-.. code-block:: none
-
-   [ui]
-   merge = internal:merge3
-   mergemarkers = detailed
-
-The first option tells mercurial to write merge markers that show the state of
-the conflicted region of the code on both sides of the merge as well as the
-"base" most recent common ancestor changeset. The second option tells mercurial
-to add extra information about the code near the merge markers.
+``master`` branch must get merged into the ``stable`` branch, and any conflicts
+that happen must be resolved.
 
 
 Incrementing Version Numbers and Tagging a Release
@@ -174,35 +99,42 @@
 
 .. code-block:: bash
 
-   hg tag <tag-name>
+   git tag <tag-name>
 
 Where ``<tag-name>`` follows the project's naming scheme for tags
-(e.g. ``yt-3.2.1``). Commit the tag, and you should be ready to upload the
-release to pypi.
+(e.g. ``yt-3.2.1``). Once you are done, you will need to push the
+tag to github::
+
+  git push origin --tags
 
-If you are doing a minor or major version number release, you will also need to
-update back to the development branch and update the development version numbers
-in the same files.
+This assumes that you have configured the remote ``origin`` to point at the main
+yt git repository. If you are doing a minor or major version number release, you
+will also need to update back to the development branch and update the
+development version numbers in the same files.
 
 
 Uploading to PyPI
 ~~~~~~~~~~~~~~~~~
 
 To actually upload the release to the Python Package Index, you just need to
-issue the following command:
+issue the following commands:
 
 .. code-block:: bash
 
-   python setup.py sdist upload -r https://pypi.python.org/pypi
+   python setup.py sdist
+   twine upload dist/*
 
 You will be prompted for your PyPI credentials and then the package should
 upload. Note that for this to complete successfully, you will need an account on
 PyPI and that account will need to be registered as an "owner" of the yt
-package. Right now there are three owners: Matt Turk, Britton Smith, and Nathan
-Goldbaum.
+package. Right now there are five owners: Matt Turk, Britton Smith, Nathan
+Goldbaum, John ZuHone, and Kacper Kowalik. In addition, you should attempt to
+upload the yt package along with compiled binary wheel packages for various
+platforms that we support.  You should contact John ZuHone about uploading
+binary wheels to PyPI for Windows and OS X users, Kacper Kowalik for Linux
+wheels, and contact Nathan Goldbaum about getting the Anaconda packages updated.
+
 
 After the release is uploaded to PyPI, you should send out an announcement
 e-mail to the yt mailing lists as well as other possibly interested mailing
-lists for all but bugfix releases. In addition, you should contact John ZuHone
-about uploading binary wheels to PyPI for Windows and OS X users and contact
-Nathan Goldbaum about getting the Anaconda packages updated.
+lists for all but bugfix releases.

diff -r 634cc55bf0668d551109b3a35850bb6c369b47b4 -r a816cf974397f25253f0f700a43c8a253933db28 doc/source/developing/testing.rst
--- a/doc/source/developing/testing.rst
+++ b/doc/source/developing/testing.rst
@@ -50,19 +50,19 @@
 
 If you are developing new functionality, it is sometimes more convenient to use
 the Nose command line interface, ``nosetests``. You can run the unit tests
-using ``nose`` by navigating to the base directory of the yt mercurial
+using ``nose`` by navigating to the base directory of the yt git
 repository and invoking ``nosetests``:
 
 .. code-block:: bash
 
-   $ cd $YT_HG
+   $ cd $YT_GIT
    $ nosetests
 
-where ``$YT_HG`` is the path to the root of the yt mercurial repository.
+where ``$YT_GIT`` is the path to the root of the yt git repository.
 
 If you want to specify a specific unit test to run (and not run the entire
 suite), you can do so by specifying the path of the test relative to the
-``$YT_HG/yt`` directory -- note that you strip off one yt more than you
+``$YT_GIT/yt`` directory -- note that you strip off one yt more than you
 normally would!  For example, if you want to run the plot_window tests, you'd
 run:
 
@@ -306,7 +306,7 @@
 
 .. code-block:: bash
 
-   $ cd $YT_HG
+   $ cd $YT_GIT
    $ nosetests --with-answer-testing --local --local-dir $HOME/Documents/test --answer-store --answer-name=local-tipsy yt.frontends.tipsy
 
 This command will create a set of local answers from the tipsy frontend tests

diff -r 634cc55bf0668d551109b3a35850bb6c369b47b4 -r a816cf974397f25253f0f700a43c8a253933db28 doc/source/faq/index.rst
--- a/doc/source/faq/index.rst
+++ b/doc/source/faq/index.rst
@@ -75,10 +75,10 @@
 
 .. code-block:: bash
 
-    cd $YT_HG
+    cd $YT_GIT
     python setup.py develop
 
-where ``$YT_HG`` is the path to the yt mercurial repository.
+where ``$YT_GIT`` is the path to the yt git repository.
 
 This error tends to occur when there are changes in the underlying cython
 files that need to be rebuilt, like after a major code update or in switching

diff -r 634cc55bf0668d551109b3a35850bb6c369b47b4 -r a816cf974397f25253f0f700a43c8a253933db28 doc/source/help/index.rst
--- a/doc/source/help/index.rst
+++ b/doc/source/help/index.rst
@@ -58,8 +58,8 @@
 loading yt either from the command line or from within python also fails, it
 may simply mean you need to rebuild the yt source (some of the c-code in yt
 needs to be rebuilt after major changes).  You can do this by navigating to
-the root of the yt mercurial repository.  If you installed with the all-in-one
-installer script, this is the ``yt-<machine>/src/yt-hg`` directory.  Then
+the root of the yt git repository.  If you installed with the all-in-one
+installer script, this is the ``yt-<machine>/src/yt-git`` directory.  Then
 execute these commands:
 
 .. code-block:: bash
@@ -112,13 +112,14 @@
 We've done our best to make the source clean, and it is easily searchable from
 your computer.
 
-If you have not done so already (see :ref:`source-installation`), clone a copy of the yt mercurial repository and make it the 'active' installation by doing
+If you have not done so already (see :ref:`source-installation`), clone a copy
+of the yt git repository and make it the 'active' installation by doing
 
 .. code-block:: bash
 
   python setup.py develop
 
-in the root directory of the yt mercurial repository.
+in the root directory of the yt git repository.
 
 .. note::
 
@@ -126,7 +127,7 @@
   script.  Building yt from source will not work if you do not have a C compiler
   installed.
 
-Once inside the yt mercurial repository, you can then search for the class,
+Once inside the yt git repository, you can then search for the class,
 function, or keyword which is giving you problems with ``grep -r *``, which will
 recursively search throughout the code base.  (For a much faster and cleaner
 experience, we recommend ``grin`` instead of ``grep -r *``.  To install ``grin``
@@ -137,7 +138,7 @@
 
 .. code-block:: bash
 
-  $ cd $YT-HG/yt
+  $ cd $YT_GIT/yt
   $ grep -r SlicePlot *         (or $ grin SlicePlot)
 
 This will print a number of locations in the yt source tree where ``SlicePlot``
@@ -216,13 +217,12 @@
 -------------------
 
 If you have gone through all of the above steps, and you're still encountering
-problems, then you have found a bug.
-To submit a bug report, you can either directly create one through the
-BitBucket `web interface <http://bitbucket.org/yt_analysis/yt/issues/new>`_,
-or you can use the command line ``yt bugreport`` to interactively create one.
-Alternatively, email the ``yt-users`` mailing list and we will construct a new
-ticket in your stead.  Remember to include the information
-about your problem you identified in :ref:`this step <isolate_and_document>`.
+problems, then you have found a bug.  To submit a bug report, you can either
+directly create one through the GitHub `web interface
+<http://github.org/yt-project/yt/issues/new>`_.  Alternatively, email the
+``yt-users`` mailing list and we will construct a new ticket in your stead.
+Remember to include the information about your problem you identified in
+:ref:`this step <isolate_and_document>`.
 
 Special Issues
 --------------

diff -r 634cc55bf0668d551109b3a35850bb6c369b47b4 -r a816cf974397f25253f0f700a43c8a253933db28 doc/source/installing.rst
--- a/doc/source/installing.rst
+++ b/doc/source/installing.rst
@@ -48,24 +48,23 @@
 
 .. _branches-of-yt:
 
-Branches of yt: ``yt``, ``stable``, and ``yt-2.x``
-++++++++++++++++++++++++++++++++++++++++++++++++++
+Branches of yt: ``master``, ``stable``, and ``yt-2.x``
+++++++++++++++++++++++++++++++++++++++++++++++++++++++
 
 Before you install yt, you must decide which branch (i.e. version) of the code
 you prefer to use:
 
-* ``yt`` -- The most up-to-date *development* version with the most current
-  features but sometimes unstable (the development version of the next ``yt-3.x``
-  release).
+* ``master`` -- The most up-to-date *development* version with the most current
+  features but sometimes unstable (the development version of the next release).
 * ``stable`` -- The latest stable release of ``yt-3.x``.
 * ``yt-2.x`` -- The last stable release of ``yt-2.x``.
 
 If this is your first time using the code, we recommend using ``stable``, unless
 you specifically need some piece of brand-new functionality only available in
-``yt`` or need to run an old script developed for ``yt-2.x``.  There were major
+``master`` or need to run an old script developed for ``yt-2.x``.  There were major
 API and functionality changes made in yt for version 3.0.  For a detailed
 description of the changes between versions 2.x (e.g. branch ``yt-2.x``) and 3.x
-(e.g. branches ``yt`` and ``stable``) see :ref:`yt3differences`.  Lastly, don't
+(e.g. branches ``master`` and ``stable``) see :ref:`yt3differences`.  Lastly, don't
 feel like you're locked into one branch when you install yt, because you can
 easily change the active branch by following the instructions in
 :ref:`switching-between-yt-versions`.
@@ -78,7 +77,7 @@
 Because installation of all of the interlocking parts necessary to install yt
 itself can be time-consuming, yt provides an all-in-one installation script
 which downloads and builds a fully-isolated installation of Python that includes
-NumPy, Matplotlib, H5py, Mercurial, and yt.
+NumPy, Matplotlib, H5py, git, and yt.
 
 The install script supports UNIX-like systems, including Linux, OS X, and most
 supercomputer and cluster environments. It is particularly suited for deployment
@@ -99,13 +98,13 @@
 
 .. code-block:: bash
 
-  $ wget http://bitbucket.org/yt_analysis/yt/raw/yt/doc/install_script.sh
+  $ wget https://raw.githubusercontent.com/yt-project/yt/master/doc/install_script.sh
 
 If you do not have ``wget``, the following should also work:
 
 .. code-block:: bash
 
-  $ curl -OL http://bitbucket.org/yt_analysis/yt/raw/yt/doc/install_script.sh
+  $ curl -OL https://raw.githubusercontent.com/yt-project/yt/master/doc/install_script.sh
 
 By default, the bash install script will create a python environment based on
 the `miniconda python distrubtion <http://conda.pydata.org/miniconda.html>`_,
@@ -119,7 +118,7 @@
 
 If you would like to build yt from source, you will need to edit the install
 script and set ``INST_YT_SOURCE=1`` near the top. This will clone a copy of the
-yt mercurial repository and build yt form source. The default is
+yt git repository and build yt form source. The default is
 ``INST_YT_SOURCE=0``, which installs yt from a binary conda package.
 
 The install script can also build python and all yt dependencies from source. To
@@ -314,28 +313,15 @@
 
 .. code-block:: bash
 
-  $ conda install -c conda-forge cython mercurial sympy ipython matplotlib netCDF4
+  $ conda install -c conda-forge cython git sympy ipython matplotlib netCDF4
 
 In addition, you will need a C compiler installed.
 
-.. note::
-  
-  If you are using a python3 environment, ``conda`` will not be able to install
-  *mercurial*, which works only with python2. You can circumvent this issue by
-  creating a dedicated python2 environment and symlinking *hg* in your current
-  environment:
-
-  .. code-block:: bash
-
-   $ export CONDA_DIR=$(python -c 'import sys; print(sys.executable.split("/bin/python")[0])')
-   $ conda create -y -n py27 python=2.7 mercurial
-   $ ln -s ${CONDA_DIR}/envs/py27/bin/hg ${CONDA_DIR}/bin
-
 Clone the yt repository with:
 
 .. code-block:: bash
 
-  $ hg clone https://bitbucket.org/yt_analysis/yt
+  $ git clone https://github.com/yt-project/yt
 
 Once inside the yt directory, update to the appropriate branch and
 run ``setup.py develop``. For example, the following commands will allow you
@@ -343,8 +329,7 @@
 
 .. code-block:: bash
 
-  $ hg pull
-  $ hg update yt
+  $ git checkout master
   $ python setup.py develop
 
 This will make sure you are running a version of yt corresponding to the
@@ -363,7 +348,7 @@
 
 .. code-block:: bash
 
-  $ hg clone https://bitbucket.org/MatthewTurk/rockstar
+  $ git clone https://github.com/yt-project/rockstar
   $ cd rockstar
   $ make lib
 
@@ -374,17 +359,17 @@
   $ cp librockstar.so /path/to/anaconda/lib
 
 Finally, you will need to recompile yt to enable the rockstar interface. Clone a
-copy of the yt mercurial repository (see :ref:`conda-source-build`), or navigate
+copy of the yt git repository (see :ref:`conda-source-build`), or navigate
 to a clone that you have already made, and do the following:
 
 .. code-block:: bash
 
-  $ cd /path/to/yt-hg
+  $ cd /path/to/yt-git
   $ ./clean.sh
   $ echo /path/to/rockstar > rockstar.cfg
   $ python setup.py develop
 
-Here ``/path/to/yt-hg`` is the path to your clone of the yt mercurial repository
+Here ``/path/to/yt-git`` is the path to your clone of the yt git repository
 and ``/path/to/rockstar`` is the path to your clone of Matt Turk's fork of
 rockstar.
 
@@ -411,8 +396,8 @@
 ^^^^^^^^^^^^^^^^^^^^^^^^
 
 Installation on 64-bit Microsoft Windows platforms is supported using Anaconda
-(see :ref:`anaconda-installation`). Also see :ref:`windows-developing` for
-details on how to build yt from source in Windows.
+(see :ref:`anaconda-installation`) and via ``pip``. Also see
+:ref:`windows-developing` for details on how to build yt from source in Windows.
 
 .. _source-installation:
 
@@ -439,7 +424,7 @@
 installed on your system. Right now, the dependencies to build yt from
 source include:
 
-- ``mercurial``
+- ``git``
 - A C compiler such as ``gcc`` or ``clang``
 - ``Python 2.7``, ``Python 3.4``, or ``Python 3.5``
 
@@ -454,15 +439,15 @@
 ``jupyter``, ``h5py`` (which in turn depends on the HDF5 library), ``scipy``, or
 ``astropy``,
 
-The source code for yt may be found on Bitbucket. If you prefer to install the
+The source code for yt may be found on GitHub. If you prefer to install the
 development version of yt instead of the latest stable release, you will need
-``mercurial`` to clone the official repo:
+``git`` to clone the official repo:
 
 .. code-block:: bash
 
-  $ hg clone https://bitbucket.org/yt_analysis/yt
+  $ git clone https://github.com/yt-project/yt
   $ cd yt
-  $ hg update yt
+  $ git checkout master
   $ python setup.py install --user --prefix=
 
 .. note::
@@ -487,14 +472,14 @@
 If you choose this installation method, you do not need to run any activation
 script since this will install yt into your global python environment.
 
-If you will be modifying yt, you can also make the clone of the yt mercurial
+If you will be modifying yt, you can also make the clone of the yt git
 repository the "active" installed copy:
 
 .. code-block:: bash
 
-  $ hg clone https://bitbucket.org/yt_analysis/yt
+  $ git clone https://github.com/yt-project/yt
   $ cd yt
-  $ hg update yt
+  $ git checkout master
   $ python setup.py develop --user --prefix=
 
 As above, you can leave off ``--user --prefix=`` if you want to install yt into
@@ -521,13 +506,13 @@
 
 or via your preferred method.   
 
-Keeping yt Updated via Mercurial
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+Keeping yt Updated via Git
+^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 If you want to maintain your yt installation via updates straight from the
-Bitbucket repository or if you want to do some development on your own, we
+GitHub repository or if you want to do some development on your own, we
 suggest you check out some of the :ref:`development docs <contributing-code>`,
-especially the sections on :ref:`Mercurial <mercurial-with-yt>` and
+especially the sections on :ref:`Git <git-with-yt>` and
 :ref:`building yt from source <building-yt>`.
 
 You can also make use of the following command to keep yt up to date from the
@@ -537,8 +522,8 @@
 
   $ yt update
 
-This will detect that you have installed yt from the mercurial repository, pull
-any changes from Bitbucket, and then recompile yt if necessary.
+This will detect that you have installed yt from the git repository, pull any
+changes from GitHub, and then recompile yt if necessary.
 
 .. _testing-installation:
 
@@ -564,7 +549,7 @@
 
 .. _switching-between-yt-versions:
 
-Switching versions of yt: ``yt-2.x``, ``stable``, and ``yt`` branches
+Switching versions of yt: ``yt-2.x``, ``stable``, and ``master`` branches
 ---------------------------------------------------------------------
 
 Here we explain how to switch between different development branches of yt. 
@@ -602,10 +587,10 @@
 
   ---
   Version = 3.3-dev
-  Changeset = d8eec89b2c86 (yt) tip
+  Changeset = d8eec89b2c86
   ---
 
-i.e. it refers to a specific changeset in the yt mercurial repository, then
+i.e. it refers to a specific changeset in the yt git repository, then
 you installed using ``INST_YT_SOURCE=1``.
 
 Conda-based installs (``INST_YT_SOURCE=0``)
@@ -616,15 +601,15 @@
 Source-based installs (``INST_YT_SOURCE=1``)
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
-You already have the mercurial repository, so you simply need to switch
-which version you're using.  Navigate to the root of the yt mercurial
-repository, update to the desired version, and rebuild the source (some of the
+You already have the git repository, so you simply need to switch
+which version you're using.  Navigate to the root of the yt git
+repository, check out the desired version, and rebuild the source (some of the
 C code requires a compilation step for big changes like this):
 
 .. code-block:: bash
 
-  $ cd yt-<machine>/src/yt-hg
-  $ hg update <desired-version>
+  $ cd yt-<machine>/src/yt-git
+  $ git checkout <desired version>
   $ python setup.py develop
 
 Valid versions to jump to are described in :ref:`branches-of-yt`.
@@ -636,22 +621,21 @@
 ++++++++++++++++++++++++++++++++++++++++++++++++++
 
 If you have installed python via ``pip``, remove
-any extant installations of yt on your system and clone the source mercurial
+any extant installations of yt on your system and clone the git
 repository of yt as described in :ref:`source-installation`.
 
 .. code-block:: bash
 
   $ pip uninstall yt
-  $ hg clone https://bitbucket.org/yt_analysis/yt
+  $ git clone https://github.com/yt-project/yt
 
-Now, to switch between versions, you need to navigate to the root of
-the mercurial yt repository. Use mercurial to
-update to the appropriate version and recompile.
+Now, to switch between versions, you need to navigate to the root of the git yt
+repository. Use git to update to the appropriate version and recompile.
 
 .. code-block:: bash
 
   $ cd yt
-  $ hg update <desired-version>
+  $ git checkout <desired-version>
   $ python setup.py install --user --prefix=
 
 Valid versions to jump to are described in :ref:`branches-of-yt`).

diff -r 634cc55bf0668d551109b3a35850bb6c369b47b4 -r a816cf974397f25253f0f700a43c8a253933db28 doc/source/quickstart/index.rst
--- a/doc/source/quickstart/index.rst
+++ b/doc/source/quickstart/index.rst
@@ -25,11 +25,11 @@
 
 If you're running the tutorial from your own system and you do not already have
 the yt repository, the easiest way to get the repository is to clone it using
-mercurial:
+git:
 
 .. code-block:: bash
 
-   hg clone https://bitbucket.org/yt_analysis/yt
+   git clone https://github.com/yt-project/yt
 
 Now start the IPython notebook from within the repository (we presume you have
 yt installed):

diff -r 634cc55bf0668d551109b3a35850bb6c369b47b4 -r a816cf974397f25253f0f700a43c8a253933db28 doc/source/reference/command-line.rst
--- a/doc/source/reference/command-line.rst
+++ b/doc/source/reference/command-line.rst
@@ -74,7 +74,7 @@
 First, we'll discuss plotting from the command line, then we will give a brief
 summary of the functionality provided by each command line subcommand. This
 example uses the :code:`DD0010/moving7_0010` dataset distributed in the yt
-mercurial repository.
+git repository.
 
 First let's see what our options are for plotting:
 

diff -r 634cc55bf0668d551109b3a35850bb6c369b47b4 -r a816cf974397f25253f0f700a43c8a253933db28 doc/source/visualizing/unstructured_mesh_rendering.rst
--- a/doc/source/visualizing/unstructured_mesh_rendering.rst
+++ b/doc/source/visualizing/unstructured_mesh_rendering.rst
@@ -29,7 +29,7 @@
 
 .. code-block:: bash
 
-  wget http://bitbucket.org/yt_analysis/yt/raw/yt/doc/install_script.sh
+  wget https://raw.githubusercontent.com/yt-project/yt/master/doc/install_script.sh
 
 and then run like so:
 
@@ -64,7 +64,7 @@
 the unstructured mesh rendering capability. Once again, if embree is installed in a
 location that is not part of your default search path, you must tell yt where to find it.
 There are a number of ways to do this. One way is to again manually pass in the flags
-when running the setup script in the yt-hg directory:
+when running the setup script in the yt-git directory:
 
 .. code-block:: bash
 
@@ -77,7 +77,7 @@
 
    python setup.py develop
 
-as usual. Finally, if you create a file called embree.cfg in the yt-hg directory with
+as usual. Finally, if you create a file called embree.cfg in the yt-git directory with
 the location of the embree installation, the setup script will find this and use it,
 provided EMBREE_DIR is not set. An example embree.cfg file could like this:
 


https://bitbucket.org/yt_analysis/yt/commits/00f28d0dd2a4/
Changeset:   00f28d0dd2a4
Branch:      yt
User:        ngoldbaum
Date:        2017-04-26 17:25:02+00:00
Summary:     Merged in ngoldbaum/yt (pull request #2590)

Update documentation for github transition

Approved-by: Alexander Lindsay <al007 at illinois.edu>
Approved-by: Matt Turk <matthewturk at gmail.com>
Affected #:  16 files

diff -r 9f8358adf4f137025473facd8738c8df01c34017 -r 00f28d0dd2a446c30cf8ed7cd91fa699bb0cb135 doc/source/about/index.rst
--- a/doc/source/about/index.rst
+++ b/doc/source/about/index.rst
@@ -16,7 +16,7 @@
 it has grown to handle any kind of data represented in a 2D or 3D volume.
 yt is an Python-based open source project and is open for anyone to use or
 contribute code.  The entire source code and history is available to all
-at https://bitbucket.org/yt_analysis/yt .
+at http://github.com/yt-project/yt .
 
 .. _who-is-yt:
 
@@ -31,7 +31,7 @@
 `our members website. <http://yt-project.org/members.html>`_
 
 For an up-to-date list of everyone who has contributed to the yt codebase,
-see the current `CREDITS <http://bitbucket.org/yt_analysis/yt/src/yt/CREDITS>`_ file.
+see the current `CREDITS <https://github.com/yt-project/yt/blob/master/CREDITS>`_ file.
 For a more detailed breakup of contributions made by individual users, see out
 `Open HUB page <https://www.openhub.net/p/yt_amr/contributors?query=&sort=commits>`_.
 

diff -r 9f8358adf4f137025473facd8738c8df01c34017 -r 00f28d0dd2a446c30cf8ed7cd91fa699bb0cb135 doc/source/analyzing/analysis_modules/halo_mass_function.rst
--- a/doc/source/analyzing/analysis_modules/halo_mass_function.rst
+++ b/doc/source/analyzing/analysis_modules/halo_mass_function.rst
@@ -4,7 +4,7 @@
 
    This module has been deprecated as it no longer functions correctly and is
    unmaintained.  The code has been moved to the `yt attic
-   <https://bitbucket.org/yt_analysis/yt_attic>`__. If you'd like to take it
+   <https://github.com/yt-project/yt_attic>`__. If you'd like to take it
    over, please do!
 
 Halo Mass Function

diff -r 9f8358adf4f137025473facd8738c8df01c34017 -r 00f28d0dd2a446c30cf8ed7cd91fa699bb0cb135 doc/source/analyzing/analysis_modules/star_analysis.rst
--- a/doc/source/analyzing/analysis_modules/star_analysis.rst
+++ b/doc/source/analyzing/analysis_modules/star_analysis.rst
@@ -3,7 +3,7 @@
 .. note::
 
    This module has been deprecated as it is unmaintained.  The code has been
-   moved to the `yt attic <https://bitbucket.org/yt_analysis/yt_attic>`__.
+   moved to the `yt attic <https://github.com/yt-project/yt_attic>`__.
    If you'd like to take it over, please do!
 
 Star Particle Analysis

diff -r 9f8358adf4f137025473facd8738c8df01c34017 -r 00f28d0dd2a446c30cf8ed7cd91fa699bb0cb135 doc/source/analyzing/analysis_modules/sunrise_export.rst
--- a/doc/source/analyzing/analysis_modules/sunrise_export.rst
+++ b/doc/source/analyzing/analysis_modules/sunrise_export.rst
@@ -3,7 +3,7 @@
 .. note::
 
    This module has been deprecated as it is unmaintained.  The code has been
-   moved to the `yt attic <https://bitbucket.org/yt_analysis/yt_attic>`__.
+   moved to the `yt attic <https://github.com/yt-project/yt_attic>`__.
    If you'd like to take it over, please do!
 
 Exporting to Sunrise

diff -r 9f8358adf4f137025473facd8738c8df01c34017 -r 00f28d0dd2a446c30cf8ed7cd91fa699bb0cb135 doc/source/analyzing/analysis_modules/two_point_functions.rst
--- a/doc/source/analyzing/analysis_modules/two_point_functions.rst
+++ b/doc/source/analyzing/analysis_modules/two_point_functions.rst
@@ -3,7 +3,7 @@
 .. note::
 
    This module has been deprecated as it is unmaintained.  The code has been
-   moved to the `yt attic <https://bitbucket.org/yt_analysis/yt_attic>`__.
+   moved to the `yt attic <https://github.com/yt-project/yt_attic>`__.
    If you'd like to take it over, please do!
 
 Two Point Functions

diff -r 9f8358adf4f137025473facd8738c8df01c34017 -r 00f28d0dd2a446c30cf8ed7cd91fa699bb0cb135 doc/source/analyzing/units/index.rst
--- a/doc/source/analyzing/units/index.rst
+++ b/doc/source/analyzing/units/index.rst
@@ -12,8 +12,8 @@
 and execute the documentation interactively, you need to download the repository
 and start the IPython notebook.
 
-You will then need to navigate to :code:`$YT_HG/doc/source/units` (where $YT_HG
-is the location of a clone of the yt mercurial repository), and then start an
+You will then need to navigate to :code:`$YT_GIT/doc/source/units` (where $YT_GIT
+is the location of a clone of the yt git repository), and then start an
 IPython notebook server:
 
 .. code:: bash

diff -r 9f8358adf4f137025473facd8738c8df01c34017 -r 00f28d0dd2a446c30cf8ed7cd91fa699bb0cb135 doc/source/developing/building_the_docs.rst
--- a/doc/source/developing/building_the_docs.rst
+++ b/doc/source/developing/building_the_docs.rst
@@ -19,9 +19,9 @@
 include a recipe in the cookbook section, or it could simply be adding a note
 in the relevant docs text somewhere.
 
-The documentation exists in the main mercurial code repository for yt in the
-``doc`` directory (i.e. ``$YT_HG/doc/source`` where ``$YT_HG`` is the path of
-the yt mercurial repository).  It is organized hierarchically into the main
+The documentation exists in the main code repository for yt in the
+``doc`` directory (i.e. ``$YT_GIT/doc/source`` where ``$YT_GIT`` is the path of
+the yt git repository).  It is organized hierarchically into the main
 categories of:
 
 * Visualizing

diff -r 9f8358adf4f137025473facd8738c8df01c34017 -r 00f28d0dd2a446c30cf8ed7cd91fa699bb0cb135 doc/source/developing/extensions.rst
--- a/doc/source/developing/extensions.rst
+++ b/doc/source/developing/extensions.rst
@@ -40,10 +40,10 @@
 
 A template for starting an extension module (or converting an existing set of
 code to an extension module) can be found at
-https://bitbucket.org/yt_analysis/yt_extension_template .
+https://github.com/yt-project/yt_extension_template .
 
 To get started, download a zipfile of the template (
-https://bitbucket.org/yt_analysis/yt_extension_template/get/tip.zip ) and
+https://github.com/yt-project/yt_extension_template/archive/master.zip ) and
 follow the directions in ``README.md`` to modify the metadata.
 
 Distributing Extensions

diff -r 9f8358adf4f137025473facd8738c8df01c34017 -r 00f28d0dd2a446c30cf8ed7cd91fa699bb0cb135 doc/source/developing/releasing.rst
--- a/doc/source/developing/releasing.rst
+++ b/doc/source/developing/releasing.rst
@@ -12,9 +12,8 @@
   once a month. These releases should contain only fixes for bugs discovered in
   earlier releases and should not contain new features or API changes. Bugfix
   releases should increment the ``PATCH`` version number. Bugfix releases should
-  *not* be generated by merging from the ``yt`` branch, instead bugfix pull
-  requests should be manually backported using the PR backport script, described
-  below. Version ``3.2.2`` is a bugfix release.
+  *not* be generated by merging from the ``master`` branch, instead bugfix pull
+  requests should be manually backported. Version ``3.2.2`` is a bugfix release.
 
 * Minor releases
 
@@ -25,7 +24,7 @@
   backwards-incompatible changes and should not change APIs.  If an API change
   is deemed to be necessary, the old API should continue to function but might
   trigger deprecation warnings. Minor releases should happen by merging the
-  ``yt`` branch into the ``stable`` branch. Minor releases should increment the
+  ``master`` branch into the ``stable`` branch. Minor releases should increment the
   ``MINOR`` version number and reset the ``PATCH`` version number to zero.
   Version ``3.3.0`` is a minor release.
 
@@ -36,7 +35,7 @@
   include arbitrary changes to the library. Major version releases should only
   happen after extensive discussion and vetting among the developer and user
   community. Like minor releases, a major release should happen by merging the
-  ``yt`` branch into the ``stable`` branch. Major releases should increment the
+  ``master`` branch into the ``stable`` branch. Major releases should increment the
   ``MAJOR`` version number and reset the ``MINOR`` and ``PATCH`` version numbers
   to zero. If it ever happens, version ``4.0.0`` will be a major release.
 
@@ -49,99 +48,25 @@
 As described above, bugfix releases are regularly scheduled updates for minor
 releases to ensure fixes for bugs make their way out to users in a timely
 manner. Since bugfix releases should not include new features, we do not issue
-bugfix releases by simply merging from the development ``yt`` branch into the
-``stable`` branch.  Instead, we make use of the ``pr_backport.py`` script to
-manually cherry-pick bugfixes from the from ``yt`` branch onto the ``stable``
-branch.
-
-The backport script issues interactive prompts to backport individual pull
-requests to the ``stable`` branch in a temporary clone of the main yt mercurial
-repository on bitbucket. The script is written this way to to avoid editing
-history in a clone of the repository that a developer uses for day-to-day work
-and to avoid mixing work-in-progress changes with changes that have made their
-way to the "canonical" yt repository on bitbucket.
-
-Rather than automatically manipulating the temporary repository by scripting
-mercurial commands using ``python-hglib``, the script must be "operated" by a
-human who is ready to think carefully about what the script is telling them
-to do. Most operations will merely require copy/pasting a suggested mercurial
-command. However, some changes will require manual backporting.
-
-To run the backport script, first open two terminal windows. The first window
-will be used to run the backport script. The second terminal will be used to
-manipulate a temporary clone of the yt mercurial repository. In the first
-window, navigate to the ``scripts`` directory at the root of the yt repository
-and run the backport script,
-
-.. code-block:: bash
-
-   $ cd $YT_HG/scripts
-   $ python pr_backport.py
-
-You will then need to wait for about a minute (depending on the speed of your
-internet connection and bitbucket's servers) while the script makes a clone of
-the main yt repository and then gathers information about pull requests that
-have been merged since the last tagged release. Once this step finishes, you
-will be prompted to navigate to the temporary folder in a new separate terminal
-session. Do so, and then hit the enter key in the original terminal session.
-
-For each pull request in the set of pull requests that were merged since the
-last tagged release that were pointed at the "main" line of development
-(e.g. not the ``experimental`` bookmark), you will be prompted by the script
-with the PR number, title, description, and a suggested mercurial
-command to use to backport the pull request. If the pull request consists of a
-single changeset, you will be prompted to use ``hg graft``. If it contains more
-than one changeset, you will be prompted to use ``hg rebase``. Note that
-``rebase`` is an optional extension for mercurial that is not turned on by
-default. To enable it, add a section like the following in your ``.hgrc`` file:
-
-.. code-block:: none
-
-   [extensions]
-   rebase=
-
-Since ``rebase`` is bundled with core mercurial, you do not need to specify a
-path to the rebase extension, just say ``rebase=`` and mercurial will find the
-version of ``rebase`` bundled with mercurial. Note also that mercurial does not
-automatically update to the tip of the rebased head after executing ``hg
-rebase`` so you will need to manually issue ``hg update stable`` to move your
-working directory to the new head of the stable branch. The backport script
-should prompt you with a suggestion to update as well.
+bugfix releases by simply merging from the development ``master`` branch into
+the ``stable`` branch.  Instead, we manually cherry-pick bugfixes from the from
+``master`` branch onto the ``stable`` branch.
 
 If the pull request contains merge commits, you must take care to *not* backport
-commits that merge with the main line of development on the ``yt`` branch. Doing
+commits that merge with the main line of development on the ``master`` branch. Doing
 so may bring unrelated changes, including new features, into a bugfix
-release. If the pull request you'd like to backport contains merge commits, the
-backport script should warn you to be extra careful.
+release.
 
-Once you've finished backporting, the script will let you know that you are done
-and warn you to push your work. The temporary repository you have been working
-with will be deleted as soon as the script exits, so take care to push your work
-on the ``stable`` branch to your fork on bitbucket. Once you've pushed to your
-fork, you will be able to issue a pull request containing the backported fixes
-just like any other yt pull request.
+Once you've finished backporting push your work to Github. Once you've pushed to
+your fork, you will be able to issue a pull request containing the backported
+fixes just like any other yt pull request.
 
 Doing a Minor or Major Release
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 This is much simpler than a bugfix release.  All that needs to happen is the
-``yt`` branch must get merged into the ``stable`` branch, and any conflicts that
-happen must be resolved, almost certainly in favor of the yt branch. This can
-happen either using a merge tool like ``vimdiff`` and ``kdiff3`` or by telling
-mercurial to write merge markers. If you prefer merge markers, the following
-configuration options should be turned on in your ``hgrc`` to get more detail
-during the merge:
-
-.. code-block:: none
-
-   [ui]
-   merge = internal:merge3
-   mergemarkers = detailed
-
-The first option tells mercurial to write merge markers that show the state of
-the conflicted region of the code on both sides of the merge as well as the
-"base" most recent common ancestor changeset. The second option tells mercurial
-to add extra information about the code near the merge markers.
+``master`` branch must get merged into the ``stable`` branch, and any conflicts
+that happen must be resolved.
 
 
 Incrementing Version Numbers and Tagging a Release
@@ -174,35 +99,42 @@
 
 .. code-block:: bash
 
-   hg tag <tag-name>
+   git tag <tag-name>
 
 Where ``<tag-name>`` follows the project's naming scheme for tags
-(e.g. ``yt-3.2.1``). Commit the tag, and you should be ready to upload the
-release to pypi.
+(e.g. ``yt-3.2.1``). Once you are done, you will need to push the
+tag to github::
+
+  git push origin --tags
 
-If you are doing a minor or major version number release, you will also need to
-update back to the development branch and update the development version numbers
-in the same files.
+This assumes that you have configured the remote ``origin`` to point at the main
+yt git repository. If you are doing a minor or major version number release, you
+will also need to update back to the development branch and update the
+development version numbers in the same files.
 
 
 Uploading to PyPI
 ~~~~~~~~~~~~~~~~~
 
 To actually upload the release to the Python Package Index, you just need to
-issue the following command:
+issue the following commands:
 
 .. code-block:: bash
 
-   python setup.py sdist upload -r https://pypi.python.org/pypi
+   python setup.py sdist
+   twine upload dist/*
 
 You will be prompted for your PyPI credentials and then the package should
 upload. Note that for this to complete successfully, you will need an account on
 PyPI and that account will need to be registered as an "owner" of the yt
-package. Right now there are three owners: Matt Turk, Britton Smith, and Nathan
-Goldbaum.
+package. Right now there are five owners: Matt Turk, Britton Smith, Nathan
+Goldbaum, John ZuHone, and Kacper Kowalik. In addition, you should attempt to
+upload the yt package along with compiled binary wheel packages for various
+platforms that we support.  You should contact John ZuHone about uploading
+binary wheels to PyPI for Windows and OS X users, Kacper Kowalik for Linux
+wheels, and contact Nathan Goldbaum about getting the Anaconda packages updated.
+
 
 After the release is uploaded to PyPI, you should send out an announcement
 e-mail to the yt mailing lists as well as other possibly interested mailing
-lists for all but bugfix releases. In addition, you should contact John ZuHone
-about uploading binary wheels to PyPI for Windows and OS X users and contact
-Nathan Goldbaum about getting the Anaconda packages updated.
+lists for all but bugfix releases.

diff -r 9f8358adf4f137025473facd8738c8df01c34017 -r 00f28d0dd2a446c30cf8ed7cd91fa699bb0cb135 doc/source/developing/testing.rst
--- a/doc/source/developing/testing.rst
+++ b/doc/source/developing/testing.rst
@@ -50,19 +50,19 @@
 
 If you are developing new functionality, it is sometimes more convenient to use
 the Nose command line interface, ``nosetests``. You can run the unit tests
-using ``nose`` by navigating to the base directory of the yt mercurial
+using ``nose`` by navigating to the base directory of the yt git
 repository and invoking ``nosetests``:
 
 .. code-block:: bash
 
-   $ cd $YT_HG
+   $ cd $YT_GIT
    $ nosetests
 
-where ``$YT_HG`` is the path to the root of the yt mercurial repository.
+where ``$YT_GIT`` is the path to the root of the yt git repository.
 
 If you want to specify a specific unit test to run (and not run the entire
 suite), you can do so by specifying the path of the test relative to the
-``$YT_HG/yt`` directory -- note that you strip off one yt more than you
+``$YT_GIT/yt`` directory -- note that you strip off one yt more than you
 normally would!  For example, if you want to run the plot_window tests, you'd
 run:
 
@@ -306,7 +306,7 @@
 
 .. code-block:: bash
 
-   $ cd $YT_HG
+   $ cd $YT_GIT
    $ nosetests --with-answer-testing --local --local-dir $HOME/Documents/test --answer-store --answer-name=local-tipsy yt.frontends.tipsy
 
 This command will create a set of local answers from the tipsy frontend tests

diff -r 9f8358adf4f137025473facd8738c8df01c34017 -r 00f28d0dd2a446c30cf8ed7cd91fa699bb0cb135 doc/source/faq/index.rst
--- a/doc/source/faq/index.rst
+++ b/doc/source/faq/index.rst
@@ -75,10 +75,10 @@
 
 .. code-block:: bash
 
-    cd $YT_HG
+    cd $YT_GIT
     python setup.py develop
 
-where ``$YT_HG`` is the path to the yt mercurial repository.
+where ``$YT_GIT`` is the path to the yt git repository.
 
 This error tends to occur when there are changes in the underlying cython
 files that need to be rebuilt, like after a major code update or in switching

diff -r 9f8358adf4f137025473facd8738c8df01c34017 -r 00f28d0dd2a446c30cf8ed7cd91fa699bb0cb135 doc/source/help/index.rst
--- a/doc/source/help/index.rst
+++ b/doc/source/help/index.rst
@@ -58,8 +58,8 @@
 loading yt either from the command line or from within python also fails, it
 may simply mean you need to rebuild the yt source (some of the c-code in yt
 needs to be rebuilt after major changes).  You can do this by navigating to
-the root of the yt mercurial repository.  If you installed with the all-in-one
-installer script, this is the ``yt-<machine>/src/yt-hg`` directory.  Then
+the root of the yt git repository.  If you installed with the all-in-one
+installer script, this is the ``yt-<machine>/src/yt-git`` directory.  Then
 execute these commands:
 
 .. code-block:: bash
@@ -112,13 +112,14 @@
 We've done our best to make the source clean, and it is easily searchable from
 your computer.
 
-If you have not done so already (see :ref:`source-installation`), clone a copy of the yt mercurial repository and make it the 'active' installation by doing
+If you have not done so already (see :ref:`source-installation`), clone a copy
+of the yt git repository and make it the 'active' installation by doing
 
 .. code-block:: bash
 
   python setup.py develop
 
-in the root directory of the yt mercurial repository.
+in the root directory of the yt git repository.
 
 .. note::
 
@@ -126,7 +127,7 @@
   script.  Building yt from source will not work if you do not have a C compiler
   installed.
 
-Once inside the yt mercurial repository, you can then search for the class,
+Once inside the yt git repository, you can then search for the class,
 function, or keyword which is giving you problems with ``grep -r *``, which will
 recursively search throughout the code base.  (For a much faster and cleaner
 experience, we recommend ``grin`` instead of ``grep -r *``.  To install ``grin``
@@ -137,7 +138,7 @@
 
 .. code-block:: bash
 
-  $ cd $YT-HG/yt
+  $ cd $YT_GIT/yt
   $ grep -r SlicePlot *         (or $ grin SlicePlot)
 
 This will print a number of locations in the yt source tree where ``SlicePlot``
@@ -216,13 +217,12 @@
 -------------------
 
 If you have gone through all of the above steps, and you're still encountering
-problems, then you have found a bug.
-To submit a bug report, you can either directly create one through the
-BitBucket `web interface <http://bitbucket.org/yt_analysis/yt/issues/new>`_,
-or you can use the command line ``yt bugreport`` to interactively create one.
-Alternatively, email the ``yt-users`` mailing list and we will construct a new
-ticket in your stead.  Remember to include the information
-about your problem you identified in :ref:`this step <isolate_and_document>`.
+problems, then you have found a bug.  To submit a bug report, you can either
+directly create one through the GitHub `web interface
+<http://github.org/yt-project/yt/issues/new>`_.  Alternatively, email the
+``yt-users`` mailing list and we will construct a new ticket in your stead.
+Remember to include the information about your problem you identified in
+:ref:`this step <isolate_and_document>`.
 
 Special Issues
 --------------

diff -r 9f8358adf4f137025473facd8738c8df01c34017 -r 00f28d0dd2a446c30cf8ed7cd91fa699bb0cb135 doc/source/installing.rst
--- a/doc/source/installing.rst
+++ b/doc/source/installing.rst
@@ -48,24 +48,23 @@
 
 .. _branches-of-yt:
 
-Branches of yt: ``yt``, ``stable``, and ``yt-2.x``
-++++++++++++++++++++++++++++++++++++++++++++++++++
+Branches of yt: ``master``, ``stable``, and ``yt-2.x``
+++++++++++++++++++++++++++++++++++++++++++++++++++++++
 
 Before you install yt, you must decide which branch (i.e. version) of the code
 you prefer to use:
 
-* ``yt`` -- The most up-to-date *development* version with the most current
-  features but sometimes unstable (the development version of the next ``yt-3.x``
-  release).
+* ``master`` -- The most up-to-date *development* version with the most current
+  features but sometimes unstable (the development version of the next release).
 * ``stable`` -- The latest stable release of ``yt-3.x``.
 * ``yt-2.x`` -- The last stable release of ``yt-2.x``.
 
 If this is your first time using the code, we recommend using ``stable``, unless
 you specifically need some piece of brand-new functionality only available in
-``yt`` or need to run an old script developed for ``yt-2.x``.  There were major
+``master`` or need to run an old script developed for ``yt-2.x``.  There were major
 API and functionality changes made in yt for version 3.0.  For a detailed
 description of the changes between versions 2.x (e.g. branch ``yt-2.x``) and 3.x
-(e.g. branches ``yt`` and ``stable``) see :ref:`yt3differences`.  Lastly, don't
+(e.g. branches ``master`` and ``stable``) see :ref:`yt3differences`.  Lastly, don't
 feel like you're locked into one branch when you install yt, because you can
 easily change the active branch by following the instructions in
 :ref:`switching-between-yt-versions`.
@@ -78,7 +77,7 @@
 Because installation of all of the interlocking parts necessary to install yt
 itself can be time-consuming, yt provides an all-in-one installation script
 which downloads and builds a fully-isolated installation of Python that includes
-NumPy, Matplotlib, H5py, Mercurial, and yt.
+NumPy, Matplotlib, H5py, git, and yt.
 
 The install script supports UNIX-like systems, including Linux, OS X, and most
 supercomputer and cluster environments. It is particularly suited for deployment
@@ -99,13 +98,13 @@
 
 .. code-block:: bash
 
-  $ wget http://bitbucket.org/yt_analysis/yt/raw/yt/doc/install_script.sh
+  $ wget https://raw.githubusercontent.com/yt-project/yt/master/doc/install_script.sh
 
 If you do not have ``wget``, the following should also work:
 
 .. code-block:: bash
 
-  $ curl -OL http://bitbucket.org/yt_analysis/yt/raw/yt/doc/install_script.sh
+  $ curl -OL https://raw.githubusercontent.com/yt-project/yt/master/doc/install_script.sh
 
 By default, the bash install script will create a python environment based on
 the `miniconda python distrubtion <http://conda.pydata.org/miniconda.html>`_,
@@ -119,7 +118,7 @@
 
 If you would like to build yt from source, you will need to edit the install
 script and set ``INST_YT_SOURCE=1`` near the top. This will clone a copy of the
-yt mercurial repository and build yt form source. The default is
+yt git repository and build yt form source. The default is
 ``INST_YT_SOURCE=0``, which installs yt from a binary conda package.
 
 The install script can also build python and all yt dependencies from source. To
@@ -314,28 +313,15 @@
 
 .. code-block:: bash
 
-  $ conda install -c conda-forge cython mercurial sympy ipython matplotlib netCDF4
+  $ conda install -c conda-forge cython git sympy ipython matplotlib netCDF4
 
 In addition, you will need a C compiler installed.
 
-.. note::
-  
-  If you are using a python3 environment, ``conda`` will not be able to install
-  *mercurial*, which works only with python2. You can circumvent this issue by
-  creating a dedicated python2 environment and symlinking *hg* in your current
-  environment:
-
-  .. code-block:: bash
-
-   $ export CONDA_DIR=$(python -c 'import sys; print(sys.executable.split("/bin/python")[0])')
-   $ conda create -y -n py27 python=2.7 mercurial
-   $ ln -s ${CONDA_DIR}/envs/py27/bin/hg ${CONDA_DIR}/bin
-
 Clone the yt repository with:
 
 .. code-block:: bash
 
-  $ hg clone https://bitbucket.org/yt_analysis/yt
+  $ git clone https://github.com/yt-project/yt
 
 Once inside the yt directory, update to the appropriate branch and
 run ``setup.py develop``. For example, the following commands will allow you
@@ -343,8 +329,7 @@
 
 .. code-block:: bash
 
-  $ hg pull
-  $ hg update yt
+  $ git checkout master
   $ python setup.py develop
 
 This will make sure you are running a version of yt corresponding to the
@@ -363,7 +348,7 @@
 
 .. code-block:: bash
 
-  $ hg clone https://bitbucket.org/MatthewTurk/rockstar
+  $ git clone https://github.com/yt-project/rockstar
   $ cd rockstar
   $ make lib
 
@@ -374,17 +359,17 @@
   $ cp librockstar.so /path/to/anaconda/lib
 
 Finally, you will need to recompile yt to enable the rockstar interface. Clone a
-copy of the yt mercurial repository (see :ref:`conda-source-build`), or navigate
+copy of the yt git repository (see :ref:`conda-source-build`), or navigate
 to a clone that you have already made, and do the following:
 
 .. code-block:: bash
 
-  $ cd /path/to/yt-hg
+  $ cd /path/to/yt-git
   $ ./clean.sh
   $ echo /path/to/rockstar > rockstar.cfg
   $ python setup.py develop
 
-Here ``/path/to/yt-hg`` is the path to your clone of the yt mercurial repository
+Here ``/path/to/yt-git`` is the path to your clone of the yt git repository
 and ``/path/to/rockstar`` is the path to your clone of Matt Turk's fork of
 rockstar.
 
@@ -411,8 +396,8 @@
 ^^^^^^^^^^^^^^^^^^^^^^^^
 
 Installation on 64-bit Microsoft Windows platforms is supported using Anaconda
-(see :ref:`anaconda-installation`). Also see :ref:`windows-developing` for
-details on how to build yt from source in Windows.
+(see :ref:`anaconda-installation`) and via ``pip``. Also see
+:ref:`windows-developing` for details on how to build yt from source in Windows.
 
 .. _source-installation:
 
@@ -439,7 +424,7 @@
 installed on your system. Right now, the dependencies to build yt from
 source include:
 
-- ``mercurial``
+- ``git``
 - A C compiler such as ``gcc`` or ``clang``
 - ``Python 2.7``, ``Python 3.4``, or ``Python 3.5``
 
@@ -454,15 +439,15 @@
 ``jupyter``, ``h5py`` (which in turn depends on the HDF5 library), ``scipy``, or
 ``astropy``,
 
-The source code for yt may be found on Bitbucket. If you prefer to install the
+The source code for yt may be found on GitHub. If you prefer to install the
 development version of yt instead of the latest stable release, you will need
-``mercurial`` to clone the official repo:
+``git`` to clone the official repo:
 
 .. code-block:: bash
 
-  $ hg clone https://bitbucket.org/yt_analysis/yt
+  $ git clone https://github.com/yt-project/yt
   $ cd yt
-  $ hg update yt
+  $ git checkout master
   $ python setup.py install --user --prefix=
 
 .. note::
@@ -487,14 +472,14 @@
 If you choose this installation method, you do not need to run any activation
 script since this will install yt into your global python environment.
 
-If you will be modifying yt, you can also make the clone of the yt mercurial
+If you will be modifying yt, you can also make the clone of the yt git
 repository the "active" installed copy:
 
 .. code-block:: bash
 
-  $ hg clone https://bitbucket.org/yt_analysis/yt
+  $ git clone https://github.com/yt-project/yt
   $ cd yt
-  $ hg update yt
+  $ git checkout master
   $ python setup.py develop --user --prefix=
 
 As above, you can leave off ``--user --prefix=`` if you want to install yt into
@@ -521,13 +506,13 @@
 
 or via your preferred method.   
 
-Keeping yt Updated via Mercurial
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+Keeping yt Updated via Git
+^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 If you want to maintain your yt installation via updates straight from the
-Bitbucket repository or if you want to do some development on your own, we
+GitHub repository or if you want to do some development on your own, we
 suggest you check out some of the :ref:`development docs <contributing-code>`,
-especially the sections on :ref:`Mercurial <mercurial-with-yt>` and
+especially the sections on :ref:`Git <git-with-yt>` and
 :ref:`building yt from source <building-yt>`.
 
 You can also make use of the following command to keep yt up to date from the
@@ -537,8 +522,8 @@
 
   $ yt update
 
-This will detect that you have installed yt from the mercurial repository, pull
-any changes from Bitbucket, and then recompile yt if necessary.
+This will detect that you have installed yt from the git repository, pull any
+changes from GitHub, and then recompile yt if necessary.
 
 .. _testing-installation:
 
@@ -564,7 +549,7 @@
 
 .. _switching-between-yt-versions:
 
-Switching versions of yt: ``yt-2.x``, ``stable``, and ``yt`` branches
+Switching versions of yt: ``yt-2.x``, ``stable``, and ``master`` branches
 ---------------------------------------------------------------------
 
 Here we explain how to switch between different development branches of yt. 
@@ -602,10 +587,10 @@
 
   ---
   Version = 3.3-dev
-  Changeset = d8eec89b2c86 (yt) tip
+  Changeset = d8eec89b2c86
   ---
 
-i.e. it refers to a specific changeset in the yt mercurial repository, then
+i.e. it refers to a specific changeset in the yt git repository, then
 you installed using ``INST_YT_SOURCE=1``.
 
 Conda-based installs (``INST_YT_SOURCE=0``)
@@ -616,15 +601,15 @@
 Source-based installs (``INST_YT_SOURCE=1``)
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
-You already have the mercurial repository, so you simply need to switch
-which version you're using.  Navigate to the root of the yt mercurial
-repository, update to the desired version, and rebuild the source (some of the
+You already have the git repository, so you simply need to switch
+which version you're using.  Navigate to the root of the yt git
+repository, check out the desired version, and rebuild the source (some of the
 C code requires a compilation step for big changes like this):
 
 .. code-block:: bash
 
-  $ cd yt-<machine>/src/yt-hg
-  $ hg update <desired-version>
+  $ cd yt-<machine>/src/yt-git
+  $ git checkout <desired version>
   $ python setup.py develop
 
 Valid versions to jump to are described in :ref:`branches-of-yt`.
@@ -636,22 +621,21 @@
 ++++++++++++++++++++++++++++++++++++++++++++++++++
 
 If you have installed python via ``pip``, remove
-any extant installations of yt on your system and clone the source mercurial
+any extant installations of yt on your system and clone the git
 repository of yt as described in :ref:`source-installation`.
 
 .. code-block:: bash
 
   $ pip uninstall yt
-  $ hg clone https://bitbucket.org/yt_analysis/yt
+  $ git clone https://github.com/yt-project/yt
 
-Now, to switch between versions, you need to navigate to the root of
-the mercurial yt repository. Use mercurial to
-update to the appropriate version and recompile.
+Now, to switch between versions, you need to navigate to the root of the git yt
+repository. Use git to update to the appropriate version and recompile.
 
 .. code-block:: bash
 
   $ cd yt
-  $ hg update <desired-version>
+  $ git checkout <desired-version>
   $ python setup.py install --user --prefix=
 
 Valid versions to jump to are described in :ref:`branches-of-yt`).

diff -r 9f8358adf4f137025473facd8738c8df01c34017 -r 00f28d0dd2a446c30cf8ed7cd91fa699bb0cb135 doc/source/quickstart/index.rst
--- a/doc/source/quickstart/index.rst
+++ b/doc/source/quickstart/index.rst
@@ -25,11 +25,11 @@
 
 If you're running the tutorial from your own system and you do not already have
 the yt repository, the easiest way to get the repository is to clone it using
-mercurial:
+git:
 
 .. code-block:: bash
 
-   hg clone https://bitbucket.org/yt_analysis/yt
+   git clone https://github.com/yt-project/yt
 
 Now start the IPython notebook from within the repository (we presume you have
 yt installed):

diff -r 9f8358adf4f137025473facd8738c8df01c34017 -r 00f28d0dd2a446c30cf8ed7cd91fa699bb0cb135 doc/source/reference/command-line.rst
--- a/doc/source/reference/command-line.rst
+++ b/doc/source/reference/command-line.rst
@@ -74,7 +74,7 @@
 First, we'll discuss plotting from the command line, then we will give a brief
 summary of the functionality provided by each command line subcommand. This
 example uses the :code:`DD0010/moving7_0010` dataset distributed in the yt
-mercurial repository.
+git repository.
 
 First let's see what our options are for plotting:
 

diff -r 9f8358adf4f137025473facd8738c8df01c34017 -r 00f28d0dd2a446c30cf8ed7cd91fa699bb0cb135 doc/source/visualizing/unstructured_mesh_rendering.rst
--- a/doc/source/visualizing/unstructured_mesh_rendering.rst
+++ b/doc/source/visualizing/unstructured_mesh_rendering.rst
@@ -29,7 +29,7 @@
 
 .. code-block:: bash
 
-  wget http://bitbucket.org/yt_analysis/yt/raw/yt/doc/install_script.sh
+  wget https://raw.githubusercontent.com/yt-project/yt/master/doc/install_script.sh
 
 and then run like so:
 
@@ -64,7 +64,7 @@
 the unstructured mesh rendering capability. Once again, if embree is installed in a
 location that is not part of your default search path, you must tell yt where to find it.
 There are a number of ways to do this. One way is to again manually pass in the flags
-when running the setup script in the yt-hg directory:
+when running the setup script in the yt-git directory:
 
 .. code-block:: bash
 
@@ -77,7 +77,7 @@
 
    python setup.py develop
 
-as usual. Finally, if you create a file called embree.cfg in the yt-hg directory with
+as usual. Finally, if you create a file called embree.cfg in the yt-git directory with
 the location of the embree installation, the setup script will find this and use it,
 provided EMBREE_DIR is not set. An example embree.cfg file could like this:

Repository URL: https://bitbucket.org/yt_analysis/yt/

--

This is a commit notification from bitbucket.org. You are receiving
this because you have the service enabled, addressing the recipient of
this email.



More information about the yt-svn mailing list