[yt-svn] commit/yt-doc: 5 new changesets
commits-noreply at bitbucket.org
commits-noreply at bitbucket.org
Sat Feb 23 03:21:59 PST 2013
5 new commits in yt-doc:
https://bitbucket.org/yt_analysis/yt-doc/commits/9cf70ce6c544/
changeset: 9cf70ce6c544
user: MatthewTurk
date: 2013-02-22 15:36:36
summary: Rewriting the developer documentation.
This removes a considerable amount of information in favor of pointing at
external resources and providing a streamlined approach to how to contribute
changes. Additionally, it includes information from YTEP-0008 about
requirements for code contribution, and an outline of how to submit changes.
affected #: 1 file
diff -r f115d10758f79d1780cc7335e4571a3e68446303 -r 9cf70ce6c54483d05453842ed833b16b2f1b4176 source/advanced/developing.rst
--- a/source/advanced/developing.rst
+++ b/source/advanced/developing.rst
@@ -27,13 +27,44 @@
* http://hgbook.red-bean.com/read/
* http://mercurial.selenic.com/
-Keep in touch, and happy hacking! We also provide doc/coding_styleguide.txt
-and an example of a fiducial docstring in doc/docstring_example.txt. Please
+The commands that are essential for using mercurial include:
+
+ * ``hg commit`` which commits changes in the working directory to the
+ repository, creating a new "changeset object."
+ * ``hg add`` which adds a new file to be tracked by mercurial. This does
+ not change the working directory.
+ * ``hg pull`` which pulls (from an optional path specifier) changeset
+ objects from a remote source. The working directory is not modified.
+ * ``hg push`` which sends (to an optional path specifier) changeset objects
+ to a remote source. The working directory is not modified.
+ * ``hg log`` which shows a log of all changeset objects in the current
+ repository. Use ``-g`` to show a graph of changeset objects and their
+ relationship.
+ * ``hg update`` which (with an optional "revision" specifier) updates the
+ state of the working directory to match a changeset object in the
+ repository.
+ * ``hg merge`` which combines two changesets to make a union of their lines
+ of development. This updates the working directory.
+
+Keep in touch, and happy hacking! We also provide `doc/coding_styleguide.txt`
+and an example of a fiducial docstring in `doc/docstring_example.txt`. Please
read them before hacking on the codebase, and feel free to email any of the
mailing lists for help with the codebase.
+.. _bootstrap-dev:
+
+Submitting Changes
+------------------
+
+We provide a brief introduction to submitting changes here. yt thrives on the
+strength of its communities ( http://arxiv.org/abs/1301.7064 has further
+discussion) and we encourage contributions from any user. While we do not
+discuss in detail version control, mercurial or the advanced usage of
+BitBucket, we do provide an outline of how to submit changes and we are happy
+to provide further assistance or guidance.
+
Licensing
----------
++++++++++
All contributed code must be GPL-compatible; we ask that you consider licensing
under the GPL version 3, but we will consider submissions of code that are
@@ -41,149 +72,152 @@
still want to contribute, just drop me a line and I'll put a link on the main
wiki page to wherever you like!
-.. _bootstrap-dev:
+Requirements for Code Submission
+++++++++++++++++++++++++++++++++
-Bootstrapping Your Development Environment
-------------------------------------------
+Modifications to the code typically fall into one of three categories, each of
+which have different requirements for acceptance into the code base. These
+requirements are in place for a few reasons -- to make sure that the code is
+maintainable, testable, and that we can easily include information about
+changes in changelogs during the release procedure. (See `YTEP-0008
+<https://ytep.readthedocs.org/en/latest/YTEPs/YTEP-0008.html>`_ for more
+detail.)
-Getting up and running with developing yt can be somewhat daunting. To assist
-with that, yt provides a 'bootstrap' script that handles a couple of the more
-annoying items on the checklist -- getting set up on BitBucket, creating a
-pasteboard, and adding a couple handy extensions to Mercurial. As time goes
-on, we hope that we will be able to use the extensions added during this
-process to both issue forks and pull requests to BitBucket, enabling much more
-rapid and easy development. To run the script, on the command line type::
+ * New Features
- $ yt bootstrap_dev
+ * New unit tests (possibly new answer tests)
+ * Docstrings for public API
+ * Addition of new feature to the narrative documentation
+ * Addition of cookbook recipe
+ * Issue created on issue tracker, to ensure this is added to the changelog
-.. note:: Although the bootstrap script will manipulate and modify your
- ``~/.hgrc`` and possibly your BitBucket repositories, it will ask before
- doing anything. You should feel free to Ctrl-C out at any time. If you
- wish to inspect the source code of the bootstrap script, it is located in
- ``yt/utilities/command_line.py`` in the function ``do_bootstrap``.
+ * Extension or Breakage of API in Existing Features
-Here is the list of items that the script will attempt to accomplish, along
-with a brief motivation of each.
+ * Update existing narrative docs and docstrings
+ * Update existing cookbook recipes
+ * Modify of create new unit tests
+ * Issue created on issue tracker, to ensure this is added to the changelog
- #. **Ensure that the yt-supplemental repository is checked out into
- ``YT_DEST``**. To make sure that the extensions we're going to use to
- facilitate mercurial usage are checked out and ready to go, we optionally
- clone the repository here. If you've run with a recent install script,
- this won't be necessary.
- #. **Create an ``~/.hgrc`` if it does not exist, and add your username**.
- Because Mercurial's changesets are all signed with a username, we make sure
- that your username is set in your ``~/.hgrc``. The script will prompt you
- for what you would like it to be. When committing to yt, we strongly
- prefer you set it to be of the form "Firstname Lastname
- <email at address.com>". If you want to skip this step, simply set the
- configuration value yourself in ``~/.hgrc``. Any of the above-listed
- tutorials on hg can help with this.
- #. **Create a BitBucket user if you do not have one**. Because yt is developed
- on the source code hosting site `BitBucket <http://bitbucket.org/>`_, we
- make sure that you're set up to have a username there. You should not feel
- obliged to do this step if you do not want to, but it provides a much more
- convenient mechanism for sharing changes, reporting issues, and
- contributing to the yt wiki. It also provides a location to host an
- unlimited number of publicly accessible repositories, if you wish to share
- other pieces of code with other users. (See :ref:`included-hg-extensions`
- for more information about this.)
- #. **Turn on the ``hgbb`` and ``cedit`` extensions in ``~/.hgrc``**. This sets
- up these extensions, described below. It amounts to adding them to the
- ``[extensions]`` section and adding your BitBucket username to the ``[bb]``
- section.
- #. **Create a pasteboard repository**. This is the step that is probably the
- most fun. yt now comes with pasteboard facilities. A pasteboard is like a
- pastebin, except designed to be more persistent -- it's a versioned
- repository that contains scripts with descriptions, which are automatically
- posted to the web. You can download from your pasteboard programmatically
- using the ``yt pasteboard`` command, and you can download from other
- pasteboards using the ``yt pasteboard_grab`` command. This repository will
- be created on BitBucket, and will be of the name
- ``your_username.bitbucket.org``, which is also the web address it will be
- hosted at.
+ * Bug fixes
-And that's it! If you run into any trouble, please email ``yt-dev`` with your
-concerns, questions or error messages. This should put you in a good place to
-start developing yt efficiently.
+ * Unit test is encouraged, to ensure breakage does not happen again in the
+ future.
+ * Issue created on issue tracker, to ensure this is added to the changelog
-.. _included-hg-extensions:
+When submitting, you will be asked to make sure that your changes meet all of
+these requirements. They are pretty easy to meet, and we're also happy to help
+out with them. In :ref:`code-style-guide` there is a list of handy tips for
+how to structure and write your code.
-Included hg Extensions
-^^^^^^^^^^^^^^^^^^^^^^
+How to Use Mercurial with yt
+++++++++++++++++++++++++++++
-Mercurial is written in Python, and as such is easily extensible by scripts.
-It comes with a number of extensions (descriptions of which you can find on the
-Mercurial wiki under `UsingExtensions
-<http://mercurial.selenic.com/wiki/UsingExtensions>`_. Some of my favorites
-are transplant, extdiff, color and progress.) yt now comes bundled with a few
-additional extensions, which should make interacting with other repositories
-and BitBucket a bit easier.
+This document doesn't cover detailed mercurial use, but on IRC we are happy to
+walk you through any troubles you might have. Here are some suggestions
+for using mercurial with yt:
-The first of these is ``hgbb``, which is a Mercurial extension that interacts
-with the public-facing BitBucket-API. It adds several commands, and you can
-get information about these commands by typing: ::
+ * Named branches are probably to be avoided. Try using bookmarks (``hg
+ bookmark``) to track work. (`More
+ <http://mercurial.selenic.com/wiki/Bookmarks>`_)
+ * Make sure you set a username in your ``~/.hgrc`` before you commit any
+ changes! All of the tutorials above will describe how to do this as one of
+ the very first steps.
+ * When contributing changes, you might be asked to make a handful of
+ modifications to your source code. We'll work through how to do this with
+ you, and try to make it as painless as possible.
+ * Please avoid deleting your yt forks, as that eliminates the code review
+ process from BitBucket's website.
+ * In all likelihood, you only need one fork. To keep it in sync, you can
+ sync from the website. (See Bitbucket's `Blog Post
+ <http://blog.bitbucket.org/2013/02/04/syncing-and-merging-come-to-bitbucket/>`_
+ about this.)
+ * If you run into any troubles, stop by IRC (see :ref:`irc`) or the mailing
+ list.
- $ hg help COMMANDNAME
+Building yt
++++++++++++
-It also adds the URL-specifier ``bb://USERNAME/reponame`` for convenience; this
-means you can reference ``sskory/yt`` to see Stephen's yt fork, for instance.
+If you have made changes to any C or Cython (``.pyx``) modules, you have to
+rebuild yt. If your changes have exclusively been to Python modules, you will
+not need to re-build, but (see below) you may need to re-install.
-The most fun of these commands are:
-
-``bbcreate``
- This creates a new repository on BitBucket and clones it locally. This is
- really cool and very convenient when developing.
-``bbforks``
- This shows the status of all known forks of a given repository, and can show
- the incoming and outgoing changesets. You can use this to see what
- changesets are different between yours and another repository.
-
-As time goes on, and as the BitBucket API is expanded to cover things like
-forking and pull requests, we hope that this extension will also expand.
-
-The other extension that is currently bundled with yt is the ``cedit``
-extension. This adds the ability to add, remove and set configuration options
-from the command line. This brings with it the ability to add new sources for
-Mercurial repositories -- for instance, if you become aware of a different
-source repository you want to be able to pull from, you can add it as a source
-and then pull from it directly.
-
-The new commands you may be interested in are:
-
-``cedit``
- Set an option in either the local or the global configuration file.
-``addsource``
- Add a mercurial repo to the ``[paths]`` section of the local repository.
-
-How To Get The Source Code
---------------------------
-
-If you just want to *look* at the source code, you already have it on your
-computer. Go to the directory where you ran the install_script.sh, then
-go to ``$YT_DEST/src/yt-hg`` . In this directory are a number of
-subdirectories with different components of the code, although most of them
-are in the yt subdirectory. Feel free to explore here. If you're looking
-for a specific file or function in the yt source code, use the unix find
-command:
+If you are running from a clone that is executable in-place (i.e., has been
+installed via the installation script or you have run ``setup.py develop``) you
+can rebuild these modules by executing:
.. code-block:: bash
- $ find <DIRECTORY_TREE_TO_SEARCH> -name '<FILENAME>'
+ python2.7 setup.py develop
-The above command will find the FILENAME in any subdirectory in the
-DIRECTORY_TREE_TO_SEARCH. Alternatively, if you're looking for a function
-call or a keyword in an unknown file in a directory tree, try:
+If you have previously "installed" via ``setup.py install`` you have to
+re-install:
.. code-block:: bash
- $ grep -R <KEYWORD_TO_FIND><DIRECTORY_TREE_TO_SEARCH>
+ python2.7 setup.py install
-This can be very useful for tracking down functions in the yt source.
+Only one of these two options is needed. yt may require you to specify the
+location to libpng and hdf5. This can be done through files named ``png.cfg``
+and ``hdf5.cfg``. If you are using the installation script, these will already
+exist.
-While you can edit this source code and execute it on your local machine,
-you will be unable to share your work with others in the community (or
-get feedback on your work). If you want to submit your modifications to the
-yt project, follow the directions below.
+Making and Sharing Changes
+++++++++++++++++++++++++++
+
+The simplest way to submit changes to yt is to commit changes in your
+``$YT_DEST/src/yt-hg`` directory, fork the repository on BitBucket, push the
+changesets to your fork, and then issue a pull request. If you will be
+developing much more in-depth features for yt, you will also
+likely want to edit the paths in your
+
+Here's a more detailed flowchart of how to submit changes.
+
+ #. If you have used the installation script, the source code for yt can be
+ found in ``$YT_DEST/src/yt-hg``. (Below, in :ref:`reading-source`,
+ we describe how to find items of interest.) Edit the source file you are
+ interested in and test your changes. (See :ref:`testing` for more
+ information.)
+ #. Fork yt on BitBucket. (This step only has to be done once.) You can do
+ this at: https://bitbucket.org/yt_analysis/yt/fork . Call this repository
+ ``yt``.
+ #. Commit these changes, using ``hg commit``. This can take an argument
+ which is a series of filenames, if you have some changes you do not want
+ to commit.
+ #. Push your changes to your new fork using the command::
+
+ hg push https://bitbucket.org/YourUsername/yt/
+
+
+ If you end up doing considerable development, you can set an alias in the
+ file ``.hg/hgrc`` to point to this path.
+ #. Issue a pull request at
+ https://bitbucket.org/YourUsername/yt/pull-request/new
+
+During the course of your pull request you may be asked to make changes. These
+changes may be related to style issues, correctness issues, or even requesting
+tests. The process for responding to pull request code review is relatively
+straightforward.
+
+ #. Make requested changes, or leave a comment indicating why you don't think
+ they should be made.
+ #. Commit those changes to your local repository.
+ #. Push the changes to your fork::
+
+ hg push https://bitbucket.org/YourUsername/yt/
+
+ #. Update your pull request by visiting
+ https://bitbucket.org/YourUsername/yt/pull-request/new
+
+How to Write Documentation
+++++++++++++++++++++++++++
+
+The process for writing documentation is identical to the above, except that
+instead of ``yt_analysis/yt`` you should be forking and pushing to
+``yt_analysis/yt-doc``. All the source for the documentation is written in
+`Sphinx <http://sphinx-doc.org/>`_, which uses ReST for markup.
+
+Cookbook recipes go in ``source/cookbook/`` and must be added to one of the
+``.rst`` files in that directory.
How To Get The Source Code For Editing
--------------------------------------
@@ -194,15 +228,14 @@
the steps above for bootstrapping your development (to assure you have a
bitbucket account, etc.)
-In order to access the source code for yt, we ask that you make a "fork" of
-the main yt repository on bitbucket. A fork is simply an exact copy of the
-main repository (along with its history) that you will now own and can make
+In order to modify the source code for yt, we ask that you make a "fork" of the
+main yt repository on bitbucket. A fork is simply an exact copy of the main
+repository (along with its history) that you will now own and can make
modifications as you please. You can create a personal fork by visiting the yt
-bitbucket webpage at https://bitbucket.org/yt_analysis/yt/wiki/Home . After
-logging in, you should see an option near the top right labeled "fork".
-Click this option, and then click the fork repository button on the subsequent
-page. You now have a forked copy of the yt repository for your own personal
-use.
+bitbucket webpage at https://bitbucket.org/yt_analysis/yt/ . After logging in,
+you should see an option near the top right labeled "fork". Click this option,
+and then click the fork repository button on the subsequent page. You now have
+a forked copy of the yt repository for your own personal modification.
This forked copy exists on the bitbucket repository, so in order to access
it locally, follow the instructions at the top of that webpage for that
@@ -255,89 +288,16 @@
This will rebuild all C modules as well.
-How To Submit Changes
----------------------
-
-So now you've made some cool modifications to the yt source, and you want
-to share it with the rest of the community. But wait, how can we trust
-that your modifications aren't going to break the rest of yt (after all, mine
-have several times!) So we have you submit your code using the "pull request"
-mechanism on bitbucket. A pull request basically submits your modifications
-to the repository, but they need to be reviewed/tested by other users of
-the code before they're pulled into the main repository.
-
-When you're ready to submit them to the main repository, simply go to the
-bitbucket page for your personal fork of the yt-analysis yt repository,
-and click the button to issue a pull request (at top right):
-
-Make sure you notify ``yt_analysis`` and put in a little description. That'll
-notify the core developers that you've got something ready to submit, and we
-will review it and (hopefully!) merge it in. If it goes well, you may end up
-with push access to the main repository.
-
-How To Download/Test Someone Else's Pull Request
-------------------------------------------------
-
-Go to the bitbucket yt repository webpage. Follow the instructions for
-cloning the repo. You must clone a new version of yt on your local machine
-(for the purposes of testing) by running a command like:
-
-.. code-block:: bash
-
- $ hg clone https://bitbucket.org/yt_analysis/yt yt-testing
-
-At the top of the webpage, click on the pull request tab, and click on
-the specific pull request you want to test.
-
-Click on the changeset hash (e.g. 3ec2c245c827) just below the name of
-the pull request and the name of the user who submitted the pull request.
-
-This page has the details of the changesets that were made in the pull
-request. To view how these results are different from the existing
-repository (i.e. the one that you already cloned), click the "compare fork"
-button in the upper right of the page.
-
-This page has instructions on how to merge this pull request into your
-local cloned copy of yt (so that you can test it on your own machine). In
-this case, it should give you these commands (because it recognizes that the
-pull request came from the submitter's forked branch of yt):
-
-.. code-block:: bash
-
- $ hg pull -r yt https://bitbucket.org/<USERNAME>/<REPOSITORY_NAME>
- $ hg update yt
- $ hg merge yt
-
-After running these commands on your local testing copy of yt, you will
-want to use this testing yt as your default (at least temporarily) so that
-you can test how this version of yt behaves with whatever testing scripts.
-You can "activate" it by going into the new yt-testing directory and running:
-
-.. code-block:: bash
-
- $ ``cp yt-old/src/yt-hg/*.cfg yt-testing``
- $ cd yt-testing
- $ python setup.py develop
-
-Now do whatever tests that you need to do on the pull-requested version
-of yt, using your normal ``from yt.mods import *`` or whatever. When you are
-done testing this version of yt, just get rid of the yt-testing directory
-tree, and "reactivate" your old version of yt:
-
-.. code-block:: bash
-
- $ rm -rf yt-testing
- $ cd yt-old/src/yt-hg
- $ python setup.py develop
-
-If you want to accept the changeset or reject it (if you have sufficient
-privileges) or comment on it, you can do so from its pull request webpage.
+.. _reading-source:
How To Read The Source Code
---------------------------
-yt is organized into several sub-packages, each of which governs a different
-conceptual regime.
+If you just want to *look* at the source code, you already have it on your
+computer. Go to the directory where you ran the install_script.sh, then
+go to ``$YT_DEST/src/yt-hg`` . In this directory are a number of
+subdirectories with different components of the code, although most of them
+are in the yt subdirectory. Feel free to explore here.
``frontends``
This is where interfaces to codes are created. Within each subdirectory of
@@ -375,50 +335,25 @@
All broadly useful code that doesn't clearly fit in one of the other
categories goes here.
-How To Use Branching
---------------------
-If you are planning on making a large change to the code base that may not be
-ready for many commits, or if you are planning on breaking some functionality
-and rewriting it, you are encouraged to create a new named branch. You can
-mark the current repository as a new named branch by executing:
+If you're looking for a specific file or function in the yt source code, use
+the unix find command:
.. code-block:: bash
- $ hg branch new_feature_name
+ $ find <DIRECTORY_TREE_TO_SEARCH> -name '<FILENAME>'
-The next commit and all subsequent commits will be contained within that named
-branch. At this point, add your branch on the `ExistingBranches
-<http://yt-project.org/wiki/ExistingBranches>`_ wiki page.
-
-To merge changes in from another branch, you would execute:
+The above command will find the FILENAME in any subdirectory in the
+DIRECTORY_TREE_TO_SEARCH. Alternatively, if you're looking for a function
+call or a keyword in an unknown file in a directory tree, try:
.. code-block:: bash
- $ hg merge some_other_branch
+ $ grep -R <KEYWORD_TO_FIND><DIRECTORY_TREE_TO_SEARCH>
-Note also that you can use revision specifiers instead of
-``some_other_branch``. When you are ready to merge back into the main branch,
-execute this process:
+This can be very useful for tracking down functions in the yt source.
-.. code-block:: bash
-
- $ hg merge name_of_main_branch
- $ hg commit --close-branch
- $ hg up -C name_of_main_branch
- $ hg merge name_of_feature_branch
- $ hg commit
-
-When you execute the merge you may have to resolve conflicts. Once you resolve
-conflicts in a file, you can mark it as resolved by doing:
-
-.. code-block:: bash
-
- $ hg resolve -m path/to/conflicting/file.py
-
-Please be careful when resolving conflicts in files.
-
-Once your branch has been merged in, mark it as closed on the wiki page.
+.. _code-style-guide:
Code Style Guide
----------------
@@ -469,6 +404,9 @@
* The usage of the ``**kwargs`` construction should be avoided. If they
cannot be avoided, they must be explained, even if they are only to be
passed on to a nested function.
+ * Constructor APIs should be kept as *simple* as possible.
+ * Variable names should be short but descriptive.
+ * No global variabless!
Variable Names and Enzo-isms
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
@@ -495,78 +433,3 @@
+ Do not assume that the domain runs from 0 to 1. This is not true
everywhere.
-
- * Variable names should be short but descriptive.
- * No globals!
-
-.. _project-ideas:
-
-Project Ideas
--------------
-
-There are lots of places in ``yt`` where new extensions could be added, or new
-functionality put in place. Here are a few.
-
-Adding Support for a New Code
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-``yt`` strives to be a general-purpose analysis tool for astrophysical data.
-To that end, we'd like to short up our support for codes besides Enzo, as well
-as ensure that the other codes we support -- Orion, Tiger, etc. -- are
-well-supported.
-
-The :ref:`creating_frontend` page describes the process of adding support for a
-new code to ``yt``. Please feel free to use it as a reference, but if you would
-like some assistance, drop a line to one of the mailing lists (see
-:ref:`mailing-list`) for more help.
-
-GUIs and Interactive Exploration
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-The 1.7 release adds some functionality for interactive exploration of data,
-but this could be greatly expanded. In particular, the volume rendering could
-be converted to a hardware based volume renderer (some simple sketches of this
-exist in the mercurial repository), the VTK interface could be improved, and
-the various components that form the interface for examining data could be
-integrated.
-
-Simulated Observations
-^^^^^^^^^^^^^^^^^^^^^^
-
-The functionality to construct simulated observations is an end goal for
-``yt``. Transforming simulation output into mock observations is the Stanley
-Cup.
-
-Bug Fixes
-^^^^^^^^^
-
-If you have simple bug fixes, please feel free to attach them to a ticket on
-the `bug tracker <http://yt-project.org/newticket/>`_ (you might have to
-`register <http://yt-project.org/register>`_ first) or to email them to one
-of the developers directly. We're always happy to hear about the things we've
-done wrong, and how you've fixed them!
-
-Fields and Extensions
-^^^^^^^^^^^^^^^^^^^^^
-
-``yt`` comes with a bunch of derived fields. However, if you have constructed
-some that add interesting analysis quantities, please feel free to send them to
-one of the developers!
-
-Additionally, if you have a sub-module that extends ``yt`` in a fun or exciting
-way, we'd be very happy to include it.
-
-.. _free_repo_space:
-
-Analysis Code and Examples
-^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-Because ``yt`` can be a bit difficult to become fully acquainted with, we
-encourage you to share your analysis scripts. Specifically, we will provide
-you with free repository space to store any analysis scripts that went into the
-writing of a paper. Through this, we hope to build up a library not only of
-usage-cases, but of real-world examples of plot generation and data analysis.
-
-If you are interested in submitting your scripts, please contact Matt Turk at
-``matthewturk at gmail.com``, or just create a repository on BitBucket and send
-over the URL!
https://bitbucket.org/yt_analysis/yt-doc/commits/b8b30e82f267/
changeset: b8b30e82f267
user: MatthewTurk
date: 2013-02-22 17:05:19
summary: Typo fix!
affected #: 1 file
diff -r 9cf70ce6c54483d05453842ed833b16b2f1b4176 -r b8b30e82f267d42be8a0dcdf2962fafaf39ab2bc source/advanced/developing.rst
--- a/source/advanced/developing.rst
+++ b/source/advanced/developing.rst
@@ -406,7 +406,7 @@
passed on to a nested function.
* Constructor APIs should be kept as *simple* as possible.
* Variable names should be short but descriptive.
- * No global variabless!
+ * No global variables!
Variable Names and Enzo-isms
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
https://bitbucket.org/yt_analysis/yt-doc/commits/dd9ccbb9d841/
changeset: dd9ccbb9d841
user: MatthewTurk
date: 2013-02-22 17:36:16
summary: Responding to Britton's suggestions
affected #: 1 file
diff -r b8b30e82f267d42be8a0dcdf2962fafaf39ab2bc -r dd9ccbb9d84117dd543ffa68d6650dd2973b6575 source/advanced/developing.rst
--- a/source/advanced/developing.rst
+++ b/source/advanced/developing.rst
@@ -85,7 +85,7 @@
* New Features
- * New unit tests (possibly new answer tests)
+ * New unit tests (possibly new answer tests) (See :ref:`testing`)
* Docstrings for public API
* Addition of new feature to the narrative documentation
* Addition of cookbook recipe
@@ -95,7 +95,7 @@
* Update existing narrative docs and docstrings
* Update existing cookbook recipes
- * Modify of create new unit tests
+ * Modify of create new unit tests (See :ref:`testing`)
* Issue created on issue tracker, to ensure this is added to the changelog
* Bug fixes
@@ -116,9 +116,8 @@
walk you through any troubles you might have. Here are some suggestions
for using mercurial with yt:
- * Named branches are probably to be avoided. Try using bookmarks (``hg
- bookmark``) to track work. (`More
- <http://mercurial.selenic.com/wiki/Bookmarks>`_)
+ * Named branches are to be avoided. Try using bookmarks (``hg bookmark``) to
+ track work. (`More <http://mercurial.selenic.com/wiki/Bookmarks>`_)
* Make sure you set a username in your ``~/.hgrc`` before you commit any
changes! All of the tutorials above will describe how to do this as one of
the very first steps.
@@ -183,6 +182,9 @@
#. Commit these changes, using ``hg commit``. This can take an argument
which is a series of filenames, if you have some changes you do not want
to commit.
+ #. If your changes include new functionality or cover an untested area of the
+ code, add a test. (See :ref:`testing` for more information.) Commit
+ these changes as well.
#. Push your changes to your new fork using the command::
hg push https://bitbucket.org/YourUsername/yt/
https://bitbucket.org/yt_analysis/yt-doc/commits/19600c58ca4b/
changeset: 19600c58ca4b
user: MatthewTurk
date: 2013-02-22 20:07:31
summary: Removing Workshop from top bar of quick reference
affected #: 1 file
diff -r dd9ccbb9d84117dd543ffa68d6650dd2973b6575 -r 19600c58ca4b5702ab656601d4cb6415f03b39a8 source/index.rst
--- a/source/index.rst
+++ b/source/index.rst
@@ -74,17 +74,6 @@
<tr valign="top"><td width="25%"><p>
- <a href="workshop.html">Workshop Tutorials</a>
- </p>
- </td>
- <td width="75%">
- <p class="linkdescr">Videos, slides and scripts from the 2012 workshop covering many aspects of yt, from beginning to advanced.</p>
- </td>
- </tr>
-
- <tr valign="top">
- <td width="25%">
- <p><a href="cookbook/index.html">The Cookbook</a></p></td>
https://bitbucket.org/yt_analysis/yt-doc/commits/5f94c4690226/
changeset: 5f94c4690226
user: MatthewTurk
date: 2013-02-23 12:21:52
summary: Merged in MatthewTurk/yt-doc (pull request #85)
Rewriting the developer documentation.
affected #: 2 files
Diff not available.
Repository URL: https://bitbucket.org/yt_analysis/yt-doc/
--
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