Update of /cvsroot/sblim/jsr48-client/src/org/sblim/cimclient/doc-files
In directory sfp-cvs-1.v30.ch3.sourceforge.com:/tmp/cvs-serv25783/src/org/sblim/cimclient/doc-files
Modified Files:
Tag: Experimental
development.html
Log Message:
2623 Reflect SourceForge upgrade in documentation
Index: development.html
===================================================================
RCS file: /cvsroot/sblim/jsr48-client/src/org/sblim/cimclient/doc-files/development.html,v
retrieving revision 1.1.2.5
retrieving revision 1.1.2.6
diff -u -d -r1.1.2.5 -r1.1.2.6
--- development.html 22 Apr 2010 14:39:53 -0000 1.1.2.5
+++ development.html 24 Feb 2013 14:25:15 -0000 1.1.2.6
@@ -1,7 +1,7 @@
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<html><head><!--
*
- * (C) Copyright IBM Corp. 2006, 2010
+ * (C) Copyright IBM Corp. 2006, 2013
*
* THIS FILE IS PROVIDED UNDER THE TERMS OF THE ECLIPSE PUBLIC LICENSE
* ("AGREEMENT"). ANY USE, REPRODUCTION OR DISTRIBUTION OF THIS FILE
@@ -20,6 +20,7 @@
* 2799260 2009-06-01 raman_arora Fix left over @author tag from Java5 upgrade
* 2972697 2010-03-18 blaschke-oss Fix spelling errors in HTML files
* 2990370 2010-04-22 blaschke-oss Development/unittest HTML out of date
+ * 2623 2013-02-24 blaschke-oss Reflect SourceForge upgrade in documentation
--></head>
<body style="background-color: white;">
@@ -41,22 +42,23 @@
Once a patch has been approved in the community review it will be merged into the "HEAD" branch. When
a new release is published it represents the content of the "HEAD" branch at the release date. Of course,
all releases have a corresponding version tag in CVS.</p>
-<h2>Bug Tracker</h2>
-The Bug Tracker process step are as follows
+<h2>Bug Tickets</h2>
+The Bug Ticket process step are as follows
<ol>
- <li>Somebody (a.k.a. the bug owner) files a bug in Bug Tracker.</li>
+ <li>Somebody (a.k.a. the bug owner) files a bug in Bug Tickets.</li>
<li>A developer reads the problem description and assigns the bug.</li>
- <li>A developer either accepts the bug (resolution->Accepted)<ul><li>Proceed with step 4</li></ul> or denies it (resolution->
- Duplicate, Invalid, Rejected, Wont Fix or Works For Me).<ul><li>A reasonable justification will be posted
+ <li>A developer either accepts the bug (Status->open-accepted)<ul><li>Proceed with step 4</li></ul>
+ requests additional information (Status->open-needinfo)<ul><li>Await new information, repeat step 3</li></ul>
+ or denies it (Status->pending-duplicate, pending-invalid, pending-rejected, pending-wont-fix or pending-works-for-me).<ul><li>A reasonable justification will be posted
to the comments. Once the bug owner agrees we proceed with step 8.</li></ul></li>
- <li>A developer creates a patch. The patch will be attached to Bug Tracker and committed into the
- Experimental branch (resolution->Fixed).</li>
- <li>The community review is initiated. A corresponding comment is added to Bug Tracker.</li>
- <li>The community review is completed and successful. A corresponding comment is added to Bug Tracker
- and the patch is merged into the HEAD branch. The bug status is changed to Pending. If the community review
+ <li>A developer creates a patch. The patch will be attached to Bug Ticket and committed into the
+ Experimental branch (Status->open-fixed).</li>
+ <li>The community review is initiated. A corresponding comment is added to Bug Ticket.</li>
+ <li>The community review is completed and successful. A corresponding comment is added to Bug Ticket
+ and the patch is merged into the HEAD branch. The bug Status is changed to pending-fixed. If the community review
was unsuccessful we go back to step 4.</li>
- <li>The patch is picked up by the next release.</li>
- <li>The bug is closed (status->Closed).</li>
+ <li>The patch is picked up by the next release. A corresponding comment is added to Bug Ticket.</li>
+ <li>The bug is closed (Status->closed-*).</li>
</ol>
<h2>Patches</h2>
Patches are created relative to the latest release. We usually use the "create patch" action
@@ -172,8 +174,8 @@
before any code is committed. There are a few warnings that can be ignored for good reason, e.g. a
precautionary throws declaration where the declared exception is not actually thrown by the current
implementation. But the cases are rare.</p>
-<p>All code is REQUIRED to compile on IBM/SUN Java 1.5.x/1.6.x.
-Therefore Java 1.6 constructs are not allowed.</p>
+<p>All code is REQUIRED to compile on IBM/SUN Java 1.5.x/1.6.x/1.7.x.
+Therefore Java 1.6 and 1.7 constructs are not allowed.</p>
<p>Use of default or protected visibility is discouraged. Fields should be private, provide getters
and setters for public or subclass access. External and internal classes/interfaces should be clearly
separated by using "*.internal" packages.</p>
|
