Development

From Open64 Wiki

Branches

The development of major changes shall be done on a branch. (Under some circumstances, development may be done in a private development tree, but the Steering Group strongly encourages the use of a branch in the publicly accessible Open64 development tree.)

Example of creating Open64 branch: svn copy http://svn.open64.net/svnroot/open64/trunk \

 http://svn.open64.net/svnroot/open64/branches/mybranch

Note: To create an Open64 branch, developer must have write permission to svn.open64.net. To request access contact Open64 svn administrator (Juergen Ributzka ributzka@gmail.com). Tell the Open64 administrator if there are any specific constraints on the branch (e.g. who is allowed to modify it).

Examples of major changes include:

  1. A new version of C/C++ front end 
  2. A new memory disambiguation package for all analysis and optimization phases 
  3. A new optimization pass 

There is no firm guideline for what constitutes a "major change" and what does not. If a developer is unsure, he or she should ask for guidance on the Open64 mailing lists. In general, a change that has the potential to be extremely destabilizing should be done on a branch. Changes may be merged from a development branch only after:

  1. They meet the standards for any other check-in as stated in the
     check-in policy. For example, the code must be well-documented,
     and any user-visible changes, including command-line options,
     should be documented in the manual. 
  2. The branch has been validated on two different targets, each
     targeting a different microprocessor family. Validation should
     consist of bootstrapping the compiler (unless that is impossible
     for the microprocessor selected) and checking that there are no
     new regression test failures. It is acceptable to use a
     simulator for validation; the use of real hardware is not
     required.

Rationale

Making major improvements to the compiler is good. However, such changes are inevitably somewhat destabilizing. By using a branch, it is possible for people to test and improve the code, but without impacting other developers. By testing major changes more thoroughly than ordinary changes, we will help reduce the impact on other developers. In addition, the presence of half-finished projects on the mainline presents a variety of problems when preparing for a release. If serious bugs remain, it may be impossible to do a release until the bugs are fixed, thereby impacting the release schedule. If functionality is present, but not robust (for example, command-line options that activate an optimization pass that does not work very well), then we can seriously confuse users.