OpenTM2 development process V2

Coordinating IBM-internal development with community development

1 General statements

1. In general the OpenTM2 git repository is used as version control system.
2. This document "OpenTM2 development process lists roles, not persons. Role to person mappings are listed at OpenTM2 team page. Roles mentioned in this document are:
   
   1. OpenTM2 Steering Committee
   2. OpenTM2 development lead
   3. OpenTM2 community support

2 IBM-internal development

1. The IBM-internal OpenTM2 development process will not be changed.
2. For OpenTM2 IBM-internal problem report fixing, there exists a defined process. 
   1. The IBM-internal OpenTM2 team members are responsible for the fixing of the problem reports.
   2. The OpenTM2 team decides, which fix will make it into which official OpenTM2 release. 
   3. The OpenTM2 code changes are committed to the source code repository, as soon as the developer's code changes are stable enough to be committed.

3 Community development

3.1 The official community repository

1. The OpenTM2 Steering Committee has the responsibility to define a person or team to act as the OpenTM2 development lead, which controls the OpenTM2 Community Repository.

3.1.1 Merging from IBM-internal repository into official community repository and vice-versa

1. Merging IBM-based "Nightly Builds" into the community environment:

   • If possible, once per night the IBM-internal official repository gets automatically merged into the official community repository.
   • Only the IBM-internal team can decide whether all or only parts of the fixes will make it into the official community repository.
   • The OpenTM2 development lead reviews this process and manually resolves any potential merge-conflicts, that may occur.
   • Merge conflicts will be sent by eMail to the OpenTM2 development lead.
2.  Merging community-based "Nightly Builds" into the IBM-repository:
   • If there are changes in the official community repository, the OpenTM2 development lead coordinates a decision to be made with the OpenTM2 Steering Committee, as well as with the IBM-internal OpenTM2 team.
   • The merge-back only takes place, if the newly developed source is error free, free of legal issues (e.g. copyright issues), stable, high performant, and following OpenTM2 coding guidelines.
   • Only the IBM-internal team can decide about a "merge back" of the newly contributed community code into the IBM-internal OpenTM2 build.

3. Keeping the repositories in sync

   • The involved teams aim to keep the two repositories (the IBM-internal OpenTM2 repository and the OpenTM2 community repository) in sync whereever possible. This is done to avoid, that the IBM-internal repository and the community repository drift apart.

3.2 Kernel and plug-ins

1. The kernel should stay as slim as possible.
2. As far as possible new features (community features and IBM features) should be developed as plug-ins.
3. If someone wants to extend the kernel with a new functionality, he should consult the OpenTM2 community development process (Nr. 3.3 of this document)

3.2.1 Official and unofficial community plug-ins

1. Official community plug-ins
   1. They are approved by the OpenTM2 Steering Committee
   2. They get merged into the official community repository.
   3. They become part of the installer.
2. Approved community plug-ins
   1. They are approved by the OpenTM2 Steering Committee.
   2. These plug-ins are listed at the OpenTM2 plug-in site as approved plug-ins and can be downloaded from there.
   3. They are not part of the installer, nor of the official community repository.
3. Unofficial community plug-ins
   
   1. Every plug-in author can list his plug-in at the OpenTM2 plug-in site
   2. These plug-ins are marked as unofficial.
   3. It is outlined very clearly, that the responsibility of the plug-in is only at the plug-in author and every user should check for himself, if the plug-in works and does not produce any unwanted results.

3.3 OpenTM2 community development process

Someone in the community wants to develop a new feature. The process is as follows:

1. The developer decides, if this feature can be developed as a plug-in or not. As far as possible, the feature should be developed as a plug-in.
2. If the developer is in doubt or if he wants to change the kernel, he checks back with the OpenTM2 community support, who coordinates this issue with the OpenTM2 development lead.
3. If the feature is developed inside the OpenTM2 kernel and if the OpenTM2 development lead did approve that: As soon as the development is stable:
   
   1. The author communicates the development to the OpenTM2 development lead and submits a pull-request towards the official community master repository.
   2. The OpenTM2 development lead recommends towards the OpenTM2 Steering Committee, if the feature should be merged into the community master.
   3. The OpenTM2 Steering Committee decides, if the new kernel feature should be merged into the community master.
   4. If the OpenTM2 Steering Committee approves the change, the new kernel feature gets merged into the master by the OpenTM2 development lead.
4. If the feature is NOT developed as a kernel change
   1. The author develops a plug-in
   2. He uploads the finished plug-in as an unofficial community plug-in to the OpenTM2 plug-in site.
   3. He can ask the OpenTM2 Steering Committee to approve his plug-in.