Document: | OpenTM2 development process |
Version: | 2.0 |
Date: | 2015-12-21 |
Author: | Marc Mittag, MittagQI; Gerhard Fetz, IBM, Arle Lommel |
Coordinating IBM-internal development with community development
1 General statements
- In general the OpenTM2 git repository is used as version control system.
- 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:
- OpenTM2 Steering Committee
- OpenTM2 development lead
- OpenTM2 community support
2 IBM-internal development
- The IBM-internal OpenTM2 development process will not be changed.
- For OpenTM2 IBM-internal problem report fixing, there exists a defined process.
- The IBM-internal OpenTM2 team members are responsible for the fixing of the problem reports.
- The OpenTM2 team decides, which fix will make it into which official OpenTM2 release.
- 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
- 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
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.
- 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.
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
- The kernel should stay as slim as possible.
- As far as possible new features (community features and IBM features) should be developed as plug-ins.
- 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
- Official community plug-ins
- They are approved by the OpenTM2 Steering Committee
- They get merged into the official community repository.
- They become part of the installer.
- Approved community plug-ins
- They are approved by the OpenTM2 Steering Committee.
- These plug-ins are listed at the OpenTM2 plug-in site as approved plug-ins and can be downloaded from there.
- They are not part of the installer, nor of the official community repository.
- Unofficial community plug-ins
- Every plug-in author can list his plug-in at the OpenTM2 plug-in site
- These plug-ins are marked as unofficial.
- 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:
- 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.
- 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.
- 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:
- The author communicates the development to the OpenTM2 development lead and submits a pull-request towards the official community master repository.
- The OpenTM2 development lead recommends towards the OpenTM2 Steering Committee, if the feature should be merged into the community master.
- The OpenTM2 Steering Committee decides, if the new kernel feature should be merged into the community master.
- If the OpenTM2 Steering Committee approves the change, the new kernel feature gets merged into the master by the OpenTM2 development lead.
- If the feature is NOT developed as a kernel change
- The author develops a plug-in
- He uploads the finished plug-in as an unofficial community plug-in to the OpenTM2 plug-in site.
- He can ask the OpenTM2 Steering Committee to approve his plug-in.