Menu
▾
▴
[Sblim-commit] jsr48-client/src/org/sblim/cimclient/doc-files development.html, 1.1.2.5, 1.1.2.6
|
From: Dave B. <bla...@us...> - 2013-02-24 14:25:17
|
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> |
