ITK/Release 4/Modularization/Code Reviews/Process: Difference between revisions

From KitwarePublic
Jump to navigationJump to search
Line 5: Line 5:
** The files will be named after the ITK files. For example
** The files will be named after the ITK files. For example
*** itkImage.h.txt  will be the code review file for itkImage.h
*** itkImage.h.txt  will be the code review file for itkImage.h
* The repository will contain at the top level, one directory per contractor, and under that directory we will replicate the monolithic directory tree structure of ITK with only the files that have been assigned to that contractor.
* This text files will be populated by the code reviewers with the following standardize content
* This text files will be populated by the code reviewers with the following standardize content
** REVIEWER: Name
**


 
   STATUS: StatusKey (see table below)
The fields will use the following convention
    
 
  Arbitrary texts, as detailed as the reviewer deem necessary. it could be paragraphs.
   KEY:   Vale
    (emtpy line)
   arbitrary texts, as detailed as the reviewer deem necessary. it could be paragraphs.


= Possible Outcomes =
= Possible Outcomes =

Revision as of 15:42, 15 February 2011

Overview

  • Kitware will create a separate Git repository containing
    • One text file for each one of the files in the current ITK Manifest.
    • The files will be named after the ITK files. For example
      • itkImage.h.txt will be the code review file for itkImage.h
  • The repository will contain at the top level, one directory per contractor, and under that directory we will replicate the monolithic directory tree structure of ITK with only the files that have been assigned to that contractor.
  • This text files will be populated by the code reviewers with the following standardize content
  STATUS: StatusKey (see table below)
  
  Arbitrary texts, as detailed as the reviewer deem necessary. it could be paragraphs.

Possible Outcomes

For each file, a contractor will review the code following the Check list (reference here) and specify one of the following outcomes

  • No change required (key: Good)
  • Minor typos (key: Minor)(reviewer will fix them directly)
  • Doxygen documentation needed (need fixing) (key: Dox)
  • File must be removed (broke, obsolete, irreparable) (key: Kill)
  • File needs refactoring (key: BUG#number)(it must have been logged as a mantis bug by the time the CSV file is updated)

Contractors

Refactoring

For classes to be refactored

the following process should be followed

  • MANTIS Bug
  • Dependencies
  • Migration guide