Deprecation Policy

Here is deprecation policy and guidelines for recipes and related metadata maintained in layers under meta-openembedded repository

Why:

- Reduce the security gap - Increase quality of layer and recipes - Reduce technical debt - Improved developer productivity

Challenges:

Obsolete code adds to maintenance burden. Old code consumes developers’ time which could be better focused elsewhere Can’t tell who is using things Sometimes recipes are one-off contributions which are unmaintained there might be a perception that obsolete/removed recipes from OE-Core can be added to meta-oe

Users aren’t often paying attention to development branches, only release branches

Full meta-openembedded builds consume significant resources. Long builds slow down development and narrows down testing matrix

Obsolete recipes adds inertia towards new developments

Older/obsolete recipes tend to become of poorer quality more so over time as they are either not brought to use latest stuff or are simply missing it.

Keeping this in sight, here is a proposal to define some guidelines for community to assess recipe deprecation

Deprecation guideline criteria:

- Recipe is not buildable - Recipe has known security issues (particularly high impact ones) - package's upstream is not actively responding to build or security issues (e.g. a large patch backlog) - Functionality from recipe has been obsoleted by other recipes and no longer commonly used - Recipe has no activity upstream (no activity for e.g. 5+ years is a concern) - Recipe with many architecture exclusions and isn’t portable but not hardware specific recipe - It is not a key dependency for large set of recipes/layers (check layer index using depends:[recipename]) - Niche specific recipe may better moved to a more focused topic layer - Poor quality recipe or recipe build environment with no maintainer willing to improve - Recipe has problematic host dependencies (e.g. 32-bit runtime) and no maintainer improving situation

Process:

- Maintainer can remove if the decision is clear to them and has discretion over the process

- For unclear situations, exclude from parsing initially with reason documented

- Notification is in the form of a patch adding the exclusion - After a reasonable time if not fixed, recipe is removed - Recipe removals scheduled after each release point - If someone addresses the underlying issues the recipe can be added back or have parsing re-enabled. - If there is a conflict, issue can be raised to OE TSC for a decision