Web   ·   Wiki   ·   Activities   ·   Blog   ·   Lists   ·   Chat   ·   Meeting   ·   Bugs   ·   Git   ·   Translate   ·   Archive   ·   People   ·   Donate
path: root/README.commits
diff options
authorCarlos Garcia Campos <carlosgc@gnome.org>2009-04-28 09:55:36 (GMT)
committer Carlos Garcia Campos <carlosgc@gnome.org>2009-04-28 09:55:36 (GMT)
commitd9a380467bfc745e64141a2ffac0549cac06bd02 (patch)
tree169735d86fc4083bc79461e149838ada95c3fdd9 /README.commits
parentd224d9bb721bf7e70dafc519ac24855e17b0d603 (diff)
[doc] Add README.commits copied from Nautilus
Diffstat (limited to 'README.commits')
1 files changed, 68 insertions, 0 deletions
diff --git a/README.commits b/README.commits
new file mode 100644
index 0000000..0f2def9
--- /dev/null
+++ b/README.commits
@@ -0,0 +1,68 @@
+Evince is part of the GNOME git repository. At the current time, any
+person with write access to the GNOME repository, can make changes to
+Evince. This is a good thing, in that it encourages many people to work
+on Evince, and progress can be made quickly. However, we'd like to ask
+people committing to Evince to follow a few rules:
+0) Ask first. If your changes are major, or could possibly break existing
+ code, you should always ask. If your change is minor and you've
+ been working on Evince for a while it probably isn't necessary
+ to ask. But when in doubt, ask. Even if your change is correct,
+ somebody may know a better way to do things.
+ If you are making changes to Evince, you should be subscribed
+ to evince-list@gnome.org. (Subscription address:
+ evince-list-request@gnome.org.) This is a good place to ask
+ about intended changes.
+ #evince on GIMPNet (irc.gimp.org, irc.us.gimp.org, irc.eu.gimp.org, ...)
+ is also a good place to find Evince developers to discuss changes with.
+1) Ask _first_.
+2) With git, we no longer maintain a ChangeLog file, but you are expected
+ to produce a meaningful commit message. Changes without a sufficient
+ commit message will be reverted. See below for the expected format
+ of commit messages.
+3) Try to separate each change into multiple small commits that are
+ independent ("micro commits" in git speak). This way its easier to
+ see what each change does, making it easier to review, to cherry pick
+ to other branches, to revert, and to bisect.
+* When developing larger features or complicated bug fixes, it is
+ advisable to work in a branch in your own cloned Evince repository.
+ You may even consider making your repository publically available
+ so that others can easily test and review your changes.
+* The expected format for git commit messages is as follows:
+=== begin example commit ===
+Short explanation of the commit
+Longer explanation explaining exactly what's changed, whether any
+external or private interfaces changed, what bugs were fixed (with bug
+tracker reference if applicable) and so forth. Be concise but not too brief.
+=== end example commit ===
+ - Always add a brief description of the commit to the _first_ line of
+ the commit and terminate by two newlines (it will work without the
+ second newline, but that is not nice for the interfaces).
+ - First line (the brief description) must only be one sentence and
+ should start with a capital letter unless it starts with a lowercase
+ symbol or identifier. Don't use a trailing period either. Don't exceed
+ 72 characters.
+ - The main description (the body) is normal prose and should use normal
+ punctuation and capital letters where appropriate. Normally, for patches
+ sent to a mailing list it's copied from there.
+ - When committing code on behalf of others use the --author option, e.g.
+ git commit -a --author "Joe Coder <joe@coder.org>" and --signoff.
+Alexander Larsson
+17 Apr 2009