How to use the review form

- copy the template doc/devel/review.txt to review/<Changelog-ID>.txt
- cvs add review/<Changelog-ID>.txt
- complete the form and check it in with the changed sources.

1 Please copy/paste the complete Changelog entry for the corresponding checkin.


2 Conformance to a specification:
  - For Bugfixes or RFE's from Bugster:
    Check if the "Suggested Fix" section contains usefull information.
    Check if the bug has been fixed according to the "Suggested Fix" section in the CR.
  
  - For other workpackages, a specification document should exist.
    Check, if the code change has been implemented according to the documentation.

3 Check if the documentation has been changed or change requests have been made

3.1 Does the issue make necessary any changes in the user or admin guide? 
    If yes, have the changes been documented and communicated to the doc writer?
    This is done by creating a Bugster CR in the doc subcategory.

3.2 Are any man page updates necessary? 
    If yes, have they been done?
    Are they understandable from a user perspective?

3.3 If commandline switches are implemented or affected by the code change, 
    check the -help output (has to exist and be understandable from a users view)

3.4 All interfaces have to be documented.
    The following interfaces have to be documented - any documentation beyond 
    the obligated is welcome:
    - GDI Interface
    - Event client interface
    - any library functions
    If interfaces changed, analyze all affected situations/code pieces.
    Documentation shall be done using ADOC headers.

3.5 If messages changed, check if they are correct and meaningful.
    Output formats shall only be changed if unavoidable - such changes have to 
    be documented.
    Attention: Output (e.g. from qstat) may be part of the documentation. Please
    communicate changes to the doc writer (see also 3.1).

3.6 Bugster Change Request
    - A CR in Bugster has to be created
       - for all bugs
       - for feature development, improvements, ...
       - for all changes to files that shall go into a patch

    - Is the Synopsis correct, meaningfull and understandable?
    - Has the version information been set (Release, CommitToFix, 
      FixedInRelease)?
    - Is the status set to "8-Fix Available"?
    - Is the hook3 field set to the Changelog id?
    - Is the hook4 field set to the automatic test path (testsuite or module test)?
    - If there is an Issuezilla Entry: Has the Hook5 field been set to the 
      Issue Number?
    - Is the CR-Number referenced in Changelog?
    - If documentation is affected, or messages have changed: Is this documented
      in Bugster ("More Info" Tab, "Fix affects ...").
    - If the code change includes a fix for memory leaks: Are the keywords "memory" and "leak" set?


3.7 Issuezilla
    - An Issuezilla Entry has to be created
       - for bugs (if they are copied from Bugster, please remove customer related info)
    - We have no Issuezilla Entries for
       - ARCo
       - GEMM
       - Windows Port
       - Doc Issues

    - Is the Synopsis correct, meaningfull and understandable?
    - Has the version information been set (Version, Target Milestone, 
      comment "Fixed in xyz")?
    - Is the Issue Number referenced in Changelog?
    

4 Check source code (diff)

4.1 Does the source code conform to our coding styleguide?

4.2 If memory is allocated, check for deallocation, access to freed memory, 
    boundaries, static buffer sizes ...

4.3 Is the code thread safe? Are all system calls / sge functions the code calls
    thread safe? Does the autodoc header of the function contain info about 
    thread safety?

5 Check if adequate testing has taken place

5.1 Run the changed component in a memory debugger, e.g.
    dbx (check -all), purify, insure.
    Optional test for complex scenarios.
    Especially for library functions having no dependencies on a running system,
    please write a module tests and run this module tests in the memory debugger.

5.2 Which manual tests have been done? 
    Include a short description.

5.3 Does the testsuite sufficiently cover the issue?
    If not, please add a test scenario yourself.
    This can be a completely new testsuite check or just an addition to an existing 
    check.

5.4 Has a new testsuite test or module test been created?
    If testsuite doesn't cover the issue, creation of a new testsuite or module test
    is required.
    If no test is created, a precise and comprehensive justification has to be 
    added to the review document and a testsuite issue has to be created.

5.5 If the testsuite does not cover the issue, and no new test has been created,
    a testsuite issue has to be filed.
    This issue should contain information about test cases (usually will 
    reflect the manual tests), 
    if scripts have been written for the manual testing, they should be 
    attached to the issue.

5.6 A testsuite run should always be done before checking in code. 
    Even if there is no special test case for the issue, testsuite might show 
    problems or sideeffects.



