Marcus Shawcroft <marcus.shawcroft@...>
Recently I stumbled into a couple of examples of components within the
zephyr tree that for whatever reason are currently unused, not
compilable and not testable in current form. The code is retained in
tree because it is expected to be useful at some point in the future.
The const config-info and const driver-api patches I posted a few
weeks back are now complete bar those patches which impact drivers
that currently cannot be compiled. I've refrained from pushing those
patches to gerrit in order to avoid presenting changes that cannot be
tested (or even compiled).
This means that those components for which I have not pushed the
relevant patches are effectively 'bit rotting'.
There are a couple of different approaches to this situation:
1) Wire up some form of trivial test quickly.
2) Pull the component out of tree. Re-instate the driver (from git)
and fix it up when someone has use for it (or it can be tested, or
perhaps at least compiled).
3) Leave the component in the tree, don't take any change. Fix it up
when it has use in the future.
4) Leave the component in the tree, take structural changes that
cannot be compiled or tested, deal with the breakage in the future
when the component has use/tests or compiles.
Option 1 is clearly a good approach and indeed in the context of the
patch sets referred to above, this has happened. However it is not
always possible or practical...
Which leaves us with 2/3/4 for dealing with the awkward squad.
Does zephyr have a policy on dealing with this situation?