RFC: Handling of unmaintained modules when having issues in release builds other than deprecate and removal

[romkell]

Introduction

Removing earlier integrated modules when they are unmaintained and cause issue on release builds is understandable from release managers point of view, but also would throw away a lot of work done. Finding an "soft" solution as marking such modules as "untested since Zephyr x.y.z", "has known issues since " or similar (a degraded state, deprecated I still consider full functional but bound to be removed) would open the opportunity for someone to fix it when needed instead of starting over from "zero".

This process will not work for core modules rather than for add-ons such as e.g. civetweb, lvgl etc.

Problem description

Features and modules are added to Zephyr OS and possibly publicly advertised. At some point the initial maintainer does no longer have the time to maintain. The release manager have to deal with issues arising from such modules on their own. By finally removing such modules, a lot of work will be lost and Zephyr OS feature richness will be reduced.

Finding a maintainer who can spend the time to fix things for each Zephyr OS release and be available for feature requests etc. seems not easy. Fixing such issues for particular Zephyr OS releases might be more likely than for every release, since Zephyr OS end user will not follow every Zephyr OS release but stick to a particular version as long as there is no benefit of upgrading. If an organization has the need for such a module, it will spend the time to fix it for a particular Zephyr OS release.

Proposed change

Introduce a process how such "problematic" modules can be keep in the framework, but clearly visible to the users that such marked "problematic" modules will not work out of the box.

Detailed RFC

No detailed RFC, rather a trigger to a TSC discussion

Proposed change (Detailed)

No Proposed change (Detailed), rather a trigger to a TSC discussion

Dependencies

None.

Concerns and Unresolved Questions

• Loss of reputation Zephyr OS as being a stable, feature rich OS (more than a scheduler)
• What are the criteria s to finally remove a module (in order not to end up with everything requiring to be fixed)
  • Voting in TSC?

Alternatives

--

Background

Our company will require a web server sooner or later. But we will not get the time to maintain it for every Zephyr OS release.

[keith-zephyr]

I added some comments to https://github.com/zephyrproject-rtos/zephyr/pull/61505, provides the framework for documenting module support.

[keith-zephyr]

Finding an "soft" solution as marking such modules as "untested since Zephyr x.y.z", "has known issues since " or similar (a degraded state, deprecated I still consider full functional but bound to be removed) would open the opportunity for someone to fix it when needed instead of starting over from "zero".

For the new category of optional modules, I think we should require that each module provides release notes that explicitly documents the Zephyr releases known to be tested and work with the module.

[marc-hb]

Removing earlier integrated modules when they are unmaintained and cause issue on release builds is understandable from release managers point of view, but also would throw away a lot of work done.

"understandable" seems to refer to a past discussion? If yes then which one?

since Zephyr OS end user will not follow every Zephyr OS release but stick to a particular version as long as there is no benefit of upgrading.

A distinction is required between removing a module from Zephyr release branches versus the Zephyr main branch. Also a distinction between removing them from the manifest versus making them completely unavailable from https://github.com/zephyrproject-rtos (for instance because of unfixed and intolerable vulnerabilities). And there are also "optional modules" also coming in #61505. The devil is in the details.

[keith-zephyr]

Process WG discussion:

@nashif - Integrated modules need to have justification why a module is a better option than implementing directly in tree. These integrated modules need to have a clear maintenance plan and support. If the module bit-rots, then there needs to be a clear plan to identify a replacement.

[keith-zephyr]

@romkell - Is this still an open issue for you? The optional/external modules mentioned by #61505 wouldn't be subject to this deprecation, as the optional modules aren't part of the CI, and it's up to the user verify the status of the module. Integrated modules should be considered fully supported.

[romkell]

@romkell - Is this still an open issue for you? The optional/external modules mentioned by #61505 wouldn't be subject to this deprecation, as the optional modules aren't part of the CI, and it's up to the user verify the status of the module. Integrated modules should be considered fully supported.

I feel #61505 addresses the topic. I will close the issue.

[romkell]

Issue closed since addressed by #61505.