Deprecation Policy - Revision history

Ycongal smile: Improve wiki markup (proper wiki lists)

2024-07-16T16:45:06Z

Improve wiki markup (proper wiki lists)

← Older revision		Revision as of 16:45, 16 July 2024
Line 6:		Line 6:
	= Why: =		= Why: =

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

	= Challenges: =		= Challenges: =

	- Obsolete code adds to maintenance burden.		* Obsolete code adds to maintenance burden.
			* Old code consumes developers’ time which could be better focused elsewhere
	- 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
	- Can’t tell who is using things		* 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
	- Sometimes recipes are one-off contributions which are unmaintained		* Full meta-openembedded builds consume significant resources. Long builds slow down development and narrows down testing matrix
			* Obsolete recipes adds inertia towards new developments
	~~- there~~ might be a perception that obsolete/removed recipes from OE-Core can be added to meta-oe		* 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.

	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		Keeping this in sight, here is a proposal to define some guidelines for community to assess recipe deprecation
Line 35:		Line 27:
	= Deprecation guideline criteria: =		= Deprecation guideline criteria: =

	- Recipe is not buildable		* Recipe is not buildable
			* Recipe has known security issues (particularly high impact ones)
	- 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
	- package's upstream is not actively responding to build or security issues (e.g. a large patch backlog)		* 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
	- Functionality from recipe has been obsoleted by other recipes and no longer commonly used		* 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
	- Recipe has no activity upstream (no activity for e.g. 5+ years is a concern)		* 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
	- 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: =		= Process: =

	- Maintainer can remove if the decision is clear to them and has discretion over the 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
	- 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
	- Notification is in the form of a patch adding the exclusion		* Recipe removals scheduled after each release point
			* If someone addresses the underlying issues the recipe can be added back or have parsing re-enabled.
	- After a reasonable time if not fixed, recipe is removed		* If there is a conflict, issue can be raised to OE TSC for a decision

	- 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

	[[Category:Policy]]		[[Category:Policy]]

Khem: /* Challenges: */

2023-10-24T18:16:27Z

Challenges:

← Older revision		Revision as of 18:16, 24 October 2023
Line 13:		Line 13:
	= Challenges: =		= Challenges: =

	Obsolete code adds to maintenance burden.		- Obsolete code adds to maintenance burden.
	Old code consumes developers’ time which could be better focused elsewhere
	Can’t tell who is using things		- Old code consumes developers’ time which could be better focused elsewhere
	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		- 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		Users aren’t often paying attention to development branches, only release branches

Khem: /* Process: */

2023-10-24T18:15:54Z

Process:

← Older revision		Revision as of 18:15, 24 October 2023
Line 58:		Line 58:

	- Notification is in the form of a patch adding the exclusion		- Notification is in the form of a patch adding the exclusion

	- After a reasonable time if not fixed, recipe is removed		- After a reasonable time if not fixed, recipe is removed

	- Recipe removals scheduled after each release point		- 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 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		- If there is a conflict, issue can be raised to OE TSC for a decision

	[[Category:Policy]]		[[Category:Policy]]

Khem: /* Deprecation guideline criteria: */

2023-10-24T18:15:40Z

Deprecation guideline criteria:

← Older revision		Revision as of 18:15, 24 October 2023
Line 32:		Line 32:

	- Recipe is not buildable		- Recipe is not buildable

	- Recipe has known security issues (particularly high impact ones)		- 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)		- 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		- 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 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		- 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])		- 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		- 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		- 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		- Recipe has problematic host dependencies (e.g. 32-bit runtime) and no maintainer improving situation

Khem at 18:15, 24 October 2023

2023-10-24T18:15:04Z

← Older revision		Revision as of 18:15, 24 October 2023
Line 4:		Line 4:
	Here is deprecation policy and guidelines for recipes and related metadata maintained in layers under meta-openembedded repository		Here is deprecation policy and guidelines for recipes and related metadata maintained in layers under meta-openembedded repository

	Why:		= Why: =

	- Reduce the security gap		- Reduce the security gap
Line 11:		Line 11:
	- Improved developer productivity		- Improved developer productivity

	Challenges:		= Challenges: =

	Obsolete code adds to maintenance burden.		Obsolete code adds to maintenance burden.
Line 29:		Line 29:
	Keeping this in sight, here is a proposal to define some guidelines for community to assess recipe deprecation		Keeping this in sight, here is a proposal to define some guidelines for community to assess recipe deprecation

	Deprecation guideline criteria:		= Deprecation guideline criteria: =

	- Recipe is not buildable		- Recipe is not buildable
Line 42:		Line 42:
	- Recipe has problematic host dependencies (e.g. 32-bit runtime) and no maintainer improving situation		- Recipe has problematic host dependencies (e.g. 32-bit runtime) and no maintainer improving situation

	Process:		= Process: =

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

Khem at 18:13, 24 October 2023

2023-10-24T18:13:53Z

← Older revision		Revision as of 18:13, 24 October 2023
Line 1:		Line 1:
			= Recipes and metadata deprecation policy =


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

Khem at 18:12, 24 October 2023

2023-10-24T18:12:13Z

← Older revision		Revision as of 18:12, 24 October 2023
Line 50:		Line 50:
	- If someone addresses the underlying issues the recipe can be added back or have parsing re-enabled.		- 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		- If there is a conflict, issue can be raised to OE TSC for a decision

			[[Category:Policy]]

Khem at 18:10, 24 October 2023

2023-10-24T18:10:57Z

← Older revision		Revision as of 18:10, 24 October 2023
Line 1:		Line 1:
	Here is deprecation policy and guidelines for recipes and related metadata maintained in layers under meta-openembedded repository		Here is deprecation policy and guidelines for recipes and related metadata maintained in layers under meta-openembedded repository

			Why:
	== Why:

	- Reduce the security gap		- Reduce the security gap
Line 9:		Line 8:
	- Improved developer productivity		- Improved developer productivity

	~~'''~~Challenges:		Challenges:
	~~'''~~
	Obsolete code adds to maintenance burden.		Obsolete code adds to maintenance burden.
	Old code consumes developers’ time which could be better focused elsewhere		Old code consumes developers’ time which could be better focused elsewhere
Line 27:		Line 26:
	Keeping this in sight, here is a proposal to define some guidelines for community to assess recipe deprecation		Keeping this in sight, here is a proposal to define some guidelines for community to assess recipe deprecation

	~~'''~~Deprecation guideline criteria:		Deprecation guideline criteria:
	~~'''~~
	- Recipe is not buildable		- Recipe is not buildable
	- Recipe has known security issues (particularly high impact ones)		- Recipe has known security issues (particularly high impact ones)
Line 40:		Line 39:
	- Recipe has problematic host dependencies (e.g. 32-bit runtime) and no maintainer improving situation		- Recipe has problematic host dependencies (e.g. 32-bit runtime) and no maintainer improving situation

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

Khem at 18:10, 24 October 2023

2023-10-24T18:10:21Z

← Older revision		Revision as of 18:10, 24 October 2023
Line 3:		Line 3:

	== Why:		== Why:
	==

	- Reduce the security gap		- Reduce the security gap

Khem at 18:10, 24 October 2023

2023-10-24T18:10:10Z

← Older revision		Revision as of 18:10, 24 October 2023
Line 1:		Line 1:
	Here is deprecation policy and guidelines for recipes and related metadata maintained in layers under meta-openembedded repository		Here is deprecation policy and guidelines for recipes and related metadata maintained in layers under meta-openembedded repository

	~~'''~~Why:
	~~'''~~		== Why:
			==

	- Reduce the security gap		- Reduce the security gap
	- Increase quality of layer and recipes		- Increase quality of layer and recipes