Update HACKING file. Fixes bug #447689

1 files changed, 5 insertions, 219 deletions

diff --git a/HACKING b/HACKING
index 7c0e9b8c48..7de98a31e3 100644
--- a/HACKING
+++ b/HACKING
@@ -1,195 +1,12 @@
-
 1 Patch guidelines
 
-This section lists some guidelines for writing a good patch which is
-more likely to be accepted.
-
-Any new features or large scale work should first be discussed on the
-evolution-hackers list first.  This will ensure the idea fits in the
-direction we wish to take Evolution, and also that the effort is not
-duplicated.  See section 3 for details on the mailing lists.
-
-1.1 Patch basics
-
-o The patch should apply cleanly at the time it is made.
-
-o It must compile once applied.
-
-o It must not generate any more compile time warnings than were
-  already there.  This may be platform dependent so simply do your
-  best.
-
-o It must conform to C89/C90 (ANSI/ISO C), and build with gcc using
-  the default compile flags.
-
-  The primary trap is that in C99 you may define variables anywhere in
-  the code, in C89 they must be declared in a declaration block which
-  follows any block start '{'.
-
-  If you wish to ensure the code is C89, try the following.
-
-  From the gcc manual page:
-                                                           "To select
-  this standard in GCC, use one of the options `-ansi', `-std=c89' or
-   `-std=iso9899:1990'; to obtain all the diagnostics required by the
-  standard, you should also specify `-pedantic'" ...
-
-  You may actually have to use '-std=gnu89' if libraries have taken
-  advantage of gcc extensions and where not compiled similarly, as the
-  above options will disable all gnu extensions.
-
-  [FIXME: Add the same option for Forte here]
-
-o It should not add any extra debug printing by default, unless the
-  patch is specifically to add extra debug printing.
-
-o It should not use any gcc extensions, except where they are properly
-  checked for and not used with other compilers.  glib provides some
-  of these features as portable macros and should be used when they
-  cover the required functionality.
-
-o It must include ChangeLog entries in the appropriate ChangeLog for
-  the file modified.  Use emacs, C-4-a will start a properly formatted
-  ChangeLog entry in the correct ChangeLog file automatically.
-
-o If it is from a bug report, it must reference the bug number, and if
-  it isn't in the gnome bugzilla, it must reference the bug system from
-  whence it came.
-
-1.1 GUI changes
-
-If the change requires non-trivial user interface changes, then they
-will have to be discussed and approved on the evolution-hackers list
-first.  This is highly recommended before embarking on any UI work, or
-large scale work in general.  The Gnome HIG document is the place to
-start on any UI changes or additions.
-
-1.2 Translated string changes
-
-Any changes to translated strings in a stable release must be
-discussed on the hackers list (see section 3), and/or as part of the
-patch submission.  There must be very good reasons for changing the
-strings in this case.
-
-1.3 Coding style
-
-Generally the coding style employed matches the "Linux Kernel" style,
-that is, basically K&R style indenting with 8 space tabs.  Tabs should
-be used rather than space characters.  Reformatting of otherwise
-unchanged code is not acceptable.  Editors should have any automatic
-reformatting features disabled.
-
-K&R style indenting puts braces on the same line.  The opening
-parenthesis of a function call or conditional statement should be on
-the same line as the function.  "else" "} else" and "} else {" must
-always occur on lines by themselves.
-
-A single blank line should follow {} blocks (if not immediately
-followed by the close of another block), and conditional statements,
-and be used to separate logical groups of statements in the same
-block.
-
-A single blank line only should separate functions, and other
-structures at the top level of the file (i.e. outside functions).  The
-same rule applies to variable declarations at the start of a block.
-
-An example of the most-developer-preferred formatting:
-
-TheType
-the_function (int frank)
-{
-        int a = 1;
-
-        if (a == frank) {
-                a = foo (a);
-        } else {
-                do {
-                        a = bob (frank) + a;
-        	} until (a == frank);
-
-                frank = a;
-        }
-
-        return (TheType) a;
-}
+Procedures that should be followed when submitting patches for 
+Evolution are available on 
+http://projects.gnome.org/evolution/patch.shtml
 
-Where there are slight stylistic differences, the style in the
-surrounding code should be followed.
+Further information:
 
-1.3.1 Object casts
-
-You can either use C style casts, or Gtk style casts.  Note that Gtk
-style casts can add significant execution overhead, which is not
-adding any extra checking.  e.g. if arguments have already been
-type-checked by preconditions.  Putting a space between a cast and a
-variable is optional, but preferred by most of the developers.
-
-1.3.2 Preconditions
-
-External api entry points should have preconditions (g_return_if_fail,
-etc), although their use varies from case to case.  Internal entry
-points and/or when you are guaranteed the type has already been
-checked, are unecessary.  Object initialisation and other virtual
-method invocations are considered internal entry points.
-
-1.3.3 Line lengths
-
-Do not expend effort and resort to unreadable formatting merely to fit
-any long lines into 80 column widths.  We use 8 space tabs, and
-because of the lack of namespacing other than extending the function
-name, many of the function and type names are too long for this to be
-practical.  We now all uses high resolution displays, and not
-circa-80's VT100 terminals!
-
-On the other hand, lines should generally not exceed 100 characters,
-and absolutely not exceed 160 characters.  If your tab nesting is too
-deep you probably have a poor design that needs rethinking.
-
-1.4 Design
-
-This is a tricky issue to document, but the design of new code should
-`fit' with the existing design of the relevent module.  It should at
-the very least, be no worse.
-
-Code should not cross existing abstraction boundaries or attempt
-to remove or work around them, if required the existing design may
-need adjustment.
-
-Type and method names should follow the existing practice in the
-surrounding code.  Method arguments should follow the same order as
-related methods, and should use the same names for matching
-parameters.
-
-Per file, static class globals are ok, true globals may be ok, but
-should be used sparingly.  Use 'i' for a loop variable, if that's all
-it is, don't use 'the_current_index'.  etc.
-
-If in doubt, ask on the lists.
-
-2. Patch submission guidelines
-
-This section outlines procedures that should be followed when
-submitting patches for Evolution.
-
-The patch must simply be attached to an appropriate, open bug on
-bugzilla.gnome.org.
-
-For discussion of the patch, or to expediate processing of the patch,
-an email may be sent to the evolution-patches list.  See the mailing
-lists section for more information.  You may attach patches when
-sending to this list for discussion.
-
-Any non-trival patches (patches of more than 1 or 2 changed lines in
-more than 5 isolated locations) also require copyright assignment.
-See http://developer.ximian.com/projects/evolution/copyright.html for
-details.
-
-If you follow the guidelines listed here, you should generally expect
-a response within 2 working days.  If you re-send the same patch
-repeatedly, you will more likely receive less attention.  Do not
-re-send the same patch repeatedly.
-
-2.1 Subject Lines
+1.1 Subject Lines
 
 If the patch addresses a specific bug in bugzilla.gnome.org, then the
 bug number must be included in the subject line, preferably near the
@@ -240,34 +57,3 @@ Generally, any patch to the stable branch from non-core developers
 must address a specific bug in bugzilla.gnome.org.  The patch should
 also be attached to the bug in question.  The patch must not be
 applied until reviewed.
-
-3 Mailing lists
-
-3.1 Evolution Hackers
-
-If you wish to discuss patches before they are submitted, or ideas
-before you start to work on them, do it on the evolution-hackers list,
-which may be subscribed and viewed at
-`http://lists.ximian.com/mailman/listinfo/evolution-hackers'.
-
-This is a low-volume list (5-10 posts per day on average).
-
-Some patches may be discussed here to get a wider audience, although
-once a patch has been made it should generally be discussed on
-evolution-patches.  Large posts are blocked, so they should be sent to
-the patches list intsead, or reference resources elsewhere.
-
-Feature requests, bug reports, and other user related discussions,
-without the intention to write code to address them, will be ignored.
-
-3.2 Evolution Patches
-
-The patch discussion list evolution-patches may be subscribed and
-viewed at
-`http://lists.ximian.com/mailman/listinfo/evolution-patches'.  Once a
-patch has been written, it may be submitted here for discussion, as
-well as final approval.
-
-Patches may be sent to this list as attachments for discussion.
-
-Any non-patch related postings to this list will be ignored.