continuum-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From wsm...@apache.org
Subject svn commit: r788206 - /continuum/site/src/site/apt/development/guide-continuum-development.apt
Date Wed, 24 Jun 2009 23:12:08 GMT
Author: wsmoak
Date: Wed Jun 24 23:12:08 2009
New Revision: 788206

URL: http://svn.apache.org/viewvc?rev=788206&view=rev
Log:
Expand the commit message template to encourage including more information.
Emphasize that changes need tests and documentation.

Modified:
    continuum/site/src/site/apt/development/guide-continuum-development.apt

Modified: continuum/site/src/site/apt/development/guide-continuum-development.apt
URL: http://svn.apache.org/viewvc/continuum/site/src/site/apt/development/guide-continuum-development.apt?rev=788206&r1=788205&r2=788206&view=diff
==============================================================================
--- continuum/site/src/site/apt/development/guide-continuum-development.apt (original)
+++ continuum/site/src/site/apt/development/guide-continuum-development.apt Wed Jun 24 23:12:08
2009
@@ -8,8 +8,6 @@
 
 Developing Continuum
 
-    <<To write>>
-
 * {Creating and submitting a patch}
 
  When you have either completed an issue or just want some feedback on the work you have
done, create a patch
@@ -50,10 +48,10 @@
  A couple of notes:
 
  * If you are using another tool for creating patches, make sure that the patch doesn't include
absolute paths.
- Including absolute paths in the patch will make the useless for us as we most likely don't
have the same directory
+ Including absolute paths in the patch will make it difficult for us to apply as we most
likely don't have the same directory
  structure as you.
 
- * Make sure that you follow our code style.
+ * Make sure that you follow the code style.
 
 * Other useful Subversion commands while developing
 
@@ -99,16 +97,16 @@
     before a patch is contributed, so if you are unsure, discuss it there or on the mailing
lists first. Feel free to
     continue discussing it (with new justification) if you disagree, or appeal to a wider
audience on the mailing lists.
 
-  * Whether it contains tests. It is expected that any patches relating to functionality
will be accompanied by unit tests
-    and/or integration tests. It is strongly desired (and will be requested) for bug fixes
too, but will not be the basis
-    for not applying it. At a bare minimum, the change should not decrease the amount of
automated test coverage.
+  * Whether it contains tests. It is expected that any patches will be accompanied by unit
tests
+    and/or integration tests.  If you're not sure how to write a test for your change, please
ask for help on the dev list.
+    At a bare minimum, the change should not decrease the amount of automated test coverage.
     As a community, we are focusing on increasing the current coverage, as there are several
areas that do not receive automated testing.
 
-  * Whether it contains documentation. All new functionality needs to be documented for users,
even if it is very rough
+  * Whether it contains documentation. All functionality needs to be documented for users
and developers, even if it is very rough
     for someone to expand on later. While rough is acceptable, incomplete is not. As with
automated testing, as a community
     we are striving to increase the current coverage of documentation.
 
-Above all, don't be discouraged. These are the same requirements the current commiters should
hold each other to as well.
+Above all, don't be discouraged. These are the same requirements the current committers should
hold each other to as well.
 And remember, your contributions are always welcome!
 
 * {Commit Message Template}
@@ -116,18 +114,25 @@
   Commits should have a message that follows this template:
 
 -----
-[issue1, issue2] <<comment>>
-Submitted by: (when it was a patch, put that persons name there)
+[issue] <<summary>>
+<<description>>
+Submitted by: <<name>>
 -----
 
-  <<issue>> can be omitted if there was no relevant JIRA issue, though it is
strongly encouraged to create one for significant
-  changes.
+  <<[issue]>> can be omitted if there is no relevant JIRA issue, though it is
strongly encouraged to create one for
+  any non-trivial change.
+
+  <<summary>> should briefly describe the problem or intent.  Often the summary
from the JIRA issue will work.
+
+  <<description>> should describe what was changed, and why.  This is important
so that others can follow your thought
+  process and evaluate the change.
 
-  <<Submitted by>> only needs to be specified when a patch is being applied for
a non-committer.
+  <<Submitted by>> only needs to be included when a patch is being applied for
a non-committer.
   
 eg:
 
 -----
-[CONTINUUM-1234] Added the foo to the bar
+[CONTINUUM-1234] Fix X when doing Y
+Added a check to make sure Z is true before we decide to... This will prevent...  
 Submitted by: Baz Bazman
 -----



Mime
View raw message