During our first IRC PSC meeting, the PSC decided to update the decision making process, by distinguishing between Request For Comments (what is intended) and Request For Changes (what has been done and is ready to merge). The current workflow is therefore the following:
Request for Comments -> Comments and discussions -> Developments -> Requests for changes -> Review -> Vote -> Requests for Merge -> approval by Release Manager -> Merge
A release manager is nominated for each release. Nomination is made shortly after previous release announcement. A backup release manager is also nominated, to assist and possibly step in if the official release manager is not available. The release manager and his/her backup can be a member of the PSC, but also another member of otb-developers list willing to take the spot.
The release manager is in charge of :
- Listing and tracking all major features proposed for next release (from call for contribution in the early phase and then approved RFCs)
- Planing release date and ensures sync with RFCs execution,
- Approving feature branch merges
- Actually merging feature branches when authors do not have commit rights (github pull request for instance)
- Tracking remote module that can be candidate for official inclusion in next release, and ensuring they will be included (see Contributors guidelines)
- Submiting the start of the release process to PSC vote
- Ensuring proper execution of release process
Remember: all new features must be submitted by RFCs and approved by PSC. Release manager only approves the feature branches merge.
Request for Comments
A Request for Comments can be submitted by anyone, at anytime, on otb-developers mailing list (topic should start with [Request for Comments]). Its purpose is twofold:
- Publicly announce intention to develop some new features or changes in order to increase openness of the project and coordination between developers,
- Gather feedback and comments to assess acceptation by the community and build a stronger development plan based on its feedback (caveats, best way to do it, things not to forget, etc.)
Request for Comments are only proposed ideas, they are therefore not voted by the PSC (but the PSC is encouraged to give its opinion so as to help the author). However, anyone can express her support to Request for Comments, which will help both the author and the PSC to assess acceptation and popularity of the proposed feature.
Development should start anytime, but it is advised to wait for discussion to end so as to know if the change can be accepted in the future and how it should be best done.
Requests for Comments are not mandatory, but they will help the community to get the big picture (a Request for Comments can cover several Request for Changes) and ensure that the proposed change can get accepted.
Request for Changes
A Request for Changes describes a precise set of changes that have been made to the source code:
- General purpose of the changes,
- Architecture insight (how are classes affected by the changes supposed to interact),
- Classes added or modified,
- Tests added,
- CMake scripts modifications,
A Request for Change can be submitted by anyone, at anytime, on otb-developers (topic should start with [Request for Changes]). Authors should also create a wiki entry corresponding to their Request for Changes here, following this template.
Requests for Changes can refer to a former Request for Comments to explain what role it plays in a bigger picture. A Request for changes can indeed correspond to a part of a Request for Comments. It is not mandatory that a former Request for Comments exists, but it will most certainly help.
A Request for Changes refers to existing changesets, either on a feature branch or in a pull request.
A Request for Changes needs to be approved by a PSC vote, following voting rules. The purpose of the vote is to validate that the content in the set of changes is in line with project directions. A code review might be performed during the process.
The list of all Request for Changes is available here.
Request for Merge
Once a Request for Change has been formally approved by PSC, the author can issue a Request for Merge to the current release manager, by sending a mail (topic should start with [Request for Merge]), according to the release planning process.
Note that the Release Manager does not evaluate the content of the changesets themselves (this is the purpose of the PSC vote), she only decides if a merge in develop branch is possible according to the merge acceptance checklist.
There is no need for tracking Request for merge on the wiki, everything will therefore be decided on otb-developers.
Feature branch merge acceptance checklist
- The feature branch corresponds to an approved RFC
- The feature branch is synched with develop
- The feature branch is tested on the dashboard (see here) and has no major failure (compilation errors, tremendous amount of warning or failing tests, segfault or not executed tests)
- Feature branch author are available during days following the merge to analyse dashboard and fix things in case of unexpected issues after the merge
It is important to note that a feature branch should be kept relatively small and does not necessarily correspond to the full implementation of a RFC. Small consistent branches implementing parts of RFC can be merged early. Further evolutions and implementations of the RFC can be done by continuing the feature branch or opening new branches, and approval of Release Manager should be requested again before merging.
Remote branche deletion
After a feature branch is merged it should be considered "finished" and will be deleted from the remote server. We can of course make exceptions to this if the RFC author asks.