Update of /cvsroot/xdoclet/xdoclet/xdocs/development
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv13648/xdoclet/xdocs/development
Modified Files:
index.xml
Log Message:
Add some best practices.
Fellow developers: please review!
Index: index.xml
===================================================================
RCS file: /cvsroot/xdoclet/xdoclet/xdocs/development/index.xml,v
retrieving revision 1.12
retrieving revision 1.13
diff -C2 -r1.12 -r1.13
*** index.xml 15 Apr 2004 11:01:32 -0000 1.12
--- index.xml 11 Sep 2004 11:14:46 -0000 1.13
***************
*** 19,22 ****
--- 19,26 ----
</p>
<p>
+ A first step in praticipating is usually to
provide patches or other contributions to entries
+ in the issue tracking system.
+ </p>
+ <p>
Feel the irresistible urge to write quality
code? Then <a href="../mail-lists.html">join</a> the XDoclet
<a href="../team-list.html">project team</a>
today (send an email to the xdoclet-devel mailing list)!
***************
*** 53,56 ****
--- 57,107 ----
</p>
</subsection>
+ <subsection name="Commits">
+ <p>
+ Before commiting at least rebuild xdoclet to
see if the changes at least compile.
+ <br/>
+ This will also run a beautifier over your java
files. Sync your IDE after the build was run
+ to grab those format changes and only commit
afterwards.
+ </p>
+ <p>
+ If possible, run the build in the samples
directory over your changes and see if this passes.
+ This is no real testsuite, but the build run
should not stop. If possible add some tags for what
+ you are testing to the samples and see if it
behavs as desired.
+ </p>
+
+ </subsection>
+ <subsection name="JIRA">
+ <p>As you already know,
+ <a
href="http://opensource.atlassian.com/projects/xdoclet/secure/BrowseProject.jspa?id=10000";>JIRA</a>
+ is used as issue tracking system. As there is
a link between JIRA and sourceforge, you should do two things:
+ <ul>
+ <li>Set your sourceforge email address
([EMAIL PROTECTED]) as email address in JIRA</li>
+ <li>For commits that link to items in
JIRA, add the issue number (e.g. XDT-399) to the commit message.</li>
+ </ul>
+ </p>
+ <p>
+ When you plan to work on an issue, assign the
issue to yourself, so other developers won't grab it as
+ well and duplicate work is done.
+ If you see that you won't solve the problem,
then assign the issue back to xdoclet-devel general user.
+ </p>
+ <p>
+ If there is an issue assigned to another
developer for a long time without any notion of activity
+ <b>and</b> you have a solution to the issue,
you can take over the issue and apply your fix.
+ </p>
+ <p>
+ If you plan to do bigger changes (more severe
than e.g. fixing a typo, throwing out unused imports etc.)
+ and there is no JIRA for it, create one. This
is generally a good idea, as the change log is built from
+ the closed JIRA issues.
+ </p>
+ <p>
+ As the changelog for a release is created from
the JIRA issues, set the release an issue was fixed
+ when closing a successful fix and select no
release when rejecting an issue (e.g. incomplete).
+ </p>
+ <p>
+ The resolved state in JIRA should only be used
to signal that the problem itself is solved (and the
+ fix applied), but there is some feedback from
the submitter needed. If an issue is solved, then
+ close it completely.
+ </p>
+ </subsection>
<subsection name="Further Reading">
<ul>
-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM.
Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php
_______________________________________________
xdoclet-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/xdoclet-devel
