The goal of this page is to document how other open source project are developed to avoid reinventing the wheel. This may also give us valuable insights how we could improve our release process.

The Linux Kernel

Development

The Linux kernel is released every 2-3 months. For all considerations it's worth to notice that Linux kernel is developed in a single git repository.

All changes are reviewed in a public mailing list. When a patch is ready for submission it is merged by a subsystem (sth close to "subproject") maintainer to his -next git tree.

Every release starts with a 2-weeks merge window. During this time subsystem maintainers issue pull request to Linus (or higher level maintainer) asking him to pull changes from his git tree to main one.

When this time passes Linus releases rc1 release and we enter bugfix stage. This means that there are two streams of patches submitted:

• Bug Fixes which are intended to enter next rc release

• Main development patches which are merged to -next tree for a next main release

After 6-9 weeks of bug fixing a new version of The Linux kernel is released and the whole process starts over.

It's worth to notice that there is no:

• 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.