...
- OPNFV developers who are working with upstream projects cannot use the OPNFV releases for development and testing, since the versions are older
- If OpenStack will move to annual releases, then the OPNFV releases can have OpenStack versions that are several releases old
- Installer projects have to support both old and recent versions of OpenStack. Recently, the Apex project stopped supporting the OPNFV releases for this reason
- The current state also has the typical issues of the waterfall model: integration happens relatively late, there is a rush to integrate installers and CI testing, and testing before the release can take an unpredictable amount of time
- As a consequence, the release dates often slip
- Making the releases take a lot of effort in the end, which can be problematic if the effort in OPNFV reduces
- Some features that did not quite make it to the main release have come in a maintenance releases, which confuses the concept of a release
- Sometimes the maintanance releases have fared worse in testing than the main release, since all effort is already going to the next release
- The baseline for releases (OS packages, OpenStack and other upstream projects) can change, so the release is not really "stable": an installer for an OPNFV release pulls in packages from Linux distro repositories, from github etc and these upstream projects can change (as has happened already)
- To make the progress towards a release transparent and predictable, the milestones must be enforced which takes some effort and requires some punishments for missing deadlines. This reduces the incentives to participate in a release
- Overall, what is the incentive to participate in a release?
...