Everything in one place

The OTB has moved on Gitlab a few weeks ago. It has never been so easy to contribute.

https://gitlab.orfeo-toolbox.org/

Anybody can now easily interact with the developers community. Wanna report a bug, submit a patch or a new feature, participate to enthusiastic talks, and more? It can be done simply and nicely in one place. A few things have also moved on since we needed to adapt our process to Gitlab. In this post, we’ll see quickly the main changes and the big advantages offered to the OTB users and developers.

Access

Quite simple. Create your own account, or just sign in using your favorite account :

• Github
• Gitlab
• Bitbucket

Merge Requests

We have adapted our current process to move from Request For Changes to Merge Requests. Now, the proposed changes are not announced anymore on the list, neither in the wiki, but in the Gitlab instance. 

As we expect to see a bump in contributors and possibly in core developers, we changed a bit the voting policy : core developers can vote +1 for a Merge Request using the “thumb up” button (The Release Manager is in charge of merging, if the Merge Request has enough votes).

Merge requests can also be used to improve the documentation : The two main OTB documentations are the Software Guide and the CookBook. Their sources are hosted in the main OTB repository in the Documentation/ directory. To contribute documentation, just do a Merge Request. See also the Compiling documentation wiki page for help on building the Sphinx and Latex source.

Finally, anybody can contribute to the code at any level, just clone the repository, create a feature branch, commit your changes, push the feature branch to a fork (or the main repository if you are a core developer), then send a merge request. Note that we also accept PRs on our GitHub mirror !

The Gitlab’s Merge Request section enables to review the proposed changes, using nice tools that Gitlab proposes, like the Commit and Changes panels.

Issues

This section of the Gitlab instance is used for many purposes. To open an issue, just go to the Issues section and select a template.

The Request for Comments have moved to the Issues section : like Request For Changes, it will no longer be on the wiki. A Request For Comments can be done by creating a new issue, using the ‘request_for_comments’ template.

Same with bugs. Originally on a Mantis instance, the bugs have also moved in this section. If you find a bug, you can first check that it hasn’t already been reported in the existing ones. If it’s a new bug, please open a new issue on GitLab : the ‘Bug’ template will help you provide all important information and help fixing the bug quicker. Remember to add as much information as possible!

Finally, Feature requests are welcome in this section ! Generally you are welcome to simply open an issue with the ‘feature_request’ template and discuss your idea there.

A few guidelines

Here is a few useful guidelines. You can find more information in this document.

Commit messages

Remember to write a concise commit message. If fixing an issue or bug, put the issue number in the commit message so that GitLab can crosslink it. You can prefix your commit message with an indicating flag (DOC, BUG, PKG, TEST, SuperBuild, etc.).

Standard prefixes for OTB commit messages:

BUG: Fix for runtime crash or incorrect result
COMP: Compiler error or warning fix
DOC: Documentation change
ENH: New functionality
PERF: Performance improvement
STYLE: No logic impact (indentation, comments)
WIP: Work In Progress not ready for merge

Here is a few example of good commit messages :

BUG: #1701 Warn users if parameter string is unset
DOC: Fix typo in Monteverdi French translation
COMP: Allow GeoTIFF and TIFF to be disabled when no 3rd party drags them

Gitlab guidelines

In order to organize the issues in our Gitlab instance, we use both labels and milestones. The milestones should be used to track in which release a feature is merged. Gitlab can then provide a summary of all features and bugs added to a given release version. Regarding labels, we use the following set:

• story : significant feature to be implemented with a detailed work plan, it can correspond to a Request for Comments that has turned into a development action
• bug : bug, crash or unexpected behavior, reported by a user or a developer
• feature : Feature request expressed by an OTB user/developer
• to to : action is planned
• doing : work in progress
• api : optional context information

 

We hope that this new place will ease your contribution to the Orfeo ToolBox. It is also a nice place to put your remote modules if you have some !