SBLIM CIM Client Development Process

Contact

If you have any questions about the SBLIM CIM Client you may contact the development lead at blaschke@us.ibm.com.

Releases

Planned releases appear in the middle of every quarter (middle of February, May, August, November). It might occur that we publish a release out of schedule on request of one of our exploiters as well.
A release is a code level that has been intensively tested and is supported. Releases are the only origins for maintenance branches.

CVS

All patches are committed to the "experimental" branch first. The code in this branch is the most active, but it hasn't undergone a community review and is therefore unapproved.
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.

Bug Tracker

The Bug Tracker process step are as follows
  1. Somebody (aka the bug owner) files a bug in Bug Traker.
  2. A developer reads the problem description and assigns the bug.
  3. A developer either accepts the bug (resolution->Accepted)
    • proceed with step 4
    or denies it (resolution-> Duplicate, Invalid, Rejected or Works For Me).
    • A reasonable justification will be posted to the comments. Once the bug owner agrees we proceed with step 8.
  4. A developer creates a patch. The patch will be attached to Bug Traker and committed into the experimental branch (resolution->fixed).
  5. The community review is initiated. A corresponding comment is added to Bug Tracker.
  6. The community review is completed and successful. A corresponding comment is added to Bug Tracker and the patch is merged into "HEAD". The bug status is changed to "pending". If the community review was unsuccessful we go back to step 4.
  7. The patch is picked up by the next release.
  8. The bug is closed.

Patches

Patches are created relative to the latest release. We usually use the "create patch" action from Eclipse.

Code Conventions

We use the following naming conventions in our code (not all sources have been migrated to these conventions yet):

entity naming sample
class, interface mixed-case, first letter uppercase class HttpClient
method mixed-case, first letter lowercase HttpClient getClient()
parameter mixed-case, prefix 'p' void setClient(HttpClient pClient)
local variable mixed-case, first letter lowercase int loopCounter
field mixed-case, prefix 'i' String iName
static field mixed-case, prefix 'c' static String cName
static final field uppercase static final String NAME = "SBLIM"

Access to members is not qualified with "this." the prefixing usually does a good job avoiding hidden members. We aim at warning free code, but haven't met that goal yet. All code is REQUIRED to compile on IBM/SUN Java 1.4.x/1.5.x and GCJ 4.1. Therefore Java 1.5 constructs are not allowed.

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 seperated by using "*.internal" packages (realized in slp client, not yet in CIM client !).

Javadoc is mandatory for public API of a class.