...

• Defined milestones.
• Formal release planning (feature has to be ready to enter the tree)
• Formal checklists

Maintenance

After a particular version of The Linux Kernel is released it's considered "stable". This means that community maintains it and backport all bug fixes that are being merged into next release also to this version until new release is available.

Usually one of releases in particular year is chosen to be a Long Term Support release (LTS) which means that community will maintain it way longer than till next release (3-6 years). This version is typically used as a base for commercial products or Linux Distributions.

DPDK

Development

The DPDK development process is modeled (loosely) on the Linux Kernel development model. The process is described in more details here.

Typical release cycle is 3 months long.

All changes are reviewed in a public mailing list with the help of patchwork tool in a similar fashion to the linux kernel.

Right after the previous release is out the merge window for a new release is open. All new features must be introduced within the merge window.

Last month of every release is considered a bug fixing period and no new functionality will enter the tree within this period.

Maintenance

Stable and LTS releases are described here.

Every major release of DPDK can be marked as a stable release if there is a volunteer who would like to maintain it. A stable release can be maintained from 3 months up to a year.

A stable release can be designated as an LTS release based on community agreement and a commitment from a maintainer. The current policy is that each year’s November (X.11) release will be maintained as an LTS for 2 years.

OpenStack

Development

Typical release cycle is 6 months long with two F2F events within every release cycle - Project Teams Gathering and The Forum (around Open Infrastructure Summit). Please keep in mind that openstack is currently reorganizing their release cycle model so information mentioned here may be out of the date or mixed.

The release takes 27 weeks which are numbered as week before the targeted release (R - 1, R - 2 etc). It starts with the identification of community-wide goals and working on specs. The spec is approved by affected project PTL and as soon as it is approved, the implementation can be started. The deadline for adding new specs is R-12. R-7 is the deadline for adding patches with features to the tree. After this point of time only bugfixes are accepted. Last 4 weeks are rc-weeks and are dedicated for testing and bug fixing. More detailed schedule can be found here.

It's also worth to notice that openstack is using lunchpad and storyboard to maintain their progress but not for a strict project management like we do in ONAP.

Maintenance

OpenStack has a well documented maintenance phase.

Basically every release is maintained actively for 18 months. Then the effort is constantly reduced including the reduced CI.