[gnome-web-photo: 20/24] Update ChangeLog.README/HACKING

[Vincent Untz <vuntz src gnome org>]

commit 621edfba295d33601a7eb00ab90c22366b9d2d81
Author: Vincent Untz <vuntz gnome org>
Date:   Wed Feb 16 20:19:49 2011 +0100

    Update ChangeLog.README/HACKING

 ChangeLog.README |   64 ++++++++++++++++++++++++++++++++++++-----------------
 HACKING          |   38 +++++++++++++++++++++++--------
 2 files changed, 71 insertions(+), 31 deletions(-)
---
diff --git a/ChangeLog.README b/ChangeLog.README
index 82c5782..4a123a2 100644
--- a/ChangeLog.README
+++ b/ChangeLog.README
@@ -1,28 +1,50 @@
-GNOME Web Photo doesn't use ChangeLog anymore. Instead, we use SVN checkin
-comments to autogenerate a ChangeLog file at "make dist" time.
+=== No ChangeLog ===
 
-When committing a patch to svn, you must use a checkin comment that fully
-describes the changes made. If the checkin is related to a bug, reference
-the bug number. Example:
+ Since this module is using git, we rely on commit messages to provide change
+ history. Please write commit messages in the format described at
+ http://live.gnome.org/Git/CommitMessages
 
-        When removing a toolbar, make its items available again in the toolbar
-        editor. (Bug #131182)
+ Below is a copy of this format:
 
-Checkin comments MUST use the UTF-8 encoding.
+=== begin example commit ===
+tag: Short explanation of the commit
 
-If you forget to check in some changes that belonged in the same commit (e.g.
-you accidentally omitted a file), you must copy the checkin comment from the
-previous, incomplete checkin, and additionally reference that commit's svn
-revision number.
+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 ===
 
-DO NOT use meaningless checkin comments such as "forgotten file" !
+  - The commit message is mainly for the other people, so they should be able
+    to understand it now and six months later.
 
-If you make a major mistake in the checkin comment (e.g it is empty, or
-you've forgotten to cite the bug numbers), you must create a new checkin
-that touches all files the original checkin changed (just using whitespace
-changes preferably, or fix a random typo), and in the new checkin comment
-you must note that this new checkin fixes the original checkin, referencing
-it by its SVN revision number.
+  - 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).
 
-Do NOT commit to this module without permission from a maintainer.
-See the MAINTAINERS file for who they are.
+  - 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.
+
+  - You can prefix the first line with one tag, to make it easier to know to
+    which part of the module the commit applies. For example, a commit with
+    "fish: Make it work with newer fortune" in the gnome-panel module clearly
+    applies to the fish applet.
+
+  - 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, the body is copied from there. This main
+    description can be empty if the change is self-explanatory (eg: "Add DOAP
+    file").
+
+  - When committing code on behalf of others use the --author option, e.g. git
+    commit -a --author "Joe Coder <joe coder org>".
+
+  - When referring to a bug, you can use this form: bgo#12345. Use bgo for
+    bugzilla.gnome.org, but you can also reference bugs in other bug trackers:
+    rh means bugzilla.redhat.com, bnc means bugzilla.novell.com, lp means
+    launchpad.net, etc. Whenever possible, use the full URL of the bug, though.
+
+  - When a commit closes a bug, the commit message should contain a line like:
+    Closes: http://bugzilla.gnome.org/show_bug.cgi?id=12345
+    or simply:
+    http://bugzilla.gnome.org/show_bug.cgi?id=12345
diff --git a/HACKING b/HACKING
index 54c2f0f..ea1670c 100644
--- a/HACKING
+++ b/HACKING
@@ -1,13 +1,31 @@
-In order to keep the code nice and clean we have a few requirements you'll
-need to stick to in order to get your patch accepted:
+Hacking on gnome-web-photo
+==========================
 
-- all files have to be encoded in UTF-8
+ + The development occurs in git:
 
-  Comment blocks are written like this:
-  
-/*
- * bla_bla_cb: This is an example comment block
- */
+     http://git.gnome.org/browse/gnome-web-photo
 
-Do NOT commit to this module without permission from me 
-(chpe gnome org)
+   For information on how to access GNOME git please read:
+
+     http://live.gnome.org/Git
+
+ + Please send patches as bug reports in GNOME Bugzilla:
+
+     https://bugzilla.gnome.org/ (product gnome-web-photo)
+
+   Your patch should be in unified diff form (the -u option to GNU
+   diff). See also:
+
+     http://live.gnome.org/GnomeLove/SubmittingPatches
+
+ + Please try and send a patch against a recent version of this package.
+   Patches against git master are most preferable.
+
+ + Don't commit any but the most trivial patches without approval.
+
+ + Exceptions to this are:
+
+   - Translators may commit basic i18n related patches to the build
+     setup.
+   - Build sheriff are welcome - in accordance with the relevant build
+     sheriff constraints.