[PATCH 3/4] docs: Refer to 'Patchwork' consistently
Stephen Finucane
stephen.finucane at intel.com
Sat Mar 26 08:33:25 AEDT 2016
The docs referred to both 'patchwork' and 'Patchwork'. Use the title
case variant consistently.
Signed-off-by: Stephen Finucane <stephen.finucane at intel.com>
---
CHANGELOG.md | 10 +++++-----
README.md | 8 ++++----
UPGRADING.md | 8 ++++----
docs/api.md | 6 +++---
docs/contributing.md | 6 +++---
docs/deployment.md | 44 ++++++++++++++++++++++----------------------
docs/development.md | 40 ++++++++++++++++++++--------------------
docs/index.md | 30 +++++++++++++++---------------
docs/releasing.md | 6 +++---
docs/upgrading.md | 32 ++++++++++++++++----------------
10 files changed, 95 insertions(+), 95 deletions(-)
diff --git a/CHANGELOG.md b/CHANGELOG.md
index cc206cd..286ae6a 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -20,14 +20,14 @@ This project adheres to [Semantic Versioning](http://semver.org/).
- Check feature, which can be used to report the status of tests
- Automatic delegation of patches based on file path
- Automated documentation for the XML-RPC API. This can be found at the
- '/xmlrpc' in most patchwork deployments
+ '/xmlrpc' in most Patchwork deployments
- Selenium-based UI tests
- Vagrant support for developers
- Assorted cleanup tasks and bug fixes
### Changed
-- Patches can now be delegated to any patchwork user
+- Patches can now be delegated to any Patchwork user
- Significant updates to the documentation
## [1.0.0] - 2015-10-26
@@ -40,7 +40,7 @@ This project adheres to [Semantic Versioning](http://semver.org/).
- Support for Django Migrations. This will be the chosen method of making
database changes going forward. See below for more information
- Support for tox
-- Django management commands, which replace the existing patchwork cron scripts
+- Django management commands, which replace the existing Patchwork cron scripts
- CHANGELOG.md and UPGRADING.md docs
### Changed
@@ -48,7 +48,7 @@ This project adheres to [Semantic Versioning](http://semver.org/).
- Static files are now gather and served using the `django.contrib.staticfiles`
module, per Django best practices
- Restructured directory per modern Django standards. The `apps` directory no
- longer exists and patchwork source has instead been moved to the top level
+ longer exists and Patchwork source has instead been moved to the top level
directory
- Rewrote documentation to reflect changes in development and deployment best
practices over the past few years
@@ -70,7 +70,7 @@ This project adheres to [Semantic Versioning](http://semver.org/).
## [0.9.0] - 2015-03-22
-**NOTE:** 1.0.0 was the first release of patchwork adopting semantic versioning.
+**NOTE:** 1.0.0 was the first release of Patchwork adopting semantic versioning.
For information on *"0.9.0"* and before, please refer to Git logs.
[Unreleased]: https://github.com/getpatchwork/patchwork/compare/v1.1.0...HEAD
diff --git a/README.md b/README.md
index e16e97e..c83e7d3 100644
--- a/README.md
+++ b/README.md
@@ -1,10 +1,10 @@
-# patchwork
+# Patchwork
[![Requirements Status][badge-req-img]][badge-req-ref]
[![Docs Status][badge-doc-img]][badge-doc-ref]
[![Stories in Ready][badge-waffle-img]][badge-waffle-ref]
-**patchwork** is a patch tracking system for community-based projects. It is
+**Patchwork** is a patch tracking system for community-based projects. It is
intended to make the patch management process easier for both the project's
contributors and maintainers, leaving time for the more important (and more
interesting) stuff.
@@ -15,7 +15,7 @@ to the patch page too. The project's maintainer can then scan through the list
of patches, marking each with a certain state, such as Accepted, Rejected or
Under Review. Old patches can be sent to the archive or deleted.
-Currently, patchwork is being used for a number of open-source projects, mostly
+Currently, Patchwork is being used for a number of open-source projects, mostly
subsystems of the Linux kernel. Although Patchwork has been developed with the
kernel workflow in mind, the aim is to be flexible enough to suit the majority
of community projects.
@@ -45,7 +45,7 @@ For further information, please refer to the [docs][docs].
# Contact
For bug reports, patch submissions or other questions, please use the
-[patchwork mailing list][pw-ml].
+[Patchwork mailing list][pw-ml].
[badge-doc-ref]: https://patchwork.readthedocs.org/en/latest/
[badge-doc-img]: https://readthedocs.org/projects/patchwork/badge/?version=latest
diff --git a/UPGRADING.md b/UPGRADING.md
index e199855..35c75e5 100644
--- a/UPGRADING.md
+++ b/UPGRADING.md
@@ -7,7 +7,7 @@ little to no changes.
## 0.9.0 to 1.0.0
-Version 1.0.0 changes a few admin-visible components of patchwork so
+Version 1.0.0 changes a few admin-visible components of Patchwork so
upgrading involves a few steps.
### Database Migrations
@@ -37,7 +37,7 @@ Merge your previous settings (from `apps/local_settings.py`) into this file.
### Fixup external references to `apps/`
-The `apps/` directory is gone; the patchwork module is now in the top-level
+The `apps/` directory is gone; the Patchwork module is now in the top-level
directory. If you have scripts that run anything from `apps/` (e.g. incoming
mail parsers that call `parsemail.sh`, and cron scripts), then remove the
`apps/` directory from those:
@@ -59,7 +59,7 @@ too.
Static content should now be located in the folder indicated by `STATIC_ROOT`.
This should point somewhere sensible (e.g. the absolute path of `htdocs/static`
-in the patchwork tree).
+in the Patchwork tree).
You'll need to set the `STATIC_ROOT` setting in your settings file.
@@ -79,7 +79,7 @@ will be:
### Use new management console
-The patchwork cron script (`bin/patchwork-cron.py`) has been moved to a
+The Patchwork cron script (`bin/patchwork-cron.py`) has been moved to a
`manage.py` command. Instead of running `patchwork-cron.py`, you should now
run:
diff --git a/docs/api.md b/docs/api.md
index 04026d8..b7164a5 100644
--- a/docs/api.md
+++ b/docs/api.md
@@ -13,16 +13,16 @@ You can find this at the following URL:
http://patchwork.example.com/xmlrpc/
-Where `patchwork.example.com` refers to the URL of your patchwork instance.
+Where `patchwork.example.com` refers to the URL of your Patchwork instance.
-**NOTE:** Automatic documentation generation for the patchwork API was
+**NOTE:** Automatic documentation generation for the Patchwork API was
introduced in Patchwork v1.1. Prior versions of Patchwork do not offer this
functionality.
## Developing Your Own Client
You need to connect to the server. Some methods require authentication (via
-HTTP Basic Auth) while others do not. Authentication uses your patchwork
+HTTP Basic Auth) while others do not. Authentication uses your Patchwork
account and the on-server documention will indicate where it is necessary.
We will only cover the unauthenticated method here for brevity - please
consult the [`xmlrpclib`] documentation for more detailed examples:
diff --git a/docs/contributing.md b/docs/contributing.md
index 1e61b7f..fc70301 100644
--- a/docs/contributing.md
+++ b/docs/contributing.md
@@ -13,12 +13,12 @@ below for more information on usage of this tool.
## Testing
-patchwork includes a [tox][ref-tox] script to automate testing. This requires
+Patchwork includes a [tox][ref-tox] script to automate testing. This requires
a functional database and some Python requirements like `tox`. Please refer
to the [development guide][doc-development] for information on how to configure
these.
-Assuming these requirements are met, actually testing patchwork is quite easy
+Assuming these requirements are met, actually testing Patchwork is quite easy
to do. To start, you can show the default targets like so:
$ tox --list
@@ -36,7 +36,7 @@ command:
$ tox -e py27-django18 patchwork.tests.SubjectCleanUpTest
-Because patchwork support multiple versions of Django, it's very important
+Because Patchwork support multiple versions of Django, it's very important
that you test against all supported versions. When run without argument, tox
will do this:
diff --git a/docs/deployment.md b/docs/deployment.md
index f53d27f..e8dcd0f 100644
--- a/docs/deployment.md
+++ b/docs/deployment.md
@@ -1,19 +1,19 @@
# Deployment
-This document describes the necessary steps to configure patchwork in a
+This document describes the necessary steps to configure Patchwork in a
production environment. This requires a significantly "harder" deployment than
-the one used for development. If you are interested in developing patchwork,
+the one used for development. If you are interested in developing Patchwork,
please refer to [the development guide][doc-development] instead.
-This document describes a two-node installation of patchwork, consisting of
+This document describes a two-node installation of Patchwork, consisting of
a database sever and an application server. It should be possible to combine
-these machines for smaller patchwork instances. It should also be possible to
+these machines for smaller Patchwork instances. It should also be possible to
configure high availability deployment through use of additional database and
application machines, though this is out of the scope of this document.
## Deployment Guides, Provisioning Tools and Platform-as-a-Service
-Before continuing, it's worth noting that patchwork is a Django application.
+Before continuing, it's worth noting that Patchwork is a Django application.
With the exception of the handling of incoming mail (described below), it
can be deployed like any other Django application. This means there are tens,
if not hundreds, of existing articles and blogs detailing how to deploy an
@@ -46,8 +46,8 @@ For the purpose of this guide, we will assume the following machines:
| application | 10.1.1.2 |
We will use the database server to, ostensibly enough, host the database for
-the patchwork instance. The application server, on the other hand, will host
-the patchwork instance along with the required reverse proxy and WSGI HTTP
+the Patchwork instance. The application server, on the other hand, will host
+the Patchwork instance along with the required reverse proxy and WSGI HTTP
servers.
We expect a Ubuntu 15.04 installation on each of these hosts: commands,
@@ -71,7 +71,7 @@ should be exported on all systems:
<dt>PW_DB_NAME=patchwork</dt>
<dd>Name of the database</dd>
<dt>PW_DB_USER=www-data</dt>
- <dd>Username that the patchwork app will access the database with</dd>
+ <dd>Username that the Patchwork app will access the database with</dd>
</dl>
## Database
@@ -91,7 +91,7 @@ different RDBMS. Install the required packages.
### Configure Database
PostgreSQL created a user account called `postgres`; you will need to run
-commands as this user. Use this account to create the database that patchwork
+commands as this user. Use this account to create the database that Patchwork
will use, using the credentials we configured earlier.
$ sudo -u postgres createdb $PW_DB_NAME
@@ -109,7 +109,7 @@ These steps should be run on the application server.
### Install Packages
-The first requirement is patchwork itself. It can be downloaded like so:
+The first requirement is Patchwork itself. It can be downloaded like so:
$ wget https://github.com/getpatchwork/patchwork/archive/v1.1.0.tar.gz
@@ -124,7 +124,7 @@ that people may be able to view your code over the Web. This is a security
risk.
Next we require Python. If not already installed, then you should do so now.
-patchwork supports both Python 2.7 and Python 3.3+, though we would suggest
+Patchwork supports both Python 2.7 and Python 3.3+, though we would suggest
using the latter to ease future upgrades:
$ sudo apt-get install python3 # or 'python' if using Python 2.7
@@ -141,11 +141,11 @@ corresponding distro package for each of these requirements. For example:
**NOTE:** The [pkgs.org][ref-pkgs] website provides a great reference for
identifying the name of these dependencies.
-### Configure patchwork
+### Configure Patchwork
You will also need to configure a [settings][ref-django-settings] file for
Django. A sample settings file is provided that defines default settings for
-patchwork. You'll need to configure settings for your own setup and save this
+Patchwork. You'll need to configure settings for your own setup and save this
as `production.py`.
$ cp patchwork/settings/production.example.py \
@@ -248,7 +248,7 @@ These steps should be run on the application server.
### Install Packages
-We will use nginx and uWSGI to deploy patchwork, acting as reverse proxy server
+We will use nginx and uWSGI to deploy Patchwork, acting as reverse proxy server
and WSGI HTTP server respectively. Other options are available, such as
Apache+mod_wsgi or nginx+Gunicorn. While we don't document these, sample
configuration files for the former case are provided in `lib/apache2/`.
@@ -258,7 +258,7 @@ configuration files for the former case are provided in `lib/apache2/`.
### Configure nginx and uWSGI
Configuration files for nginx and uWSGI are provided in the `lib` subdirectory
-of the patchwork source code. These can be modified as necessary, but for now
+of the Patchwork source code. These can be modified as necessary, but for now
we will simply copy them.
First, let's load the provided configuration for nginx:
@@ -321,7 +321,7 @@ Next up, restart the nginx service:
$ sudo systemctl nginx restart
$ sudo systemctl nginx status
-patchwork uses a cron script to clean up expired registrations and send
+Patchwork uses a cron script to clean up expired registrations and send
notifications of patch changes (for projects with this enabled). Something like
this in your crontab should work.
@@ -338,7 +338,7 @@ website address (in the Sites section of the admin console, found at `/admin`).
## Incoming Email
-patchwork is designed to parse incoming mails which means you need an address
+Patchwork is designed to parse incoming mails which means you need an address
to receive email at. This is a problem that has been solved for many webapps,
thus there are many ways to go about this. Some of these ways are discussed
below.
@@ -347,9 +347,9 @@ below.
The most flexible option is to configure our own mail transfer agent (MTA) and
Postfix is as good a choice as any. While we don't cover setting up Postfix
-here (it's complicated and there are many guides already available), patchwork
+here (it's complicated and there are many guides already available), Patchwork
does include a script to take received mails and create the relevant entries
-in patchwork for you. To use this, you should configure your system to forward
+in Patchwork for you. To use this, you should configure your system to forward
all emails to a given localpart (the bit before the `@`) to this script. Using
the `patchwork` localpart (e.g. `patchwork at example.com`) you can do this like
so:
@@ -378,7 +378,7 @@ One could also use an email account provided by a run-of-the-mill email
provider and retrieve mail using IMAP or POP3. This may be suitable for
low-volume mailing lists but be warned: this will introduce a significant lag
between when a patch is submitted to a mailing list and when it appears in
-patchwork.
+Patchwork.
### Use a Email-as-a-Service Provider
@@ -388,14 +388,14 @@ are a variety of web services available that offer "Email-as-as-Service".
These services typically convert received emails into HTTP POST requests to
your endpoint of choice, allowing you to sidestep configuration issues. We
don't cover this here, but a simple wrapper script coupled with one of these
-services can be more than to get email into patchwork.
+services can be more than to get email into Patchwork.
You can also create such as service yourself using a PaaS provider that
supports incoming mail and writing a little web app.
## (Optional) Configure your VCS to Automatically Update Patches
-The `tools` directory of the patchwork distribution contains a file named
+The `tools` directory of the Patchwork distribution contains a file named
`post-receive.hook` which is a sample git hook that can be used to
automatically update patches to the `Accepted` state when corresponding
commits are pushed via git.
diff --git a/docs/development.md b/docs/development.md
index ace9e59..ddfbcb4 100644
--- a/docs/development.md
+++ b/docs/development.md
@@ -1,7 +1,7 @@
# Development
-This document describes the necessary steps to configure patchwork in a
-development environment. If you are interested in deploying patchwork in a
+This document describes the necessary steps to configure Patchwork in a
+development environment. If you are interested in deploying Patchwork in a
production environment, please refer to [the deployment guide][doc-deployment]
instead.
@@ -13,8 +13,8 @@ The latest version of Patchwork is available with git. To download:
## Vagrant-Based Installation
-patchwork provides a Vagrantfile that can be used to quickly configure
-patchwork in a delopment environment. Like any Vagrant VM, you can start this
+Patchwork provides a Vagrantfile that can be used to quickly configure
+Patchwork in a delopment environment. Like any Vagrant VM, you can start this
using the `vagrant up` command:
$ cd patchwork # the path to the repo you cloned above
@@ -27,7 +27,7 @@ Alternatively, manual installation steps are provided below.
## Install Required Packages
-There are a number of different requirements for developing patchwork:
+There are a number of different requirements for developing Patchwork:
* Python and libraries
* A supported RDBMS
@@ -44,15 +44,15 @@ on many installations, though they can also be installed manually using the
It's a good idea to use [virtual environments][ref-venv] to develop Python
software. Virtual environments are "instances" of your system Python without
any of the additional Python packages installed. They are useful to develop and
-possibly deploy patchwork against a "well known" set of dependencies, but they
-can also be used to test patchwork against several versions of Django.
+possibly deploy Patchwork against a "well known" set of dependencies, but they
+can also be used to test Patchwork against several versions of Django.
If you do not have `virtualenv` installed then you should install it now. This
can be installed using the `python-virtualenv` or `python3-virtualenv`
packages. Alternatively you can install these using `pip`.
It is also helpful to install [`tox`][ref-tox] which is used for running tests
-in patchwork. This can be installed using the `python-tox` or `python3-tox`
+in Patchwork. This can be installed using the `python-tox` or `python3-tox`
packages, or via `pip`.
### Database Requirements
@@ -64,16 +64,16 @@ on Debian-based Debian-based distros like Ubuntu and `mysql-devel` or
`postgresql-devel` on RHEL-based distros.
**NOTE:** While Django provides support for
-[multiple database backends][ref-django-db], patchwork itself is only tested
+[multiple database backends][ref-django-db], Patchwork itself is only tested
against MySQL/MariaDB and PostgreSQL. Should you wish to use a different
backend, ensure you validate this first (and perhaps
[upstream][doc-contributing] any changes you may find necessary).
-**NOTE:** You may be tempted to use SQLite to develop patchwork. We'd advise
+**NOTE:** You may be tempted to use SQLite to develop Patchwork. We'd advise
against doing this. SQLite supports a subset of the functionality of "full"
RDBMS like MySQL: for example, case-sensitive matching of Unicode
[is not supported][ref-sqlite-utf8]. You will find some tests provided by
-patchwork fail and some patches you develop may fail in production due to these
+Patchwork fail and some patches you develop may fail in production due to these
differences.
### Example Installations
@@ -95,7 +95,7 @@ the above command.
## Configure Virtual Environment
-**NOTE:** If you are interested in simply [testing patchwork][doc-testing],
+**NOTE:** If you are interested in simply [testing Patchwork][doc-testing],
many of the the below steps are not required. tox will automatically install
dependencies and use virtual environments when testing.
@@ -113,7 +113,7 @@ Now install the packages. Patchwork provides three requirements files.
* `requirements-dev.txt`: Packages required to configure a development
environment
-* `requirements-prod.txt`: Packages required for deploying patchwork in
+* `requirements-prod.txt`: Packages required for deploying Patchwork in
production
* `requirements-test.txt`: Packages required to run tests
@@ -123,7 +123,7 @@ We're going to install the first of these, which can be done like so:
(.venv)$ pip install -r requirements-dev.txt
**NOTE:** Once configured this does not need to be done again *unless* the
-requirements change, e.g. patchwork requires an updated version of Django.
+requirements change, e.g. Patchwork requires an updated version of Django.
## Initialize the Database
@@ -157,7 +157,7 @@ hardcoded and change the value of `DJANGO_SETTINGS_MODULE` as described below.
## Load Initial Data
Before continuing, we need to tell Django where it can find our configuration.
-patchwork provides a default development `settings.py` file for this purpose.
+Patchwork provides a default development `settings.py` file for this purpose.
To use this, export the `DJANGO_SETTINGS_MODULE` environment variable as
described below:
@@ -171,10 +171,10 @@ the `migrate` command of the `manage.py` executable:
(.venv)$ ./manage.py migrate
-Next, you should load the initial fixtures into patchwork. These initial
+Next, you should load the initial fixtures into Patchwork. These initial
fixtures provide.
-* `default_tags.xml`: The tags that patchwork will extract from mails.
+* `default_tags.xml`: The tags that Patchwork will extract from mails.
Examples: `Acked-By`, `Reviewed-By`
* `default_states.xml`: The states that a patch can be in. Examples:
`Accepted`, `Rejected`
@@ -204,12 +204,12 @@ tool. You can do this like so:
Where `mm_user` and `mm_pass` are the username and password you have registered
with on the Mailman instance found at `mm_host`.
-**NOTE:** We provide instructions for downloading archives from the patchwork
+**NOTE:** We provide instructions for downloading archives from the Patchwork
mailing list, but almost any instance of Mailman will allow downloading of
archives as seen above; simply change the `pw_url` variable defined. You can
find more informations about this [here][ref-mman-bulk].
-Load these archives into patchwork. Depending on the size of the downloaded
+Load these archives into Patchwork. Depending on the size of the downloaded
archives this may take some time:
(.venv)$ PYTHONPATH=. ./patchwork/bin/parsearchive.py \
@@ -231,7 +231,7 @@ script again.
## Django Debug Toolbar
-patchwork installs and enables the 'Django Debug Toolbar' by default. However,
+Patchwork installs and enables the 'Django Debug Toolbar' by default. However,
by default this is only displayed if you are developing on localhost. If
developing on a different machine, you should configure an SSH tunnel such
that, for example, `localhost:8000` points to `[DEV_MACHINE_IP]:8000`.
diff --git a/docs/index.md b/docs/index.md
index 6c9aa5a..601ab12 100644
--- a/docs/index.md
+++ b/docs/index.md
@@ -1,6 +1,6 @@
-# patchwork
+# Patchwork
-patchwork is a patch tracking system for community-based projects. It is
+Patchwork is a patch tracking system for community-based projects. It is
intended to make the patch management process easier for both the project's
contributors and maintainers, leaving time for the more important (and more
interesting) stuff.
@@ -11,7 +11,7 @@ to the patch page too. The project's maintainer can then scan through the list
of patches, marking each with a certain state, such as Accepted, Rejected or
Under Review. Old patches can be sent to the archive or deleted.
-Currently, patchwork is being used for a number of open-source projects, mostly
+Currently, Patchwork is being used for a number of open-source projects, mostly
subsystems of the Linux kernel. Although Patchwork has been developed with the
kernel workflow in mind, the aim is to be flexible enough to suit the majority
of community projects.
@@ -26,41 +26,41 @@ Patchwork is distributed under the [GNU General Public License][ref-gpl].
# Design
-## patchwork should supplement mailing lists, not replace them
+## Patchwork should supplement mailing lists, not replace them
Patchwork isn't intended to replace a community mailing list; that's why you
-can't comment on a patch in patchwork. If this were the case, then there would
+can't comment on a patch in Patchwork. If this were the case, then there would
be two forums of discussion on patches, which fragments the patch review
-process. Developers who don't use patchwork would get left out of the
+process. Developers who don't use Patchwork would get left out of the
discussion.
-However, a future development item for patchwork is to facilitate on-list
+However, a future development item for Patchwork is to facilitate on-list
commenting, by providing a "send a reply to the list" feature for logged-in
users.
-## Don't pollute the project's changelogs with patchwork poop
+## Don't pollute the project's changelogs with Patchwork poop
-A project's changelogs are valuable - we don't want to add patchwork-specific
+A project's changelogs are valuable - we don't want to add Patchwork-specific
metadata.
-## patchwork users shouldn't require a specific version control system
+## Patchwork users shouldn't require a specific version control system
Not everyone uses git for kernel development, and not everyone uses git for
-patchwork-tracked projects.
+Patchwork-tracked projects.
-It's still possible to hook other programs into patchwork, using the pwclient
-command-line client for patchwork, or directly to the XML RPC interface.
+It's still possible to hook other programs into Patchwork, using the pwclient
+command-line client for Patchwork, or directly to the XML RPC interface.
# Getting Started
You should check out the [deployment][doc-deployment] and
[development][doc-development] guides for information on how to configure
-patchwork for production and development environments, respectively.
+Patchwork for production and development environments, respectively.
# Support
All questions and contributions should be sent to the
-[patchwork mailing list][ref-pw-ml].
+[Patchwork mailing list][ref-pw-ml].
[ref-gpl]: http://www.gnu.org/licenses/gpl-2.0.html
[ref-pw-ml]: https://ozlabs.org/mailman/listinfo/patchwork
diff --git a/docs/releasing.md b/docs/releasing.md
index d8e005d..5974da2 100644
--- a/docs/releasing.md
+++ b/docs/releasing.md
@@ -2,7 +2,7 @@
## Versioning
-Since version 1.0, patchwork has implemented a version of
+Since version 1.0, Patchwork has implemented a version of
[Semantic Versioning][ref-semver]. To summarise, releases take the format
**MAJOR.MINOR.PATCH** (or just **MAJOR.MINOR**). We increment:
@@ -22,11 +22,11 @@ There is no cadence for releases: they are made available as necessary.
Typically all development should occur on `master`. While we will backport
bugfixes and security updates, we will not backport any new features. This
-is to ensure stability for users of these versions of patchwork.
+is to ensure stability for users of these versions of Patchwork.
## Release Checklist
* Documentation has been updated with latest release version
* Documentation references latest supported version of Django
-[ref-semver]: http://semver.org/
\ No newline at end of file
+[ref-semver]: http://semver.org/
diff --git a/docs/upgrading.md b/docs/upgrading.md
index 5f97950..453ae94 100644
--- a/docs/upgrading.md
+++ b/docs/upgrading.md
@@ -1,10 +1,10 @@
# Upgrading
**NOTE:** This document provides some general tips and tricks that one can use
-when upgrading an existing, production installation of patchwork. If you are
+when upgrading an existing, production installation of Patchwork. If you are
interested in the specific changes between each release, please refer to the
[`UPGRADING` document][gh-upgrading] instead. If this is your first time
-installing patchwork. please refer to the
+installing Patchwork. please refer to the
[installation guide][doc-installation] instead.
## Before You Start
@@ -13,14 +13,14 @@ Before doing anything, always **backup your data**. This generally means
backing up your database, but it might also be a good idea to backup your
environment in case you encounter issues during the upgrade process.
-While patchwork won't explicity prevent it, it's generally wise to avoid
+While Patchwork won't explicity prevent it, it's generally wise to avoid
upgrades spanning multiple releases in one go. An iterative upgrade approach
will provide an easier, if slower, upgrade process.
## Identify Changed Scripts, Requirements, etc.
The `UPGRADING` document provides a comprehensive listing of all
-backwards-incompatible changes that occur between releases of patchwork.
+backwards-incompatible changes that occur between releases of Patchwork.
Examples of such changes include:
* Moved/removed scripts and files
@@ -32,7 +32,7 @@ may have, such as systemd/upstart scripts, are modified accordingly.
## Understand What Requirements Have Changed
-New versions of patchwork can often require additional or updated version of
+New versions of Patchwork can often require additional or updated version of
dependencies, e.g. newer versions of Django. It is important that you
understand these requirements and can fulfil them. This is particularly true
for users relying on distro-provided packages, who may have to deal with older
@@ -42,7 +42,7 @@ you can also diff the `requirements.txt` files in each release for comparison.
## Collect Static Files
-New versions of patchwork generally contain changes to the additional files
+New versions of Patchwork generally contain changes to the additional files
like images, CSS and JavaScript. To do this, run the `collectstatic`
management commands:
@@ -52,7 +52,7 @@ management commands:
Migrations of the database can be tricky. Prior to [`v1.0.0`][gh-v1], database
migrations were provided by way of manual, SQL migration scripts. After this
-release, patchwork moved to support [Django migrations][ref-django-migrate].
+release, Patchwork moved to support [Django migrations][ref-django-migrate].
If you are upgrading from `v1.0.0` or later, it is likely that you can rely
entirely on the later to bring your database up-to-date. This can be done like
so:
@@ -64,7 +64,7 @@ the provided SQL migrations or provide your own:
* You are using Django < 1.6
- patchwork supports Django 1.6. However, Django Migrations was added in 1.7
+ Patchwork supports Django 1.6. However, Django Migrations was added in 1.7
and is [not available for previous versions][ref-south2]. As such, you must
continue to use manual migrations or upgrade your version of Django. For
many of the migrations, this can be done automatically:
@@ -75,13 +75,13 @@ the provided SQL migrations or provide your own:
however, this will fail. In this cases, these migrations will need to be
handwritten.
-* You are using Django > 1.6, but upgrading from patchwork < 1.0.0
+* You are using Django > 1.6, but upgrading from Patchwork < 1.0.0
- patchwork only started providing migrations in `v1.0.0`. SQL migrations are
+ Patchwork only started providing migrations in `v1.0.0`. SQL migrations are
provided for versions prior to this and must be applied to get the database
to the "initial" state that Django migrations expects.
-* You have diverged from upstream patchwork
+* You have diverged from upstream Patchwork
If you have applied custom patches that change the database models, the
database in an "inconsistent state" and the provided migrations will likely
@@ -89,7 +89,7 @@ the provided SQL migrations or provide your own:
Steps to handle the latter two of these are described below.
-### Upgrading a pre-v1.0.0 patchwork instance
+### Upgrading a pre-v1.0.0 Patchwork instance
The process for this type of upgrade is quite simple: upgrade using manual
SQL upgrades until better options become available. As such, you should apply
@@ -97,11 +97,11 @@ all unapplied SQL migrations that are not duplicated by Django migrations.
Once such duplication occurs, rely on the Django migrations only and continue
to do so going forward.
-### Upgrading a "diverged" patchwork instance
+### Upgrading a "diverged" Patchwork instance
This type of upgrade is a little trickier. There are two options you can take:
-1. Bring your patchwork instance back in sync with upstream
+1. Bring your Patchwork instance back in sync with upstream
2. Provide your own migrations
The former option is particularly suitable if you decide to upstream your
@@ -120,12 +120,12 @@ possible to return to using upstream code rather than maintaining a fork.
The latter option is best chosen if you wish to retain the aforementioned fork.
How you do this depends on the extensiveness of your changes, but getting the
-latest version of patchwork, deleting the provided migrations, applying any
+latest version of Patchwork, deleting the provided migrations, applying any
patches you may have and regenerating the migrations seems like the best
option.
**NOTE**: To prevent the latter case above from occuring, we'd ask that you
-submit any patches you may have to the upstream patchwork so that the wider
+submit any patches you may have to the upstream Patchwork so that the wider
community can benefit from this new functionality. Please see
[the contributing document][doc-contributing] for more informtion on this
process.
--
2.0.0
More information about the Patchwork
mailing list