Stable branch maintenance

Policies

The primary focus for stable branches is bugfixing, security updates, and making sure that builds on recently released Ubuntu, Fedora, and OpenSUSE distros work. All other kinds of patches (e.g, performance improvements) have a high bar to reach for them to be accepted - i.e, it will have to be very clear they pose little risk to introducing more bugs or stability issues. Anything that breaks APIs or compatibility is not appropriate.

General policies:

• Fixes must go into master first unless they are applicable only to the stable branch; if back-porting to an older stable branch, the fix should first be applied to the newer stable branches before being back-ported to the older branch.
  • In order to help make it clear when this policy has been followed cover letters for stable pull requests must include information for each patch detailing whether it's a backport, which other branches require the fix and (equally as importantly) when appropriate why the patch isn't required in other maintained branches.
• All CVE (security) patches should be backported if at all possible
• No recipe upgrades unless:
  • The old version is completely broken
  • The new version contains a security patch or other critical bugfix that is too difficult to backport to the version already in the stable branch

As always, the stable branch maintainers' judgement is important when it comes to deciding which fixes are or are not appropriate. If there is doubt, feel free to consult with the overall project maintainer (Richard Purdie <richard.purdie@linuxfoundation.org>).