As a compilation infrastructure, LLVM has multiple types of users, both downstream and upstream, of many combinations of its projects, tools and libraries.
There is a core part of it that encompass the implementation of the compiler (front/middle/back ends), run-time libraries (RT, C++, OpenMP, etc) and associated tools (debugger, linker, object file manipulation, etc). These components are present in the public release on our supported architectures and operating systems and the whole community must maintain and care about.
There are, however, other components within the main repository that either cater to a specific sub-community of LLVM (upstream or downstream) or help parts of the community to integrate LLVM into their own development tools or external projects. Those parts of the main repository don’t always have rigorous testing like the core parts, nor are they validated and shipped with our public upstream releases.
Even not being a core part of the project, we have enough sub-communities needing those changes with enough overlap that having them in the main repository is beneficial to minimise the repetition of those changes in all the external repositories that need them.
But the maintenance costs of such diverse ecosystem is non trivial, so we divide the level of support in two tiers: core and peripheral, with two different levels of impact and responsibilities. Those tiers refer only to the main repository (llvm-project) and not the other repositories in our git project, unless explicitly stated.
Regardless of the tier, all code must follow the existing policies on quality, reviews, style, etc.
The core tier encompasses all of the code in the main repository that is in production, is actively tested and released in a regular schedule, including core LLVM APIs and infrastructure, front/middle/back-ends, run-time libraries, tools, etc.
It is the responsibility of every LLVM developer to care for the core tier regardless of where their work is applied to.
The peripheral tier encompass the parts of LLVM that cater to a specific sub-community and which don’t usually affect the core components directly.
This includes experimental back-ends, disabled-by-default options and alternative paths (work-in-progress replacements) in the same repository, as well as separate efforts to integrate LLVM development with local practices.
It is the responsibility of each sub-community to care about their own parts and the intersection of that with the core tier and other peripheral parts.
To add a new peripheral component, send an RFC to the appropriate dev list proposing its addition and explaining how it will meet the support requirements listed above. Different types of components could require different levels of detail. when in doubt, ask the community what’s the best approach.
Inclusion must reach consensus in the RFC by the community and the approval of the corresponding review (by multiple members of the community) is the official note of acceptance.
After merge, there often is a period of transition, where teething issues on existing buildbots are discovered and fixed. If those cannot be fixed straight away, the sub-community is responsible for tracking and reverting all the pertinent patches and retrying the inclusion review.
Once the component is stable in tree, it must follow this policy and the deprecation rules below apply.
Due to the uncertain nature of inclusion, it’s advisable that new components are not added too close to a release branch. The time will depend on the size and complexity of the component, so adding release and testing managers on the RFC and review is strongly advisable.
The LLVM code base has a number of files that aren’t being actively maintained. But not all of those files are obstructing the development of the project and so it remains in the repository with the assumption that it could still be useful for downstream users.
For code to remain in the repository, its presence must not impose an undue burden on maintaining other components (core or peripheral).
There are multiple types of issues that might trigger a request for deprecation, including (but not limited to):
- Changes in a component consistently break other areas of the project.
- Components go broken for long periods of time (weeks or more).
- Clearly superior alternatives are in use and maintenance is painful.
- Builds and tests are harder / take longer, increasing the cost of maintenance, overtaking the perceived benefits.
If the maintenance cost is higher than it is acceptable by the majority of developers, it means that either the sub-community is too small (and the extra cost should be paid locally), or not active enough (and the problems won’t be fixed any time soon). In either case, removal of such problematic component is justified.
However clear the needs for removal are, we should take an incremental approach to deprecating code, especially when there’s still a sub-community that cares about it. In that sense, code will never be removed outright without a series of steps are taken.
If a proposal for removal is delayed by the promise a sub-community will take care of the code affected, the sub-community will have a time to fix all the issues (depending on each case, as above), and if those are not fixed in time, a subsequent request for removal should be made and the community may elect to eject the component without further attempts to fix.
If a component is removed from LLVM, it may, at a later date, request inclusion of a modified version, with evidence that all of the issues were fixed and that there is a clear sub-community that will maintain it.
By consequence, the pressure on such sub-community will be higher to keep overall maintenance costs to a minimum and will need to show steps to mitigate all of the issues that were listed as reasons for its original removal.
Failing on those again, will lead to become a candidate for removal yet again.