Request for Comments-31: Dashboard refactoring

Status

• Author: Julien Michel and Victor Poughon
• Submitted on 04.05.2016
• Open for comments

Content

What changes will be made and why they would make a better Orfeo ToolBox?

Now that we have feature branch and new release process, dashboard is more and more complex, and it is often hard to find out what is going one between all the tested branches and configurations. Here are a set of improvements that would help greatly in understanding our dashboard and actually use it for release preparation.

Naming conventions

To be consistent, we propose that:

• Nighlty track is renamed to Develop track (as it tests the develop branch)
• Stable track is renamed to Latest release track (as it tests the latest release branch)
• ExtraBranches is renamed to Feature Branches (as it tests feature branches)

The Latest Release track should always be present and test the latest release branch head. When preparing a new release (after feature freeze and creation of the new release branch) we can swith tested branch to the new release branch.

Order of track appearance should be:

1. Develop track
2. Latest Release track
3. Feature Branches track
4. Remote Modules track
5. Experimental track

CrossCompile track should not be a track by itself and the only build in it should be moved to the appropriate track (either Develop or Latest Release).

Superbuild track should be removed (see bellow).

Superbuild

Superbuild should not be a track by itself. It is a special way of building either develop or latest release branch, so the related builds should appear in Develop or Latest Release track, *with the appropriate xxx-Superbuild* naming.

Builds consistency

To be able to sort out problems, it is very important that a consistent configuration (platform, compilers, flags) is used to provide all builds, which means that the same plateform, compiler, flags (release/debug/relwithdebinfo) are used to produce the regular and superbuild builds for both the develop and latest release track (and also of course the feature branches track).

For now it is not the case (for instance, some plateforms build develop in RelWithDebInfo mode and release-5.4 in Release mode).

The case of OTB-Data

Unfortunately, we have several git repositories that are supposed to work together : a given revision of OTB is tied to a revision of OTB-Data (and also a revision of Monteverdi). This is not enforced right now, which makes it very difficult to understand which revision of OTB-Data is used for testing a given builds. We also have problems of OTB-Data updates that are done for commits in develop and break builds in latest release track. Note that we partly solved this problem for feature branches, since there is a way to indicate manually the OTB-Data branch that should be used to test feature branches. Still, this information should be updated manually in yet another repository, and is not used for develop and release branch testing.

Regarding Monteverdi, we already decided to move it inside OTB source tree, so the dependency between git repository will no longer exist in a near future.

Unfortunately we can not do the same for OTB-Data, since it is quite big. But I think we should enforce the link between OTB and OTB-Data revision. Here is the proposed solution :

• The revision of OTB-Data required to run the tests is hardcoded in a cmake internal variable,
• At configuration time, if tests are activated, OTB checks for this required revision of OTB-Data, and configuration fails with a FATAL error if the revision is not correct,
• It is up to developers to update the OTB-Data required revision variable in CMakeLists.txt when it is necessary.

Actually, I would like to propose something even more radical. If the required revision of OTB-Data is known in CMake, OTB could clone and checkout the correct revision of OTB-Data in the build tree at configuration time. This would allow for parallel builds without sharing the same OTB-Data folder.

This, way any revision of OTB could be tested automatically (without manual update of OTB-Data) with the correct revision of OTB-Data.

Other requests for comments that will improve the dashboard usability

Request for Comments-18: Factorize CMake configuration will allow to better understand the configuration scripts and therefore to enforce the build consistency.

Request for Comments-19: Provide a summary after cmake configuration will allow to better understand the third parties configuration of a given build.

When will those changes be available (target release or date)?

Those changes can be applied right after release 5.4, and definitively for release 5.6 preparation.

Community

Comments

List here important comments (possibly links) received.

Support

List here community members that support this RFComments.

Corresponding Requests for Changes

List here links to corresponding Requests for Changes if any.