[gnomeweb-wml] Update the patch submission process.

[Matthew Barnes <mbarnes src gnome org>]

commit 9a7c3922f595ce2d109f13180ca9dca13627d89e
Author: Matthew Barnes <mbarnes redhat com>
Date:   Tue Jan 19 15:15:19 2010 -0500

    Update the patch submission process.

 projects.gnome.org/evolution/patch.shtml |   30 ++++++++++++------------------
 1 files changed, 12 insertions(+), 18 deletions(-)
---
diff --git a/projects.gnome.org/evolution/patch.shtml b/projects.gnome.org/evolution/patch.shtml
index ec9eb26..1c687f0 100644
--- a/projects.gnome.org/evolution/patch.shtml
+++ b/projects.gnome.org/evolution/patch.shtml
@@ -87,7 +87,14 @@ the_function (int frank)
 <p>Where there are slight stylistic differences, the style in the surrounding code should be followed. These are guidelines; use your own best judgement.</p>
 <strong>Object Casts</strong> 
 
-<p>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.</p>
+<p>Use GObject style casts for GObject instances, which provides extra safety checks over C style casts.</p>
+
+<p>For example:</p>
+<pre>
+<code>GtkWidget *widget = (GtkWidget *) button;  /* unsafe */
+GtkWidget *widget = GTK_WIDGET (button);   /* preferred */
+</code>
+</pre>
 <strong>Preconditions</strong> 
 
 <p>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.</p>
@@ -105,29 +112,16 @@ the_function (int frank)
 
 <p>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.</p>
 
-<p>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.</p>
+<p>Per file, static class globals are ok, true globals may be ok, but should be used sparingly. Use 'ii' for a loop variable, if that's all it is, don't use 'the_current_index'. etc.</p>
 
 <p><strong>If in doubt, ask on the lists.</strong></p>
 
 <h3>Patch Submission Process</h3>
 
-<p>This section outlines procedures that should be followed when submitting patches to evolution, via the evolution-patches mailing list. For spam-prevention reasons, you must subscribe to the list at <a href="http://mail.gnome.org/mailman/listinfo/evolution-patches";>mail.gnome.org</a> before you can submit patches to it.</p>
-
-<p>If you attach a patch to a bug report, please also send it to the list.</p>
+<p>Patches should be submitted to our bug tracking system at <a href="http://bugzilla.gnome.org/";>bugzilla.gnome.org</a>.</p>
 
-<p>Historically, the Evolution project required the copyright on all
-non-trivial patches to be assigned to Novell.  As of July 2008, this
-is no longer required.  See this
-<a href="http://mail.gnome.org/archives/desktop-devel-list/2008-July/msg00065.html";>announcement</a>
-for details.</p>
+<p>Note that the <a href="http://mail.gnome.org/mailman/listinfo/evolution-patches";>evolution-patches mailing list</a> is no longer used since we've found that patches are easier to track and discuss in <a href="http://bugzilla.gnome.org/";>Bugzilla</a>.
 
-<p>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 less likely to receive attention. <em>Do not re-send the same patch repeatedly.</em></p>
-<strong>Clear Subject Lines</strong> 
-
-<ul>
-  <li>If the patch addresses a specific bug, please include the bug number in the subject line, along with a summary or description of the bug(s) being addressed, should be the remainder of the subject.</li>
-
-  <li>It is unnecessary to add "[PATCH]", "patch" or similar to the subject line, unless it is being cross-posted to other non-patch</li>
-</ul>
+<p>Historically, the Evolution project required the copyright on all non-trivial patches to be assigned to Novell.  As of July 2008, this is no longer required.  See this <a href="http://mail.gnome.org/archives/desktop-devel-list/2008-July/msg00065.html";>announcement</a> for details.</p>
 
 <!--#include virtual="foot.shtml" -->