Request for Comments-30: Shorter release process

From OTBWiki
Jump to: navigation, search

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?

With almost a month to achieve release 5.4, we are still far from an efficient release process. Here are some adjustment that we think will help in reducing the time between feature freeze and final release.

Packages generation

We have source and standalone binary package generation on a nighlty basis, but we still have a nasty manual switch from develop to release-x.x branch (we generate one or the other, but not both). We suggest that we generate those packages on a nighly basis, both for develop head and release-x.x head. release-x.x is the latest release, and can be changed to next release once feature freeze is done and next release branch created.

Moreover, all packages should be identified with the commit id they refer to. If someone has a problem with a nighly binary package, there is no way (other than to guess from the download date) to know which revision it relates to. New naming convention should be: 

OTB-develop-commit_id-Linux64.run
OTB-release-5.4-commit_id-Linux64.run

Automatic package generation should include:

  • Sources packages
  • All standalone binary packages
  • Superbuild archive (there is a target for that, but no cronjob is doing it on a nightly basis)
  • Software Guide, CookBook and FAQ
  • OTB-Data-Examples.tgz

This way, we only need to promote those packages to official release package once ready. This should be scripted also.

Merge Feature Freeze and Release Candidate

For now, the Release Candidate process is adding one week delay with almost zero benefits. We actually already do a kind of Release Candidate and bug-fixing party with Feature Freeze (most of the 47 bugfixes in 5.4 occured between Feature Freeze and RC). Let say Feature Freeze is the first RC. From the Feature Freeze, we will have a new RC each day (with nightly builds), and when we are happy the state of the day we can do the final release.

What exactly is "Test the nightly generated packages"?

The day of the final release is not the right time to:

  • Check that there are no regressions
  • Find new bugs

Regarding regressions, I hope that our 2300 nightly tests give us a pretty good insight for OTB. Regarding Monteverdi, there should be some manual testing, but it should occur (and has occured) right after feature freeze.

So what exactly is "Test the nightly generated packages" ? I suggest we keep this to a bare minimum (if not removing this step completely) :

  • Archives are not corrupted and install fine,
  • 2 or 3 identified short manual tests (one otbcli_Convert of a tiff file), one opening of another tiff file in monteverdi. This will validate packaging issues like missing dlls or so.

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

Those changes can be applied for release 5.6.

Who will be developing the proposed changes?

As this is more a process than a new feature, anyone involved in the release process should help.

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.

Retrieved from "https://wiki.orfeo-toolbox.org/index.php?title=Request_for_Comments-30:_Shorter_release_process&oldid=7943"