[libc-commits] [libc] [libc][docs] Add a sunset policy to porting docs (PR #168936)

[Michael Jones via libc-commits]

================
@@ -103,3 +91,52 @@ bring up. The Linux config has ``headers.txt`` file listed separately for the
 config and the
 `x86_64 <https://github.com/llvm/llvm-project/tree/main/libc/config/linux/x86_64>`_
 config.
+
+
+Upstreaming
+===========
+
+Adding a target to the main LLVM-libc has some requirements to ensure that the
+targets stay in usable condition. LLVM-libc is under active development and
+without active maintenance targets will become stale and may be sunset.
+
+Maintenance
+-----------
+
+To add a target there must be one or more people whose responsibility it is to
+keep the target up to date or push it forwards if it's not complete. Those
+people are the maintainers, and they are responsible for keeping their target in
+good shape. This means fixing their target when it breaks, reviewing patches
+related to their target, and keeping the target's CI running.
+
+Maintainers are listed in libc/maintainers.rst and must follow
+`LLVM's maintainer policy <https://llvm.org/docs/DeveloperPolicy.html#maintainers>`_.
+
+CI builders
+-----------
+
+Every target needs at least one CI builder. These are used to check when the
+target breaks, and to help people who don't have access to the specific
+architecture fix their bugs. LLVM-libc has both presubmit CI on github
+and postsubmit CI on the `LLVM buildbot <https://lab.llvm.org/buildbot>`_. For
+instructions on contributing a postsubmit buildbot read
+`the LLVM documentation <https://llvm.org/docs/HowToAddABuilder.html>`_ and for
+presubmit tests read
+`the github documentation <https://github.com/llvm/llvm-project/blob/main/.github/workflows/libc-fullbuild-tests.yml>`
+TODO: proper link.
+
+The test configurations are at these links:
+ * `Linux Postsubmit <https://github.com/llvm/llvm-zorg/blob/main/zorg/buildbot/builders/annotated/libc-linux.py>`_
+ * `Windows Postsubmit <https://github.com/llvm/llvm-zorg/blob/main/zorg/buildbot/builders/annotated/libc-windows.py>`_
+ * `Fullbuild Presubmit <https://github.com/llvm/llvm-project/blob/main/.github/workflows/libc-fullbuild-tests.yml>`_
+ * `Overlay Presubmit <https://github.com/llvm/llvm-project/blob/main/.github/workflows/libc-overlay-tests.yml>`_
+
+Sunsetting
+----------
+
+If a target is incomplete and no progress has been made for 1 month, or if a
----------------
michaelrj-google wrote:

I agree with the idea of synchronizing this review to the LLVM release cycle to give us a useful reference point. I'd rather not have the waiting period be too long though, I don't want to still be shipping a target that's been unmaintained for a year.

My main concern is around targets that are broken or otherwise unusable. Some targets don't get much specific contribution because they don't need it (e.g. RISC-V linux). Given that we also have a CI requirement, maybe that can be a useful metric. 

We can have a slow path to deprecation where if there are 0 contributions for a target between two releases we mark it as deprecated and then if there are still 0 contributions before the next release we sunset it. Then we can have a faster path where if the CI has been broken for a month we move it to unstable or otherwise non-blocking, then if nobody picks it up and fixes it in the following 3(?) months we sunset it.

That way we aren't randomly deleting stable targets for being too stable, but we also have a path to get rid of targets that aren't properly supported in a reasonable amount of time. If people agree I'll update the PR to include that.

As for if a libc backend is ever "finished" I agree with Roland that development may slow but never stop. If we let the system interface for one target freeze then that may block changes to the others for fear of breaking compatibility.

https://github.com/llvm/llvm-project/pull/168936