summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authormathieui <mathieui@mathieui.net>2012-03-07 17:31:41 +0100
committermathieui <mathieui@mathieui.net>2012-03-07 17:31:41 +0100
commit513ff094e3388b363e666e438be2d6db76b4542b (patch)
tree98f6404e8fe7b6f2110ae58f05d7a09f91de7280
parentc04d194ad09615832cc47dc3da832fcaaed1761a (diff)
downloadpoezio-513ff094e3388b363e666e438be2d6db76b4542b.tar.gz
poezio-513ff094e3388b363e666e438be2d6db76b4542b.tar.bz2
poezio-513ff094e3388b363e666e438be2d6db76b4542b.tar.xz
poezio-513ff094e3388b363e666e438be2d6db76b4542b.zip
Typos in the READMOE
-rw-r--r--README14
1 files changed, 7 insertions, 7 deletions
diff --git a/README b/README
index 8ebd13e9..3c1fce62 100644
--- a/README
+++ b/README
@@ -26,14 +26,14 @@ MUCs, especially XEP 0045.
=======================
You need python 3.0 (and the associated devel package, to build C modules)
or higher, and the SleekXMPP python library.
-In the developpement version, you’ll need this fork of SleekXMPP
+In the developement version, you’ll need this fork of SleekXMPP
http://github.com/louiz/SleekXMPP.
Additionally, you’ll need asciidoc and source-highlight to build the html
documentation pages. To read the documentation without these dependance,
just read the .txt files, or read it on the webpage.
The simplest way to have up-to-date dependencies and to be able to test
-this developpement version is to use the update.sh script that downloads
+this developement version is to use the update.sh script that downloads
and places them in the right directory.
You also need to compile some external C modules, to do this, just enter
@@ -69,8 +69,8 @@ feature you want.
=======================
Authors
=======================
-Florent Le Coz (louiz’) <louiz@louiz.org> (developper)
-Mathieu Pasquet (mathieui) <mathieui@mathieui.net> (developper)
+Florent Le Coz (louiz’) <louiz@louiz.org> (developer)
+Mathieu Pasquet (mathieui) <mathieui@mathieui.net> (developer)
=======================
@@ -111,7 +111,7 @@ the unstable version, which can be broken, but we should try to keep it usable
and crash-free as much as possible (so, never push to it if you are adding a
*known* crash).
-New big features that take time to be complete should be developped in feature
+New big features that take time to be complete should be developed in feature
branches (for example the “plugins” or the “opt” branches).
If it’s a really long feature, merge the “master” branch in that feature branch
from time to time, to avoid huge merges (and merge issues) when you’ll have to
@@ -120,10 +120,10 @@ Merge your work in master once it works and is usable, not necessarily when
it’s 100% finished. Polishing and last bug fixes can take place in “master”.
Conflicts should be solved with *rebase* and not with merge. This means
-that if two developpers commited one thing at the same time in their own
+that if two developers commited one thing at the same time in their own
repository, the first pushes on the public public repos, and the other
has to pull before being able to push too. In that case, the second
-developper should use the rebase command instead of merge. This avoids
+developer should use the rebase command instead of merge. This avoids
creating unnecessary “branches” and visible merges.
On the contrary, when merging feature branches back to “master”, we should
use merge with the --no-ff tag (this makes sure the branch will always