From d9a380467bfc745e64141a2ffac0549cac06bd02 Mon Sep 17 00:00:00 2001 From: Carlos Garcia Campos Date: Tue, 28 Apr 2009 11:55:36 +0200 Subject: [PATCH] [doc] Add README.commits copied from Nautilus --- README.commits | 68 ++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 68 insertions(+) create mode 100644 README.commits diff --git a/README.commits b/README.commits new file mode 100644 index 00000000..0f2def96 --- /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. + +Notes: + +* 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 " and --signoff. + + +Alexander Larsson +17 Apr 2009 -- 2.43.5