CheckinPolicy

From Open64 Wiki

All developers who have a subversion login for svn.open64.net can check-in new files or modify existing files in the open64.net subversion repository. A list of all developers is available in the "MAINTAINERS" file in the top level open64 directory. This file also contains the list of gatekeepers for the various phases in the compiler.

The following sections outline various aspects of development, testing and checkin of changes by developers:

1. Design / Timing

  For significant new changes like adding a new optimziation phase, 
  algorithmic change to an existing component or a major extension,
  the developer should post a design note to the open64-devel mailing
  list describing the proposed change. This serves several purposes:
    a) Informs others that you are working in this area - avoids 
       duplicate work, allows other interested developers to offer
       to work jointly with you
    b) Provides an opportunity for others to provide feedback
    c) Helps the release planning process for Open64 compiler

  Significant new check-ins can be made at any time, except close to 
  a release, stage 2.  The release manager(s) may restrict check-ins 
  to critical bug fixes only for a short duration before a release.

2. Coding Guidelines

  There are no formal coding rules for Open64. Please follow the 
  coding style of the existing code. 

  Comments in the code describing your change are highly recommended.
  Please avoid using "fixed bug #1234" type comments.

  Please try to avoid adding target-specific #Ifdefs in the code. For example, 
  target specific defaults can be set in Preconfigure_Target in 
  common/com/<target>/config_targ.cxx rather than using #ifdefs in 
  common/com/config.cxx

3. Testing Requirements

  The amount and type of testing done before a checkin depends on the 
  where the change is made and how widespread it is. For changes that 
  apply only to a single target, testing can be limited to that target
  alone. For changes to any common source file, testing needs to be done
  on your target platform of interest as well as x86/Linux since that is
  the primary testing platform for Open64. Testing on other platforms is 
  left to the owners/maintainers for those platforms.

  For simple changes, the testing requirements are:

   a) No compile time failure for x86 build
   b) Run the gcc regression test suite on x86/Linux with no new failures.
      There are many tests that fail currently due to missing
      GCC compatibility features, but we don't want any regressions.
      As Open64 compiler adds more GCC compatibility features, the 
      number of expected failures for gcc regression suite should reduce.
   c) For changes that may impact performance, run the SPEC2006 test suite
      at -Ofast to ensure there is no performance regression.

  For a major change (e.g. AMD's merge corresponding to their 4.2.2 releaes), 
  the changes should be made on a branch and access provided to other 
  developers at least 2 weeks prior to checkin.
  
  The additional testing requirements are:

   a) Successful bootstrap of Open64 compiler on x86/Linux. If your 
      platform of interest is different than x86/Linux, ensure a 
      successful bootstrap on that platform as well.
   b) Pass SPEC2006 int and fp test suites at -O1, -O2 and -Ofast. Very few 
      performance regressions should be present compared to the Open64 compiler 
      before your change.
   c) No regression in language test suites for C, C++ and Fortran 
      (Plumhall, Perennial, Modena, Fortran: ABI, GSA, CRI, Unicomp). 
   d) Ask for volunteers to do testing on other platforms using your 
      branch. Respond to problems discovered in this process.   

  Recommended additional testing for major changes (and before each release):

   a) Pass SPEC2000 int and fp test suites at -O1, -O2 and -Ofast.
   b) Pass SPEC OMPM2001 and SPEC MPI2007 at -O1, -O2 and -Ofast. 
      Use training input for MPI2007 due to excessive runtime for ref input. 

  Since the SPEC and Language test suites are not available for free, 
  if you don't have access to these, ask for volunteers who have 
  access to these test suites. 

4. Review and Approval Process

  All check-ins must be reviewed and approved by at least one
  Gatekeeper. The patch for the upcoming change needs to be mailed out
  to the open64-devel mailing list at least 2 days before the check-in
  to allow everyone a chance to provide feedback. On the request for approval, 
  developers need to make it easier for gate-keepers to identify the requests 
  that are intended for them, by including in their email subject line the
  ‘component name’ when requesting code/patch review. 

  The checkin message should contain the following:
   a) A brief description of the change.
   b) If the change fixes a bug from the bugs.open64.net Bugzilla database, 
      please add "Fix for bug#xxxx" in the checkin message.
   c) The name of the Gatekeeper who approved the checkin.
   d) If change has been copied from some other place, indicate the 
      origin of the source code and provide confirmation that the 
      license is compatible with Open64.

5. Copyright Notice and Licensing

  Any new source file checked into the Open64 source tree should have 
  a GPL v2+ (GPL  version 2 or later) compatible license. The following 
  link provides a template for the header of new source files in Open64:

    LicenseTemplate

  For changes to existing source files, do not change the License notice.
  You may add a Copyright Notice to the header of the file for your 
  contribution using the following template:

     Copyright (C) <year>  <Author>  All Rights Reserved.

  If a source change has been copied from some other place, the contributor
  is responsible for providing information about the origin of the source 
  code as well as confirming that the license of the code being copied is
  compatible with Open64.

6. Gatekeeper Policy

  Gatekeepers are designated approvers for various components of
  Open64.  They are responsible for design / code review, determine
  what check-in is allowed, and determine testing criteria for specific
  check-in. If a patch review is large, Gate Keeper team could sponsor 
  the distribution of request.

  In order to avoid redesign, maintainers are advised to gain support
  from at least a Gatekeeper by sharing the design including design
  objectives, rationale, important data structure, interfaces and test
  plan, during the design phase.

  Gatekeepers are nominated by the community or individuals volunteer
  themselves via open64-devel mailing list with the areas of coverage,
  an articulation of the candidate’s qualification including
  contributions to Open64 compiler architecture design and/or
  significant contribution to the code base.   OSG reviews the
  qualification and make the selection decision with majority vote. 
  The list of Gatekeepers and their coverage are posted in open64.net
  website, and the current list of gatekeepers can be looked up in the
  "MAINTAINERS" file in the top level source directory.

  Based on the knowledge across various part of the Open64
  functionalities Gatekeepers are classified as global or local
  Gatekeeper.  The global Gatekeeper oversees every component in the
  compiler while local Gatekeeper only oversee one or a few components,
  including Language front ends, WHIRL Generator, Code Generator(CG),
  Global Optimizer(WOPT), Loop Nest Optmizer(LNO), Inter-Procedural
  Analysis(IPA), Common Infrastructure, Tools, and so on. Besides the
  Global or Local Gatekeepers, there are gatekeepers for specific
  domain such as OpenMP, Feedback based optimization, and so on.  They
  are experts in domain and have knowledge across multiple components.

  All gatekeepers are appointed by OSG for a term of one year, and the
  term can be renewed each year without a limit.  The appointment and
  renewal are based on the ability and willingness of the individual to
  serve the gatekeeper role and the feedback from the community on
  individual gatekeeper’s performance. The decision is at a sole
  discretion of OSG. As in the OSG process, each approval requires
  majority votes from the voting population.  Considering the number of
  gatekeepers and a smooth operation of review processes, the
  appointments and renewals of gatekeepers will probably be handled in
  a staggering manner. The initial plan is to process these at one of
  the OSG meetings every quarter.

  There may be 1 – 3 local Gatekeepers designated for each component
  and 3 – 5 global Gatekeepers.  When there exists difference in
  opinion on specific check-in, release manager will orchestrate the
  resolution. 

  Gatekeepers need to feel the ownership of the compiler architecture
  and solicit additional Gatekeepers for reviewing big check-in.