Ask Solem 14 lat temu
rodzic
commit
30ce278ad5

+ 115 - 113
Changelog

@@ -52,7 +52,7 @@ Fixes
 
 * snapshots: Fixed race condition leading to loss of events.
 
-* celeryd: Reject tasks with an eta that cannot be converted to timestamp.
+* celeryd: Reject tasks with an eta that cannot be converted to a time stamp.
 
     See issue #209
 
@@ -69,7 +69,7 @@ Fixes
 * control command `dump_scheduled`: was using old .info attribute
 
 * :program:`celeryd-multi`: Fixed `set changed size during iteration` bug
-    occuring in the restart command.
+    occurring in the restart command.
 
 * celeryd: Accidentally tried to use additional command line arguments.
 
@@ -90,7 +90,7 @@ Fixes
   to `cache.set` is deprecated by the memcached libraries,
   so we now automatically cast to :class:`int`.
 
-* unittests: No longer emits logging and warnings in test output.
+* unit tests: No longer emits logging and warnings in test output.
 
 .. _v211-news:
 
@@ -106,7 +106,7 @@ News
     :program:`celerybeat`.  All output to `stdout` and `stderr` will be
     redirected to the current logger if enabled.
 
-    :setting:`CELERY_REDIRECT_STDOUTS_LEVEL` decides the loglevel used and is
+    :setting:`CELERY_REDIRECT_STDOUTS_LEVEL` decides the log level used and is
     :const:`WARNING` by default.
 
 * Added :setting:`CELERYBEAT_SCHEDULER` setting.
@@ -235,8 +235,8 @@ News
 
     .. code-block:: python
 
-        CELERY_AMQP_TASK_RESULT_EXPIRES = 30 * 60  # 30 mins
-        CELERY_AMQP_TASK_RESULT_EXPIRES = 0.80     # 800 ms
+        CELERY_AMQP_TASK_RESULT_EXPIRES = 30 * 60  # 30 minutes.
+        CELERY_AMQP_TASK_RESULT_EXPIRES = 0.80     # 800 ms.
 
 * celeryev: Event Snapshots
 
@@ -274,11 +274,11 @@ News
     There's also a Debian init.d script for :mod:`~celery.bin.celeryev` available,
     see :doc:`cookbook/daemonizing` for more information.
 
-    New command line argments to celeryev:
+    New command line arguments to celeryev:
 
         * :option:`-c|--camera`: Snapshot camera class to use.
-        * :option:`--logfile|-f`: Logfile
-        * :option:`--loglevel|-l`: Loglevel
+        * :option:`--logfile|-f`: Log file
+        * :option:`--loglevel|-l`: Log level
         * :option:`--maxrate|-r`: Shutter rate limit.
         * :option:`--freq|-F`: Shutter frequency
 
@@ -342,7 +342,7 @@ News
     We now configure the root logger instead of only configuring
     our custom logger. In addition we don't hijack
     the multiprocessing logger anymore, but instead use a custom logger name
-    for different apps:
+    for different applications:
 
     =====================================  =====================================
     **Application**                        **Logger Name**
@@ -398,19 +398,20 @@ News
 * celeryd: now emits a warning if running as the root user (euid is 0).
 
 * :func:`celery.messaging.establish_connection`: Ability to override defaults
-  used using kwarg "defaults".
+  used using keyword argument "defaults".
 
 * celeryd: Now uses `multiprocessing.freeze_support()` so that it should work
   with **py2exe**, **PyInstaller**, **cx_Freeze**, etc.
 
 * celeryd: Now includes more metadata for the :state:`STARTED` state: PID and
-  hostname of the worker that started the task.
+  host name of the worker that started the task.
 
     See issue #181
 
-* subtask: Merge addititional keyword args to `subtask()` into task kwargs.
+* subtask: Merge additional keyword arguments to `subtask()` into task keyword
+  arguments.
 
-    e.g:
+    e.g.:
 
         >>> s = subtask((1, 2), {"foo": "bar"}, baz=1)
         >>> s.args
@@ -481,7 +482,7 @@ News
 * :meth:`TaskSetResult.join <celery.result.TaskSetResult.join>`:
   Added 'propagate=True' argument.
 
-  When set to :const:`False` exceptions occuring in subtasks will
+  When set to :const:`False` exceptions occurring in subtasks will
   not be re-raised.
 
 * Added `Task.update_state(task_id, state, meta)`
@@ -500,13 +501,13 @@ News
 * `celery.platform` renamed to :mod:`celery.platforms`, so it doesn't
   collide with the built-in :mod:`platform` module.
 
-* Exceptions occuring in Mediator+Pool callbacks are now catched and logged
+* Exceptions occurring in Mediator+Pool callbacks are now caught and logged
   instead of taking down the worker.
 
 * Redis result backend: Now supports result expiration using the Redis
   `EXPIRE` command.
 
-* unittests: Don't leave threads running at teardown.
+* unit tests: Don't leave threads running at tear down.
 
 * celeryd: Task results shown in logs are now truncated to 46 chars.
 
@@ -547,7 +548,7 @@ News
   Now supports a timeout keyword argument.
 
 * celeryd: The mediator thread is now disabled if
-  :setting:`CELERY_RATE_LIMTS` is enabled, and tasks are directly sent to the
+  :setting:`CELERY_RATE_LIMITS` is enabled, and tasks are directly sent to the
   pool without going through the ready queue (*Optimization*).
 
 .. _v210-fixes:
@@ -555,13 +556,13 @@ News
 Fixes
 -----
 
-* Pool: Process timed out by TimeoutHandler must be joined by the Supervisor,
-  so don't remove it from self._pool
+* Pool: Process timed out by `TimeoutHandler` must be joined by the Supervisor,
+  so don't remove it from the internal process list.
 
     See issue #192.
 
-* TaskPublisher.delay_task now supports exchange argument, so exchange can be
-  overriden when sending tasks in bulk using the same publisher
+* `TaskPublisher.delay_task` now supports exchange argument, so exchange can be
+  overridden when sending tasks in bulk using the same publisher
 
     See issue #187.
 
@@ -585,7 +586,7 @@ Fixes
 
     This issue could result in replies being lost, but have now been fixed.
 
-* Compat `LoggerAdapter` implementation: Now works for Python 2.4.
+* Backward compatible `LoggerAdapter` implementation: Now works for Python 2.4.
 
     Also added support for several new methods:
     `fatal`, `makeRecord`, `_log`, `log`, `isEnabledFor`,
@@ -602,7 +603,7 @@ Experimental
 
         $ celeryd-multi start jerry elaine george kramer
 
-    This also creates pidfiles and logfiles (:file:`celeryd@jerry.pid`,
+    This also creates PID files and log files (:file:`celeryd@jerry.pid`,
     ..., :file:`celeryd@jerry.log`. To specify a location for these files
     use the `--pidfile` and `--logfile` arguments with the `%n`
     format::
@@ -676,7 +677,7 @@ Fixes
 
 * No longer depends on the :mod:`mailer` package.
 
-    This package had a namespace collision with `django-mailer`,
+    This package had a name space collision with `django-mailer`,
     so its functionality was replaced.
 
 * Redis result backend: Documentation typos: Redis doesn't have
@@ -745,16 +746,16 @@ Fixes
     See issue #175.
 
 * Using urllib2 in a periodic task on OS X crashed because
-  of the proxy autodetection used in OS X.
+  of the proxy auto detection used in OS X.
 
     This is now fixed by using a workaround.
     See issue #143.
 
-* Debian init scripts: Commands should not run in a subshell
+* Debian init scripts: Commands should not run in a sub shell
 
     See issue #163.
 
-* Debian init scripts: Use abspath for celeryd to allow stat
+* Debian init scripts: Use the absolute path of celeryd to allow stat
 
     See issue #162.
 
@@ -767,18 +768,18 @@ Documentation
 
     `set_permissions ""` -> `set_permissions ".*"`.
 
-* Tasks Userguide: Added section on database transactions.
+* Tasks User Guide: Added section on database transactions.
 
     See issue #169.
 
-* Routing Userguide: Fixed typo `"feed": -> {"queue": "feeds"}`.
+* Routing User Guide: Fixed typo `"feed": -> {"queue": "feeds"}`.
 
     See issue #169.
 
 * Documented the default values for the :setting:`CELERYD_CONCURRENCY`
   and :setting:`CELERYD_PREFETCH_MULTIPLIER` settings.
 
-* Tasks Userguide: Fixed typos in the subtask example
+* Tasks User Guide: Fixed typos in the subtask example
 
 * celery.signals: Documented worker_process_init.
 
@@ -800,25 +801,26 @@ Documentation
 :release-date: 2010-07-22 11:31 A.M CEST
 
 * Routes: When using the dict route syntax, the exchange for a task
-  could dissapear making the task unroutable.
+  could disappear making the task unroutable.
 
     See issue #158.
 
 * Test suite now passing on Python 2.4
 
-* No longer have to type PYTHONPATH=. to use celeryconfig in current dir.
+* No longer have to type `PYTHONPATH=.` to use celeryconfig in the current
+  directory.
 
     This is accomplished by the default loader ensuring that the current
     directory is in `sys.path` when loading the config module.
     `sys.path` is reset to its original state after loading.
 
-    Adding cwd to `sys.path` without the user knowing may be a security
-    issue, as this means someone can drop a Python module in the users
+    Adding the current working directory to `sys.path` without the user
+    knowing may be a security issue, as this means someone can drop a Python module in the users
     directory that executes arbitrary commands. This was the original reason
     not to do this, but if done *only when loading the config module*, this
-    means that the behvavior will only apply to the modules imported in the
+    means that the behavior will only apply to the modules imported in the
     config module, which I think is a good compromise (certainly better than
-    just explictly setting PYTHONPATH=. anyway)
+    just explicitly setting `PYTHONPATH=.` anyway)
 
 * Experimental Cassandra backend added.
 
@@ -837,16 +839,16 @@ Documentation
 
     See issue #152.
 
-* Test teardown: Don't use atexit but nose's `teardown()` functionality
+* Test tear down: Don't use `atexit` but nose's `teardown()` functionality
   instead.
 
     See issue #154.
 
 * Debian init script for celeryd: Stop now works correctly.
 
-* Task logger:  `warn` method added (synonym for `warning`)
+* Task logger: `warn` method added (synonym for `warning`)
 
-* Can now define a whitelist of errors to send error e-mails for.
+* Can now define a white list of errors to send error e-mails for.
 
     Example::
 
@@ -899,7 +901,7 @@ Documentation
     Containing the original arguments and fields of the task requested.
 
     In addition the remote control command `set_loglevel` has been added,
-    this only changes the loglevel for the main process.
+    this only changes the log level for the main process.
 
 * Worker control command execution now catches errors and returns their
   string representation in the reply.
@@ -987,7 +989,7 @@ Documentation
 
 * New remote control command: `stats`
 
-    Dumps information about the worker, like pool process pids, and
+    Dumps information about the worker, like pool process ids, and
     total number of tasks executed by type.
 
     Example reply::
@@ -1183,7 +1185,7 @@ Backward incompatible changes
   instead of raising :exc:`ImportError`.
 
     celeryd raises :exc:`~celery.exceptions.ImproperlyConfigured` if the configuration
-    is not set up. This makes it possible to use `--help` etc, without having a
+    is not set up. This makes it possible to use `--help` etc., without having a
     working configuration.
 
     Also this makes it possible to use the client side of celery without being
@@ -1245,10 +1247,10 @@ Backward incompatible changes
 
 * Now uses pickle instead of cPickle on Python versions <= 2.5
 
-    cPikle is broken in Python <= 2.5.
+    cPickle is broken in Python <= 2.5.
 
     It unsafely and incorrectly uses relative instead of absolute imports,
-    so e.g::
+    so e.g.::
 
           exceptions.KeyError
 
@@ -1302,7 +1304,7 @@ News
     * :doc:`userguide/tasksets`
     * :doc:`userguide/routing`
 
-* celeryd: Standard out/error is now being redirected to the logfile.
+* celeryd: Standard out/error is now being redirected to the log file.
 
 * :mod:`billiard` has been moved back to the celery repository.
 
@@ -1382,7 +1384,7 @@ News
 
        $ celeryd -Q video, image
 
-   See the new routing section of the userguide for more information:
+   See the new routing section of the User Guide for more information:
    :doc:`userguide/routing`.
 
 * New Task option: `Task.queue`
@@ -1391,7 +1393,7 @@ News
     in :setting:`CELERY_QUEUES`. `exchange`, `exchange_type` and `routing_key`
     will be ignored
 
-* Added support for task soft and hard timelimits.
+* Added support for task soft and hard time limits.
 
     New settings added:
 
@@ -1402,9 +1404,9 @@ News
 
     * :setting:`CELERYD_SOFT_TASK_TIME_LIMIT`
 
-        Soft time limit. The celery.exceptions.SoftTimeLimitExceeded exception
-        will be raised when this is exceeded. The task can catch this to
-        e.g. clean up before the hard time limit comes.
+        Soft time limit. The :exc:`celery.exceptions.SoftTimeLimitExceeded`
+        exception will be raised when this is exceeded.  The task can catch
+        this to e.g. clean up before the hard time limit comes.
 
     New command line arguments to celeryd added:
     `--time-limit` and `--soft-time-limit`.
@@ -1413,7 +1415,7 @@ News
 
     This won't work on platforms not supporting signals (and specifically
     the `SIGUSR1` signal) yet. So an alternative the ability to disable
-    the feature alltogether on nonconforming platforms must be implemented.
+    the feature all together on nonconforming platforms must be implemented.
 
     Also when the hard time limit is exceeded, the task result should
     be a `TimeLimitExceeded` exception.
@@ -1436,12 +1438,12 @@ News
     You can explicitly enable/disable this feature using the
     :setting:`CELERYD_LOG_COLOR` setting.
 
-* Added support for task router classes (like the django multidb routers)
+* Added support for task router classes (like the django multi-db routers)
 
     * New setting: :setting:`CELERY_ROUTES`
 
     This is a single, or a list of routers to traverse when
-    sending tasks. Dicts in this list converts to a
+    sending tasks. Dictionaries in this list converts to a
     :class:`celery.routes.MapRoute` instance.
 
     Examples:
@@ -1515,7 +1517,7 @@ News
 * New signal: :data:`~celery.signals.worker_process_init`: Sent inside the
   pool worker process at init.
 
-* celeryd :option:`-Q` option: Ability to specifiy list of queues to use,
+* celeryd :option:`-Q` option: Ability to specify list of queues to use,
   disabling other configured queues.
 
     For example, if :setting:`CELERY_QUEUES` defines four
@@ -1543,7 +1545,7 @@ News
 
 * Removed top-level tests directory. Test config now in celery.tests.config
 
-    This means running the unittests doesn't require any special setup.
+    This means running the unit tests doesn't require any special setup.
     `celery/tests/__init__` now configures the :envvar:`CELERY_CONFIG_MODULE`
     and :envvar:`CELERY_LOADER` environment variables, so when `nosetests`
     imports that, the unit test environment is all set up.
@@ -1662,7 +1664,7 @@ News
 Critical
 --------
 
-* SIGINT/Ctrl+C killed the pool, abrubtly terminating the currently executing
+* SIGINT/Ctrl+C killed the pool, abruptly terminating the currently executing
   tasks.
 
     Fixed by making the pool worker processes ignore :const:`SIGINT`.
@@ -1696,9 +1698,9 @@ Changes
 * Added required RPM package names under `[bdist_rpm]` section, to support building RPMs
   from the sources using setup.py
 
-* Running unittests: :envvar:`NOSE_VERBOSE` environment var now enables verbose output from Nose.
+* Running unit tests: :envvar:`NOSE_VERBOSE` environment var now enables verbose output from Nose.
 
-* :func:`celery.execute.apply`: Pass logfile/loglevel arguments as task kwargs.
+* :func:`celery.execute.apply`: Pass log file/log level arguments as task kwargs.
 
     See issue #110.
 
@@ -1718,7 +1720,7 @@ Changes
 =====
 :release-date: 2010-05-31 09:54 A.M CEST
 
-* Changlog merged with 1.0.5 as the release was never announced.
+* Changelog merged with 1.0.5 as the release was never announced.
 
 .. _version-1.0.3:
 
@@ -1731,7 +1733,7 @@ Changes
 Important notes
 ---------------
 
-* Messages are now acked *just before* the task function is executed.
+* Messages are now acknowledged *just before* the task function is executed.
 
     This is the behavior we've wanted all along, but couldn't have because of
     limitations in the multiprocessing module.
@@ -1973,7 +1975,7 @@ Fixes
 
 * Remote rate limits was not properly applied (Issue #98).
 
-* Now handles exceptions with unicode messages correctly in
+* Now handles exceptions with Unicode messages correctly in
   `TaskRequest.on_failure`.
 
 * Database backend: `TaskMeta.result`: default value should be `None`
@@ -2005,7 +2007,7 @@ Fixes
             [%(asctime)s: %(levelname)s/%(processName)s] %(message)s
         """.strip()
 
-* Unittests: Don't disable the django test database teardown,
+* Unit tests: Don't disable the django test database tear down,
   instead fixed the underlying issue which was caused by modifications
   to the `DATABASE_NAME` setting (Issue #82).
 
@@ -2047,10 +2049,10 @@ Fixes
 * celery.beat.Scheduler: Fixed a bug where the schedule was not properly
   flushed to disk if the schedule had not been properly initialized.
 
-* celerybeat: Now syncs the schedule to disk when receiving the `SIGTERM`
-  and `SIGINT` signals.
+* celerybeat: Now syncs the schedule to disk when receiving the :sig:`SIGTERM`
+  and :sig:`SIGINT` signals.
 
-* Control commands: Make sure keywords arguments are not in unicode.
+* Control commands: Make sure keywords arguments are not in Unicode.
 
 * ETA scheduler: Was missing a logger object, so the scheduler crashed
   when trying to log that a task had been revoked.
@@ -2075,7 +2077,7 @@ Fixes
 
 * Tasks are now acknowledged early instead of late.
 
-    This is done because messages can only be acked within the same
+    This is done because messages can only be acknowledged within the same
     connection channel, so if the connection is lost we would have to refetch
     the message again to acknowledge it.
 
@@ -2096,9 +2098,9 @@ Fixes
         worked on, this patch would enable us to use a better solution, and is
         scheduled for inclusion in the `2.0.0` release.
 
-* celeryd now shutdowns cleanly when receving the `TERM` signal.
+* celeryd now shutdowns cleanly when receiving the :sig:`SIGTERM` signal.
 
-* celeryd now does a cold shutdown if the `INT` signal is received (Ctrl+C),
+* celeryd now does a cold shutdown if the :sig:`SIGINT` signal is received (Ctrl+C),
   this means it tries to terminate as soon as possible.
 
 * Caching of results now moved to the base backend classes, so no need
@@ -2192,7 +2194,7 @@ Fixes
     Used by retry() to resend the task to its original destination using the same
     exchange/routing_key.
 
-* Events: Fields was not passed by `.send()` (fixes the uuid keyerrors
+* Events: Fields was not passed by `.send()` (fixes the UUID key errors
   in celerymon)
 
 * Added `--schedule`/`-s` option to celeryd, so it is possible to
@@ -2221,8 +2223,8 @@ Fixes
 * Now have our own `ImproperlyConfigured` exception, instead of using the
   Django one.
 
-* Improvements to the debian init scripts: Shows an error if the program is
-  not executeable. Does not modify `CELERYD` when using django with
+* Improvements to the Debian init scripts: Shows an error if the program is
+  not executable.  Does not modify `CELERYD` when using django with
   virtualenv.
 
 .. _version-1.0.0:
@@ -2237,7 +2239,7 @@ Backward incompatible changes
 -----------------------------
 
 * Celery does not support detaching anymore, so you have to use the tools
-  available on your platform, or something like supervisord to make
+  available on your platform, or something like Supervisord to make
   celeryd/celerybeat/celerymon into background processes.
 
     We've had too many problems with celeryd daemonizing itself, so it was
@@ -2345,7 +2347,7 @@ Backward incompatible changes
   revert to the previous behaviour set
   :setting:`CELERY_STORE_ERRORS_EVEN_IF_IGNORED` to `True`.
 
-* The staticstics functionality has been removed in favor of events,
+* The statistics functionality has been removed in favor of events,
   so the `-S` and --statistics` switches has been removed.
 
 * The module `celery.task.strategy` has been removed.
@@ -2358,7 +2360,7 @@ Backward incompatible changes
 
     E.g. where you previously had: `"celery.loaders.default"`, you now need
     `"celery.loaders.default.Loader"`, using the previous syntax will result
-    in a DeprecationWarning.
+    in a `DeprecationWarning`.
 
 * Detecting the loader is now lazy, and so is not done when importing
   `celery.loaders`.
@@ -2391,13 +2393,13 @@ Deprecations
     * CELERY_AMQP_CONNECTION_MAX_RETRIES -> CELERY_BROKER_CONNECTION_MAX_RETRIES
     * SEND_CELERY_TASK_ERROR_EMAILS -> CELERY_SEND_TASK_ERROR_EMAILS
 
-* The public api names in celery.conf has also changed to a consistent naming
+* The public API names in celery.conf has also changed to a consistent naming
   scheme.
 
 * We now support consuming from an arbitrary number of queues.
 
     To do this we had to rename the configuration syntax. If you use any of
-    the custom AMQP routing options (queue/exchange/routing_key, etc), you
+    the custom AMQP routing options (queue/exchange/routing_key, etc.), you
     should read the new FAQ entry: http://bit.ly/aiWoH.
 
     The previous syntax is deprecated and scheduled for removal in v2.0.
@@ -2439,7 +2441,7 @@ News
 * Message format has been standardized and now uses ISO-8601 format
   for dates instead of datetime.
 
-* `celeryd` now responds to the `HUP` signal by restarting itself.
+* `celeryd` now responds to the :sig:`SIGHUP` signal by restarting itself.
 
 * Periodic tasks are now scheduled on the clock.
 
@@ -2466,7 +2468,7 @@ News
     :mod:`celery.task.http`. With more reflective names, sensible interface,
     and it's possible to override the methods used to perform HTTP requests.
 
-* The results of tasksets are now cached by storing it in the result
+* The results of task sets are now cached by storing it in the result
   backend.
 
 .. _v100-changes:
@@ -2505,9 +2507,9 @@ Changes
 * Now also imports modules listed in :setting:`CELERY_IMPORTS` when running
   with django (as documented).
 
-* Loglevel for stdout/stderr changed from INFO to ERROR
+* Log level for stdout/stderr changed from INFO to ERROR
 
-* ImportErrors are now properly propogated when autodiscovering tasks.
+* ImportErrors are now properly propagated when autodiscovering tasks.
 
 * You can now use `celery.messaging.establish_connection` to establish a
   connection to the broker.
@@ -2564,7 +2566,7 @@ Documentation
 * Now emits a warning if the --detach argument is used.
   --detach should not be used anymore, as it has several not easily fixed
   bugs related to it. Instead, use something like start-stop-daemon,
-  supervisord or launchd (os x).
+  Supervisord or launchd (os x).
 
 
 * Make sure logger class is process aware, even if running Python >= 2.6.
@@ -2579,10 +2581,10 @@ Documentation
 :release-date: 2009-12-22 09:43 A.M CEST
 
 * Fixed a possible race condition that could happen when storing/querying
-  task results using the the database backend.
+  task results using the database backend.
 
 * Now has console script entry points in the setup.py file, so tools like
-  buildout will correctly install the programs celerybin and celeryinit.
+  Buildout will correctly install the programs celeryd and celeryinit.
 
 .. _version-0.8.2:
 
@@ -2682,7 +2684,7 @@ Changes
 
 * Prepare exception to pickle when saving :state:`RETRY` status for all backends.
 
-* SQLite no concurrency limit should only be effective if the db backend
+* SQLite no concurrency limit should only be effective if the database backend
   is used.
 
 
@@ -2749,7 +2751,7 @@ Important changes
 
     This to not receive more messages than we can handle.
 
-* Now redirects stdout/stderr to the celeryd logfile when detached 
+* Now redirects stdout/stderr to the celeryd log file when detached
 
 * Now uses `inspect.getargspec` to only pass default arguments
     the task supports.
@@ -2762,7 +2764,7 @@ Important changes
 * `celery.utils.gen_unique_id`: Workaround for
     http://bugs.python.org/issue4607
 
-* You can now customize what happens at worker start, at process init, etc
+* You can now customize what happens at worker start, at process init, etc.,
     by creating your own loaders. (see :mod:`celery.loaders.default`,
     :mod:`celery.loaders.djangoapp`, :mod:`celery.loaders`.)
 
@@ -2793,7 +2795,7 @@ News
     detaching.
 
 * Fixed a possible DjangoUnicodeDecodeError being raised when saving pickled
-    data to Django's memcached cache backend.
+    data to Django`s memcached cache backend.
 
 * Better Windows compatibility.
 
@@ -2820,7 +2822,7 @@ News
 
 * jail() refactored into :class:`celery.execute.ExecuteWrapper`.
 
-* `views.apply` now correctly sets mimetype to "application/json"
+* `views.apply` now correctly sets mime-type to "application/json"
 
 * `views.task_status` now returns exception if state is :state:`RETRY`
 
@@ -2832,7 +2834,7 @@ News
 * Add a sensible __repr__ to ExceptionInfo for easier debugging
 
 * Fix documentation typo `.. import map` -> `.. import dmap`.
-    Thanks mikedizon
+    Thanks to mikedizon
 
 .. _version-0.6.0:
 
@@ -2846,7 +2848,7 @@ Important changes
 -----------------
 
 * Fixed a bug where tasks raising unpickleable exceptions crashed pool
-    workers. So if you've had pool workers mysteriously dissapearing, or
+    workers. So if you've had pool workers mysteriously disappearing, or
     problems with celeryd stopping working, this has been fixed in this
     version.
 
@@ -2887,7 +2889,7 @@ News
     engines)
 
 * A lot more debugging information is now available by turning on the
-    `DEBUG` loglevel (`--loglevel=DEBUG`).
+    `DEBUG` log level (`--loglevel=DEBUG`).
 
 * Functions/methods with a timeout argument now works correctly.
 
@@ -2895,14 +2897,14 @@ News
     With an iterator yielding task args, kwargs tuples, evenly distribute
     the processing of its tasks throughout the time window available.
 
-* Log message `Unknown task ignored...` now has loglevel `ERROR`
+* Log message `Unknown task ignored...` now has log level `ERROR`
 
 * Log message `"Got task from broker"` is now emitted for all tasks, even if
     the task has an ETA (estimated time of arrival). Also the message now
     includes the ETA for the task (if any).
 
 * Acknowledgement now happens in the pool callback. Can't do ack in the job
-    target, as it's not pickleable (can't share AMQP connection, etc)).
+    target, as it's not pickleable (can't share AMQP connection, etc.)).
 
 * Added note about .delay hanging in README
 
@@ -2910,10 +2912,10 @@ News
 
 * Fixed discovery to make sure app is in INSTALLED_APPS
 
-* Previously overrided pool behaviour (process reap, wait until pool worker
+* Previously overridden pool behavior (process reap, wait until pool worker
     available, etc.) is now handled by `multiprocessing.Pool` itself.
 
-* Convert statistics data to unicode for use as kwargs. Thanks Lucy!
+* Convert statistics data to Unicode for use as kwargs. Thanks Lucy!
 
 .. _version-0.4.1:
 
@@ -2931,7 +2933,7 @@ News
 :release-date: 2009-07-01 07:29 P.M CET
 
 * Adds eager execution. `celery.execute.apply`|`Task.apply` executes the
-  function blocking until the task is done, for API compatiblity it
+  function blocking until the task is done, for API compatibility it
   returns an `celery.result.EagerResult` instance. You can configure
   celery to always run tasks locally by setting the
   :setting:`CELERY_ALWAYS_EAGER` setting to `True`.
@@ -2956,7 +2958,7 @@ News
     >>> res = apply_async(MyTask,
     ...                   eta=datetime.now() + timedelta(days=1))
 
-* Now unlinks the pidfile if it's stale.
+* Now unlinks stale PID files
 
 * Lots of more tests.
 
@@ -2989,7 +2991,7 @@ News
   by running `python manage.py celerystats`. See
   `celery.monitoring` for more information.
 
-* The celery daemon can now be supervised (i.e it is automatically
+* The celery daemon can now be supervised (i.e. it is automatically
   restarted if it crashes). To use this start celeryd with the
   --supervised` option (or alternatively `-S`).
 
@@ -3028,7 +3030,7 @@ News
 =====
 :release-date: 2008-06-16 11:41 P.M CET
 
-* **IMPORTANT** Now uses AMQP's `basic.consume` instead of
+* **IMPORTANT** Now uses AMQP`s `basic.consume` instead of
   `basic.get`. This means we're no longer polling the broker for
   new messages.
 
@@ -3048,7 +3050,7 @@ News
 
 * Now compatible with carrot 0.4.5
 
-* Default AMQP connnection timeout is now 4 seconds.
+* Default AMQP connection timeout is now 4 seconds.
 * `AsyncResult.read()` was always returning `True`.
 
 *  Only use README as long_description if the file exists so easy_install
@@ -3064,7 +3066,7 @@ News
 
 * Fixed typo `AMQP_SERVER` in documentation to `AMQP_HOST`.
 
-* Worker exception e-mails sent to admins now works properly.
+* Worker exception e-mails sent to administrators now works properly.
 
 * No longer depends on `django`, so installing `celery` won't affect
   the preferred Django version installed.
@@ -3173,21 +3175,21 @@ arguments, so be sure to flush your task queue before you upgrade.
         http://bit.ly/celery_AMQP_routing
 .. _`FAQ`: http://ask.github.com/celery/faq.html
 
-* Task errors are now logged using loglevel `ERROR` instead of `INFO`,
-  and backtraces are dumped. Thanks to Grégoire Cachet.
+* Task errors are now logged using log level `ERROR` instead of `INFO`,
+  and stacktraces are dumped. Thanks to Grégoire Cachet.
 
 * Make every new worker process re-establish it's Django DB connection,
   this solving the "MySQL connection died?" exceptions.
   Thanks to Vitaly Babiy and Jirka Vejrazka.
 
-* **IMOPORTANT** Now using pickle to encode task arguments. This means you
+* **IMPORTANT** Now using pickle to encode task arguments. This means you
   now can pass complex python objects to tasks as arguments.
 
 * Removed dependency to `yadayada`.
 
 * Added a FAQ, see `docs/faq.rst`.
 
-* Now converts any unicode keys in task `kwargs` to regular strings.
+* Now converts any Unicode keys in task `kwargs` to regular strings.
   Thanks Vitaly Babiy.
 
 * Renamed the `TaskDaemon` to `WorkController`.
@@ -3217,7 +3219,7 @@ arguments, so be sure to flush your task queue before you upgrade.
 ==========
 :release-date: 2009-05-20 05:14 P.M CET
 
-* *Internal release*. Improved handling of unpickled exceptions,
+* *Internal release*. Improved handling of unpickleable exceptions,
   `get_result` now tries to recreate something looking like the
   original exception.
 
@@ -3227,7 +3229,7 @@ arguments, so be sure to flush your task queue before you upgrade.
 ==========
 :release-date: 2009-05-20 01:56 P.M CET
 
-* Now handles unpickleable exceptions (like the dynimically generated
+* Now handles unpickleable exceptions (like the dynamically generated
   subclasses of `django.core.exception.MultipleObjectsReturned`).
 
 .. _version-0.2.0-pre1:
@@ -3319,7 +3321,7 @@ arguments, so be sure to flush your task queue before you upgrade.
 
 * Refactored the task metadata cache and database backends, and added
   a new backend for Tokyo Tyrant. You can set the backend in your django
-  settings file. e.g::
+  settings file. E.g.::
 
         CELERY_RESULT_BACKEND = "database"; # Uses the database
         CELERY_RESULT_BACKEND = "cache"; # Uses the django cache framework
@@ -3365,12 +3367,12 @@ arguments, so be sure to flush your task queue before you upgrade.
 =====
 :release-date: 2009-04-30 1:50 P.M CET
 
-* Added some unittests
+* Added some unit tests
 
 * Can now use the database for task metadata (like if the task has
   been executed or not). Set `settings.CELERY_TASK_META`
 
-* Can now run `python setup.py test` to run the unittests from
+* Can now run `python setup.py test` to run the unit tests from
   within the `tests` project.
 
 * Can set the AMQP exchange/routing key/queue using
@@ -3388,12 +3390,12 @@ arguments, so be sure to flush your task queue before you upgrade.
   bars and such)
 
 * Now catches all exceptions when running `Task.__call__`, so the
-  daemon doesn't die. This does't happen for pure functions yet, only
+  daemon doesn't die. This doesn't happen for pure functions yet, only
   `Task` classes.
 
 * `autodiscover()` now works with zipped eggs.
 
-* celeryd: Now adds curernt working directory to `sys.path` for
+* celeryd: Now adds current working directory to `sys.path` for
   convenience.
 
 * The `run_every` attribute of `PeriodicTask` classes can now be a

+ 19 - 19
FAQ

@@ -27,7 +27,7 @@ These are some common use cases:
 
 * Running something in the background. For example, to finish the web request
   as soon as possible, then update the users page incrementally.
-  This gives the user the impression of good performane and "snappiness", even
+  This gives the user the impression of good performance and "snappiness", even
   though the real work might actually take some time.
 
 * Running something after the web request has finished.
@@ -112,7 +112,7 @@ language has an AMQP client, there shouldn't be much work to create a worker
 in your language.  A Celery worker is just a program connecting to the broker
 to process messages.
 
-Also, there's another way to be language indepedent, and that is to use REST
+Also, there's another way to be language independent, and that is to use REST
 tasks, instead of your tasks being functions, they're URLs. With this
 information you can even create simple web servers that enable preloading of
 code. See: `User Guide: Remote Tasks`_.
@@ -137,7 +137,7 @@ You can do that by adding the following to your :file:`my.cnf`::
     [mysqld]
     transaction-isolation = READ-COMMITTED
 
-For more information about InnoDBs transaction model see `MySQL - The InnoDB
+For more information about InnoDB`s transaction model see `MySQL - The InnoDB
 Transaction Model and Locking`_ in the MySQL user manual.
 
 (Thanks to Honza Kral and Anton Tsigularov for this solution)
@@ -203,7 +203,7 @@ One reason that the queue is never emptied could be that you have a stale
 worker process taking the messages hostage. This could happen if celeryd
 wasn't properly shut down.
 
-When a message is recieved by a worker the broker waits for it to be
+When a message is received by a worker the broker waits for it to be
 acknowledged before marking the message as processed. The broker will not
 re-send that message to another consumer until the consumer is shut down
 properly.
@@ -232,7 +232,7 @@ task manually:
     >>> from myapp.tasks import MyPeriodicTask
     >>> MyPeriodicTask.delay()
 
-Watch celeryds logfile to see if it's able to find the task, or if some
+Watch celeryd`s log file to see if it's able to find the task, or if some
 other error is happening.
 
 .. _faq-periodic-task-does-not-run:
@@ -268,7 +268,7 @@ as they are actually executed. After the worker has received a task, it will
 take some time until it is actually executed, especially if there are a lot
 of tasks already waiting for execution. Messages that are not acknowledged are
 held on to by the worker until it closes the connection to the broker (AMQP
-server). When that connection is closed (e.g because the worker was stopped)
+server). When that connection is closed (e.g. because the worker was stopped)
 the tasks will be re-sent by the broker to the next available worker (or the
 same worker when it has been restarted), so to properly purge the queue of
 waiting tasks you have to stop all the workers, and then discard the tasks
@@ -320,10 +320,10 @@ http://www.rabbitmq.com/faq.html#node-runs-out-of-memory
     If you're still running an older version of RabbitMQ and experience
     crashes, then please upgrade!
 
-Some common Celery misconfigurations can eventually lead to a crash
-on older version of RabbitMQ. Even if it doesn't crash, these
-misconfigurations can still consume a lot of resources, so it is very
-important that you are aware of them.
+Misconfiguration of Celery can eventually lead to a crash
+on older version of RabbitMQ. Even if it doesn't crash, this
+can still consume a lot of resources, so it is very
+important that you are aware of the common pitfalls.
 
 * Events.
 
@@ -498,17 +498,17 @@ Why aren't my remote control commands received by all workers?
 --------------------------------------------------------------
 
 **Answer**: To receive broadcast remote control commands, every worker node
-uses its hostname to create a unique queue name to listen to,
-so if you have more than one worker with the same hostname, the
-control commands will be recieved in round-robin between them.
+uses its host name to create a unique queue name to listen to,
+so if you have more than one worker with the same host name, the
+control commands will be received in round-robin between them.
 
-To work around this you can explicitly set the hostname for every worker
+To work around this you can explicitly set the host name for every worker
 using the :option:`--hostname` argument to :mod:`~celery.bin.celeryd`::
 
     $ celeryd --hostname=$(hostname).1
     $ celeryd --hostname=$(hostname).2
 
-etc, etc.
+etc., etc...
 
 .. _faq-task-routing:
 
@@ -550,7 +550,7 @@ RabbitMQ doesn't implement them yet.
 The usual way to prioritize work in Celery, is to route high priority tasks
 to different servers. In the real world this may actually work better than per message
 priorities. You can use this in combination with rate limiting to achieve a
-highly performant system.
+highly responsive system.
 
 .. _faq-acks_late-vs-retry:
 
@@ -562,7 +562,7 @@ to use both.
 
 `Task.retry` is used to retry tasks, notably for expected errors that
 is catchable with the `try:` block. The AMQP transaction is not used
-for these errors: **if the task raises an exception it is still acked!**.
+for these errors: **if the task raises an exception it is still acknowledged!**.
 
 The `acks_late` setting would be used when you need the task to be
 executed again if the worker (for some reason) crashes mid-execution.
@@ -617,7 +617,7 @@ Or to schedule a periodic task at a specific time, use the
 
     @periodic_task(run_every=crontab(hours=7, minute=30, day_of_week="mon"))
     def every_monday_morning():
-        print("This is run every monday morning at 7:30")
+        print("This is run every Monday morning at 7:30")
 
 .. _faq-safe-worker-shutdown:
 
@@ -671,7 +671,7 @@ services instead.
 
 .. _faq-windows-django-settings:
 
-`django-celery` cant find settings?
+`django-celery` can't find settings?
 --------------------------------------
 
 **Answer**: You need to specify the :option:`--settings` argument to

+ 10 - 10
docs/configuration.rst

@@ -297,7 +297,7 @@ This backend requires the following configuration directives to be set:
 TT_HOST
 ~~~~~~~
 
-Hostname of the Tokyo Tyrant server.
+Host name of the Tokyo Tyrant server.
 
 .. setting:: TT_PORT
 
@@ -337,7 +337,7 @@ This backend requires the following configuration directives to be set.
 REDIS_HOST
 ~~~~~~~~~~
 
-Hostname of the Redis database server. e.g. `"localhost"`.
+Host name of the Redis database server. e.g. `"localhost"`.
 
 .. setting:: REDIS_PORT
 
@@ -389,7 +389,7 @@ CELERY_MONGODB_BACKEND_SETTINGS
 This is a dict supporting the following keys:
 
 * host
-    Hostname of the MongoDB server. Defaults to "localhost".
+    Host name of the MongoDB server. Defaults to "localhost".
 
 * port
     The port the MongoDB server is listening to. Defaults to 27017.
@@ -557,7 +557,7 @@ Virtual host.  Default is `"/"`.
 BROKER_USE_SSL
 ~~~~~~~~~~~~~~
 
-Use SSL to conenct to the broker.  Off by defalt.  This may not be supported
+Use SSL to connect to the broker.  Off by default.  This may not be supported
 by all transports.
 
 .. setting:: BROKER_CONNECTION_TIMEOUT
@@ -814,7 +814,7 @@ CELERY_SEND_TASK_ERROR_EMAILS
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 The default value for the `Task.send_error_emails` attribute, which if
-set to :const:`True` means errors occuring during task execution will be
+set to :const:`True` means errors occurring during task execution will be
 sent to :setting:`ADMINS` by e-mail.
 
 .. setting:: CELERY_TASK_ERROR_WHITELIST
@@ -822,14 +822,14 @@ sent to :setting:`ADMINS` by e-mail.
 CELERY_TASK_ERROR_WHITELIST
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-A whitelist of exceptions to send error e-mails for.
+A white list of exceptions to send error e-mails for.
 
 .. setting:: ADMINS
 
 ADMINS
 ~~~~~~
 
-List of `(name, email_address)` tuples for the admins that should
+List of `(name, email_address)` tuples for the administrators that should
 receive error e-mails.
 
 .. setting:: SERVER_EMAIL
@@ -852,7 +852,7 @@ The mail server to use.  Default is `"localhost"`.
 MAIL_HOST_USER
 ~~~~~~~~~~~~~~
 
-Username (if required) to log on to the mail server with.
+User name (if required) to log on to the mail server with.
 
 .. setting:: MAIL_HOST_PASSWORD
 
@@ -957,7 +957,7 @@ CELERY_BROADCAST_QUEUE
 ~~~~~~~~~~~~~~~~~~~~~~
 
 Name prefix for the queue used when listening for broadcast messages.
-The workers hostname will be appended to the prefix to create the final
+The workers host name will be appended to the prefix to create the final
 queue name.
 
 Default is `"celeryctl"`.
@@ -1050,7 +1050,7 @@ Used by :program:`celeryd` and :program:`celerybeat`.
 CELERY_REDIRECT_STDOUTS_LEVEL
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-The loglevel output to `stdout` and `stderr` is logged as.
+The log level output to `stdout` and `stderr` is logged as.
 Can be one of :const:`DEBUG`, :const:`INFO`, :const:`WARNING`,
 :const:`ERROR` or :const:`CRITICAL`.
 

+ 8 - 7
docs/cookbook/daemonizing.rst

@@ -33,8 +33,8 @@ Init script: celeryd
 :Usage: `/etc/init.d/celeryd {start|stop|force-reload|restart|try-restart|status}`
 :Configuration file: /etc/default/celeryd
 
-To configure celeryd you probably need to at least tell it where to chdir
-when it starts (to find your celeryconfig).
+To configure celeryd you probably need to at least tell it where to change
+directory to when it starts (to find your `celeryconfig`).
 
 .. _debian-initd-celeryd-example:
 
@@ -79,13 +79,14 @@ Available options
     Additional arguments to celeryd, see `celeryd --help` for a list.
 
 * CELERYD_CHDIR
-    Path to chdir at start. Default is to stay in the current directory.
+    Path to change directory to at start. Default is to stay in the current
+    directory.
 
 * CELERYD_PID_FILE
-    Full path to the pidfile. Default is /var/run/celeryd.pid.
+    Full path to the PID file. Default is /var/run/celeryd.pid.
 
 * CELERYD_LOG_FILE
-    Full path to the celeryd logfile. Default is /var/log/celeryd.log
+    Full path to the celeryd log file. Default is /var/log/celeryd.log
 
 * CELERYD_LOG_LEVEL
     Log level to use for celeryd. Default is INFO.
@@ -160,10 +161,10 @@ Available options
     list.
 
 * CELERYBEAT_PIDFILE
-    Full path to the pidfile. Default is /var/run/celeryd.pid.
+    Full path to the PID file. Default is /var/run/celeryd.pid.
 
 * CELERYBEAT_LOGFILE
-    Full path to the celeryd logfile. Default is /var/log/celeryd.log
+    Full path to the celeryd log file. Default is /var/log/celeryd.log
 
 * CELERYBEAT_LOG_LEVEL
     Log level to use for celeryd. Default is INFO.

+ 2 - 2
docs/cookbook/tasks.rst

@@ -21,7 +21,7 @@ It's part of an imaginary RSS feed importer called `djangofeeds`.
 The task takes a feed URL as a single argument, and imports that feed into
 a Django model called `Feed`. We ensure that it's not possible for two or
 more workers to import the same feed at the same time by setting a cache key
-consisting of the md5sum of the feed URL.
+consisting of the MD5 checksum of the feed URL.
 
 The cache key expires after some time in case something unexpected happens
 (you never know, right?)
@@ -53,7 +53,7 @@ The cache key expires after some time in case something unexpected happens
             release_lock = lambda: cache.delete(lock_id)
 
             logger.debug("Importing feed: %s" % feed_url)
-            if aquire_lock():
+            if acquire_lock():
                 try:
                     feed = Feed.objects.import_feed(feed_url)
                 finally:

+ 12 - 12
docs/getting-started/broker-installation.rst

@@ -53,15 +53,15 @@ Installing RabbitMQ on OS X
 The easiest way to install RabbitMQ on Snow Leopard is using `Homebrew`_; the new
 and shiny package management system for OS X.
 
-In this example we'll install homebrew into :file:`/lol`, but you can
+In this example we'll install Homebrew into :file:`/lol`, but you can
 choose whichever destination, even in your home directory if you want, as one of
-the strengths of homebrew is that it's relocateable.
+the strengths of Homebrew is that it's relocatable.
 
-Homebrew is actually a `git`_ repository, so to install homebrew, you first need to
+Homebrew is actually a `git`_ repository, so to install Homebrew, you first need to
 install git. Download and install from the disk image at
 http://code.google.com/p/git-osx-installer/downloads/list?can=3
 
-When git is installed you can finally clone the repo, storing it at the
+When git is installed you can finally clone the repository, storing it at the
 :file:`/lol` location::
 
     $ git clone git://github.com/mxcl/homebrew /lol
@@ -88,18 +88,18 @@ Finally, we can install rabbitmq using :program:`brew`::
 
 .. _rabbitmq-osx-system-hostname:
 
-Configuring the system hostname
--------------------------------
+Configuring the system host name
+--------------------------------
 
-If you're using a DHCP server that is giving you a random hostname, you need
-to permanently configure the hostname. This is because RabbitMQ uses the hostname
+If you're using a DHCP server that is giving you a random host name, you need
+to permanently configure the host name. This is because RabbitMQ uses the host name
 to communicate with nodes.
 
-Use the :program:`scutil` command to permanently set your hostname::
+Use the :program:`scutil` command to permanently set your host name::
 
     sudo scutil --set HostName myhost.local
 
-Then add that hostname to :file:`/etc/hosts` so it's possible to resolve it
+Then add that host name to :file:`/etc/hosts` so it's possible to resolve it
 back into an IP address::
 
     127.0.0.1       localhost myhost myhost.local
@@ -119,9 +119,9 @@ as verified by :program:`rabbitmqctl`::
     {running_nodes,[rabbit@myhost]}]
     ...done.
 
-This is especially important if your DHCP server gives you a hostname
+This is especially important if your DHCP server gives you a host name
 starting with an IP address, (e.g. `23.10.112.31.comcast.net`), because
-then RabbitMQ will try to use `rabbit@23`, which is an illegal hostname.
+then RabbitMQ will try to use `rabbit@23`, which is an illegal host name.
 
 .. _rabbitmq-osx-start-stop:
 

+ 5 - 5
docs/homepage/index.html

@@ -165,7 +165,7 @@ pageTracker._trackPageview();
       <p>In addition there are a lot of new features: a curses monitor, time
       limits, complex crontab expressions, callbacks, simplified routing,
       and more. Everything is detailed in the <a
-          href="http://celeryq.org/docs/changelog.html#id1">changelog</a>,
+          href="http://celeryq.org/docs/changelog.html#id1">Changelog</a>,
       so be sure to read it before upgrading.</p>
       </span>
 
@@ -176,7 +176,7 @@ pageTracker._trackPageview();
       AMQP result backend, this release resolves this. If you've already used
       the AMQP backend you need to delete the previous declarations. For
       instructions please read the full
-      <a href="http://celeryproject.org/docs/changelog.html">changelog</a>.
+      <a href="http://celeryproject.org/docs/changelog.html">Changelog</a>.
       Download from <a href="http://pypi.python.org/pypi/celery/1.0.6">PyPI</a>,
       or simply install the upgrade using <code>pip install -U Celery==1.0.6</code>.
       <hr>
@@ -185,9 +185,9 @@ pageTracker._trackPageview();
       <span class="newsitem">
       <h2>Celery 1.0.5 released!</h2>
       <h4>By <a href="http://twitter.com/asksol">@asksol</a> on 2010-06-01.</h4>
-      <p>This release contains some important bugfixes related to shutdown and
+      <p>This release contains some important bug fixes related to shutdown and
       broker connection loss, as well as some other minor fixes. Also
-      AbortableTask has been added to contrib. Please read the full <a href="http://celeryproject.org/docs/changelog.html">changelog</a>
+      AbortableTask has been added to contrib. Please read the full <a href="http://celeryproject.org/docs/changelog.html">Changelog</a>
       before you upgrade. Download from <a href="http://pypi.python.org/pypi/celery/1.0.5">PyPI</a>,
       or simply install the upgrade using <code>pip install -U Celery</code>.
       <hr>
@@ -197,7 +197,7 @@ pageTracker._trackPageview();
       <h2>Celery 1.0.3 released!</h2>
       <h4>By <a href="http://twitter.com/asksol">@asksol</a> on 2010-05-15.</h4>
       <p>This release contains a drastic improvement in reliability and
-      performance. Please read the full <a href="http://celeryproject.org/docs/changelog.html">changelog</a>
+      performance. Please read the full <a href="http://celeryproject.org/docs/changelog.html">Changelog</a>
       before you upgrade. Download from <a href="http://pypi.python.org/pypi/celery/1.0.3">PyPI</a>,
       or simply install the upgrade using <code>pip install -U Celery</code>.
       <hr>

+ 4 - 4
docs/userguide/executing.rst

@@ -75,8 +75,8 @@ The task is guaranteed to be executed at some time *after* the
 specified date and time, but not necessarily at that exact time.
 Possible reasons for broken deadlines may include many items waiting
 in the queue, or heavy network latency.  To make sure your tasks
-are executed in a timely manner you should monitor queue lenghts. Use
-Munin, or similar tools, to receive alerts, so appropiate action can be
+are executed in a timely manner you should monitor queue lengths. Use
+Munin, or similar tools, to receive alerts, so appropriate action can be
 taken to ease the workload.  See :ref:`monitoring-munin`.
 
 While `countdown` is an integer, `eta` must be a :class:`~datetime.datetime`
@@ -135,10 +135,10 @@ json -- JSON is supported in many programming languages, is now
     using the modern Python libraries such as :mod:`cjson` or :mod:`simplejson`.
 
     The primary disadvantage to JSON is that it limits you to the following
-    data types: strings, unicode, floats, boolean, dictionaries, and lists.
+    data types: strings, Unicode, floats, boolean, dictionaries, and lists.
     Decimals and dates are notably missing.
 
-    Also, binary data will be transferred using base64 encoding, which will
+    Also, binary data will be transferred using Base64 encoding, which will
     cause the transferred data to be around 34% larger than an encoding which
     supports native binary types.
 

+ 10 - 10
docs/userguide/monitoring.rst

@@ -30,7 +30,7 @@ celeryctl: Management Utility
 :mod:`~celery.bin.celeryctl` is a command line utility to inspect
 and manage worker nodes (and to some degree tasks).
 
-To list all the commands avaialble do::
+To list all the commands available do::
 
     $ celeryctl help
 
@@ -205,7 +205,7 @@ Using outside of Django
 ~~~~~~~~~~~~~~~~~~~~~~~
 
 `django-celery` also installs the :program:`djcelerymon` program. This
-can be used by non-Django users, and runs both a webserver and a snapshot
+can be used by non-Django users, and runs both a web server and a snapshot
 camera in the same process.
 
 **Installing**
@@ -220,8 +220,8 @@ or using :program:`easy_install`::
 
 **Running**
 
-:program:`djcelerymon` reads configuration from your Celery config module,
-and sets up the Django environment using the same settings::
+:program:`djcelerymon` reads configuration from your Celery configuration
+module, and sets up the Django environment using the same settings::
 
     $ djcelerymon
 
@@ -233,7 +233,7 @@ user running the monitor.
 If you want to store the events in a different database, e.g. MySQL,
 then you can configure the `DATABASE*` settings directly in your Celery
 config module.  See http://docs.djangoproject.com/en/dev/ref/settings/#databases
-for more information about the database options avaialble.
+for more information about the database options available.
 
 You will also be asked to create a superuser (and you need to create one
 to be able to log into the admin later)::
@@ -282,7 +282,7 @@ down workers.
 
     $ celeryev --camera=<camera-class> --frequency=1.0
 
-and it includes a tool to dump events to stdout::
+and it includes a tool to dump events to :file:`stdout`::
 
     $ celeryev --dump
 
@@ -317,7 +317,7 @@ RabbitMQ can be monitored.
 
 RabbitMQ ships with the `rabbitmqctl(1)`_ command,
 with this you can list queues, exchanges, bindings,
-queue lenghts, the memory usage of each queue, as well
+queue lengths, the memory usage of each queue, as well
 as manage users, virtual hosts and their permissions.
 
 .. note::
@@ -365,10 +365,10 @@ Finding the amount of memory allocated to a queue::
 Munin
 =====
 
-This is a list of known Munin plugins that can be useful when
+This is a list of known Munin plug-ins that can be useful when
 maintaining a Celery cluster.
 
-* rabbitmq-munin: Munin-plugins for RabbitMQ.
+* rabbitmq-munin: Munin plug-ins for RabbitMQ.
 
     http://github.com/ask/rabbitmq-munin
 
@@ -451,7 +451,7 @@ it with the `-c` option::
 
     $ celeryev -c myapp.DumpCam --frequency=2.0
 
-Or you can use it programatically like this::
+Or you can use it programmatically like this::
 
     from celery.events import EventReceiver
     from celery.messaging import establish_connection

+ 7 - 7
docs/userguide/periodic-tasks.rst

@@ -106,7 +106,7 @@ the `crontab` schedule type:
     from celery.schedules import crontab
 
     CELERYBEAT_SCHEDULE = {
-        # Executes every monday morning at 7:30 A.M
+        # Executes every Monday morning at 7:30 A.M
         "every-monday-morning": {
             "task": "tasks.add",
             "schedule": crontab(hour=7, minute=30, day_of_week=1),
@@ -131,7 +131,7 @@ The syntax of these crontab expressions are very flexible.  Some examples:
 +-------------------------------------+--------------------------------------------+
 | crontab(minute="\*/15")             | Execute every 15 minutes.                  |
 +-------------------------------------+--------------------------------------------+
-| crontab(day_of_week="sunday")       | Execute every minute (!) at sundays.       |
+| crontab(day_of_week="sunday")       | Execute every minute (!) at Sundays.       |
 +-------------------------------------+--------------------------------------------+
 | crontab(minute="*",                 | Same as previous.                          |
 |         hour="*",                   |                                            |
@@ -139,20 +139,20 @@ The syntax of these crontab expressions are very flexible.  Some examples:
 +-------------------------------------+--------------------------------------------+
 | crontab(minute="\*/10",             | Execute every ten minutes, but only        |
 |         hour="3,17,22",             | between 3-4 am, 5-6 pm and 10-11 pm on     |
-|         day_of_week="thu,fri")      | thursdays or fridays.                      |
+|         day_of_week="thu,fri")      | Thursdays or Fridays.                      |
 +-------------------------------------+--------------------------------------------+
 | crontab(minute=0, hour="\*/2,\*/3") | Execute every even hour, and every hour    |
-|                                     | divisable by three. This means:            |
+|                                     | divisible by three. This means:            |
 |                                     | at every hour *except*: 1am,               |
 |                                     | 5am, 7am, 11am, 1pm, 5pm, 7pm,             |
 |                                     | 11pm                                       |
 +-------------------------------------+--------------------------------------------+
-| crontab(minute=0, hour="\*/5")      | Execute hour divisable by 5. This means    |
+| crontab(minute=0, hour="\*/5")      | Execute hour divisible by 5. This means    |
 |                                     | that it is triggered at 3pm, not 5pm       |
 |                                     | (since 3pm equals the 24-hour clock        |
-|                                     | value of "15", which is divisable by 5).   |
+|                                     | value of "15", which is divisible by 5).   |
 +-------------------------------------+--------------------------------------------+
-| crontab(minute=0, hour="\*/3,8-17") | Execute every hour divisable by 3, and     |
+| crontab(minute=0, hour="\*/3,8-17") | Execute every hour divisible by 3, and     |
 |                                     | every hour during office hours (8am-5pm).  |
 +-------------------------------------+--------------------------------------------+
 

+ 1 - 1
docs/userguide/remote-tasks.rst

@@ -102,7 +102,7 @@ functionality.
     >>> res.get()
     100
 
-The output of :program:`celeryd` (or the logfile if enabled) should show the
+The output of :program:`celeryd` (or the log file if enabled) should show the
 task being executed::
 
     [INFO/MainProcess] Task celery.task.http.HttpDispatchTask

+ 2 - 2
docs/userguide/routing.rst

@@ -282,7 +282,7 @@ Exchange types
 The exchange type defines how the messages are routed through the exchange.
 The exchange types defined in the standard are `direct`, `topic`,
 `fanout` and `headers`.  Also non-standard exchange types are available
-as plugins to RabbitMQ, like the `last-value-cache plug-in`_ by Michael
+as plug-ins to RabbitMQ, like the `last-value-cache plug-in`_ by Michael
 Bridgen.
 
 .. _`last-value-cache plug-in`:
@@ -377,7 +377,7 @@ with no arguments to start it in shell-mode::
 
 Here `1>` is the prompt.  The number 1, is the number of commands you
 have executed so far.  Type `help` for a list of commands available.
-It also supports autocompletion, so you can start typing a command and then
+It also supports auto-completion, so you can start typing a command and then
 hit the `tab` key to show a list of possible matches.
 
 Let's create a queue we can send messages to::

+ 19 - 18
docs/userguide/tasks.rst

@@ -56,11 +56,11 @@ the task being executed, and contains the following attributes:
           An integer starting at `0`.
 
 :is_eager: Set to :const:`True` if the task is executed locally in
-           the client, kand not by a worker.
+           the client, and not by a worker.
 
 :logfile: The file the worker logs to.  See `Logging`_.
 
-:loglevel: The current loglevel used.
+:loglevel: The current log level used.
 
 :delivery_info: Additional message delivery information. This is a mapping
                 containing the exchange and routing key used to deliver this
@@ -101,7 +101,7 @@ There are several logging levels available, and the workers `loglevel`
 setting decides whether or not they will be written to the log file.
 
 Of course, you can also simply use `print` as anything written to standard
-out/-err will be written to the logfile as well.
+out/-err will be written to the log file as well.
 
 .. _task-retry:
 
@@ -181,7 +181,7 @@ General
 .. attribute:: Task.abstract
 
     Abstract classes are not registered, but are used as the
-    superclass when making new task types by subclassing.
+    base class for new task types.
 
 .. attribute:: Task.max_retries
 
@@ -229,8 +229,8 @@ General
 
 .. attribute:: Task.error_whitelist
 
-    If the sending of error e-emails is enabled for this task, then
-    this is a whitelist of exceptions to actually send e-mails about.
+    If the sending of error e-mails is enabled for this task, then
+    this is a white list of exceptions to actually send e-mails about.
 
 .. attribute:: Task.serializer
 
@@ -257,7 +257,7 @@ General
     crashes in the middle of execution, which may be acceptable for some
     applications.
 
-    The global default can be overriden by the :setting:`CELERY_ACKS_LATE`
+    The global default can be overridden by the :setting:`CELERY_ACKS_LATE`
     setting.
 
 .. _task-track-started:
@@ -272,8 +272,8 @@ General
     when there are long running tasks and there is a need to report which
     task is currently running.
 
-    The hostname and pid of the worker executing the task
-    will be avaiable in the state metadata (e.g. `result.info["pid"]`)
+    The host name and process id of the worker executing the task
+    will be available in the state metadata (e.g. `result.info["pid"]`)
 
     The global default can be overridden by the
     :setting:`CELERY_TRACK_STARTED` setting.
@@ -545,7 +545,7 @@ FAILURE
 
 Task execution resulted in failure.
 
-:metadata: `result` contains the exception occured, and `traceback`
+:metadata: `result` contains the exception occurred, and `traceback`
            contains the backtrace of the stack at the point when the
            exception was raised.
 :propagates: Yes
@@ -577,7 +577,7 @@ Custom states
 You can easily define your own states, all you need is a unique name.
 The name of the state is usually an uppercase string.  As an example
 you could have a look at :mod:`abortable tasks <~celery.contrib.abortable>`
-wich defines its own custom :state:`ABORTED` state.
+which defines its own custom :state:`ABORTED` state.
 
 Use :meth:`Task.update_state <celery.task.base.BaseTask.update_state>` to
 update a tasks state::
@@ -641,7 +641,8 @@ task as :attr:`~celery.task.base.BaseTask.abstract`:
     class MyTask(Task):
         abstract = True
 
-This way the task won't be registered, but any task subclassing it will be.
+This way the task won't be registered, but any task inheriting from
+it will be.
 
 When tasks are sent, we don't send any actual function code, just the name
 of the task to execute.  When the worker then receives the message it can look
@@ -830,13 +831,13 @@ The ancient async sayings tells us that “asserting the world is the
 responsibility of the task”.  What this means is that the world view may
 have changed since the task was requested, so the task is responsible for
 making sure the world is how it should be;  If you have a task
-that reindexes a search engine, and the search engine should only be reindexed
-at maximum every 5 minutes, then it must be the tasks responsibility to assert
-that, not the callers.
+that re-indexes a search engine, and the search engine should only be
+re-indexed at maximum every 5 minutes, then it must be the tasks
+responsibility to assert that, not the callers.
 
-Another gotcha is Django model objects.  They shouldn't be passed on as arguments
-to tasks.  It's almost always better to re-fetch the object from the
-database when the task is running instead,  as using old data may lead
+Another gotcha is Django model objects.  They shouldn't be passed on as
+arguments to tasks.  It's almost always better to re-fetch the object from
+the database when the task is running instead,  as using old data may lead
 to race conditions.
 
 Imagine the following scenario where you have an article and a task

+ 2 - 2
docs/userguide/workers.rst

@@ -27,7 +27,7 @@ For a full list of available command line options see
 
 You can also start multiple workers on the same machine. If you do so
 be sure to give a unique name to each individual worker by specifying a
-hostname with the `--hostname|-n` argument::
+host name with the `--hostname|-n` argument::
 
     $ celeryd --loglevel=INFO --concurrency=10 -n worker1.example.com
     $ celeryd --loglevel=INFO --concurrency=10 -n worker2.example.com
@@ -181,7 +181,7 @@ to the number of destination hosts.
 .. seealso::
 
     The :program:`celeryctl` program is used to execute remote control
-    commands from the commandline.  It supports all of the commands
+    commands from the command line.  It supports all of the commands
     listed below.  See :ref:`monitoring-celeryctl` for more information.
 
 .. _worker-broadcast-fun: