Re: Handling unused but bit rotting code...
Marcus,toggle quoted messageShow quoted text
Do you have a list of the code you mention below?
From: Marcus Shawcroft [mailto:marcus.shawcroft(a)gmail.com]
Sent: Wednesday, November 2, 2016 4:43 AM
Subject: [devel] Handling unused but bit rotting code...
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?