added section on CI system

[kuhnel]

Summary

Add documentation for working with the CI systems.

This is based on the discussion in the Infrastructure Working Group:
https://github.com/ChristianKuehnel/iwg-workspace/issues/37

[kuhnel]

added missing information on worker tab

[kuhnel]

ping @reames

[kuhnel]

added screenshot

[kuhnel]

@reames I added a screenshot as you wanted. Please let me know if that addresses your usecase.

[reames]

LGTM

[kuhnel]

@gkistanova are you OK with this documentation change?

[gkistanova]

Thanks for updating the LLVM Developer Policy, Christian.
It looks good with a couple nit picks.

llvm/docs/DeveloperPolicy.rst

702

There is a set of builders with the name suffix "-release", for example https://lab.llvm.org/buildbot/#/builders/clang-with-thin-lto-ubuntu-release. These builders track the commits on the release branches to do the release testing.

740

LNT is a performance tracking system, not quite a CI.

[fhahn]

llvm/docs/DeveloperPolicy.rst

739

I'm not sure about the official status of green dragon, but I think in practice breaking one of those is considered similar to breaking bots at https://lab.llvm.org/buildbot/ (most bots for various Apple platforms are on green dragon rather than https://lab.llvm.org/buildbot)

[kuhnel]

addressed Galinas comments

llvm/docs/DeveloperPolicy.rst

739

I'm also not aware of any official policy around green dragons. So as I did not find any policy, I would assume they are optional as well...

[tschuett]

There is now an official revert policy:
https://reviews.llvm.org/D99305

[kuhnel]

@tschuett, thx I missed that update, just added a link to that...

[kuhnel]

added link to revert policy

[azharudd]

llvm/docs/DeveloperPolicy.rst

651–652

657

691–697

I think it is best to just remove this part.

• Issues reported by any CI system are to be fixed
• LNT is not CI, whereas this section is talking about CI system
• pre-merge testing is optional, covers only Phab reviews and already posts updates on the review

[kuhnel]

llvm/docs/DeveloperPolicy.rst

691–697

you're right, this does not really add value here.

[kuhnel]

addressed azharudd's comments

llvm/docs/DeveloperPolicy.rst

* Update the :doc:`coding standards<CodingStandards>` to allow the new
     features we've explicitly approved in the RFC.
 
   * Start using the new features in LLVM's codebase.
 
 Here's a `sample RFC
 <http://lists.llvm.org/pipermail/llvm-dev/2019-January/129452.html>`_ and the
 `corresponding change <https://reviews.llvm.org/D57264>`_.
 
+.. _ci-usage:
+
+Working with the CI system
+--------------------------
+
+The main continuous integration (CI) tool for the LLVM project is the 
+`LLVM Buildbot <https://lab.llvm.org/buildbot/>`_. It uses different *builders* 
+to cover a wide variety of sub-projects and configurations. The builds are 
+executed on different *workers*. Builders and workers are configured and 
+provided by community members.
+
+The Buildbot tracks the commits on the main branch and the release branches. 
+This means that patches are built and tested after they are merged to the these
+branches (aka. post-merge testing). This also means it's okay to break the build
+occasionally, as it's unreasonable to expect contributors to build and test
+their patch with every possible configuration. 
+
+*If your commit broke the build:*
+
+* Fix the build as soon as possible as this might block other contributors or
+  downstream users.
+* If you need more time analyze and fix the bug, please revert your change to
+  unblock others.
+
+*If someone else broke the build and this blocks your work*
+
+* Comment on the code review in `Phabricator <https://reviews.llvm.org/>`_ 
+  (if available) or email the author, explain the problem and how this impacts
+  you. Add a link to the broken build and the error message so folks can
+  understand the problem.
+* Revert the commit if this blocks your work, see revert_policy_ .
+
+*If a build/worker is permanently broken*
+
+* 1st step: contact the owner of the worker. You can find the name and contact
+  information for the *Admin* of worker on the page of the build in the 
+  *Worker* tab:
+
+  .. image:: buildbot_worker_contact.png
+
+* 2nd step: If the owner does not respond or fix the worker, please escalate 
+  to Galina Kostanova, the maintainer of the BuildBot master.
+* 3rd step: If Galina could not help you, please escalate to the 
+  Infrastructure Working Group `mailto:[e-mail]`.
+
 .. _new-llvm-components:
 
 Introducing New Components into LLVM
 ====================================
 
 The LLVM community is a vibrant and exciting place to be, and we look to be
 inclusive of new projects and foster new communities, and increase
 collaboration across industry and academia.
 
 That said, we need to strike a balance between being inclusive of new ideas and
 people and the cost of ongoing maintenance that new code requires.  As such, we
 have a general :doc:`support policy<SupportPolicy>` for introducing major new
 components into the LLVM world, depending on the degree of detail and
 responsibility required. *Core* projects need a higher degree of scrutiny
 than *peripheral* projects, and the latter may have additional differences.
 
 However, this is really only intended to cover common cases
 that we have seen arise: different situations are different, and we are open
 to discussing unusual cases as well - just start an RFC thread on the
 `llvm-dev mailing list`_.

 * Test failures, bugs, and build breakages that only appear when the
   experimental target is enabled, caused by changes unrelated to the target, are
   the responsibility of the community behind the target to fix.
 
 The basic rules for a back-end to be upstreamed in **experimental** mode are:
 
 * Every target must have a :ref:`code owner<code owners>`. The `CODE_OWNERS.TXT`
   file has to be updated as part of the first merge. The code owner makes sure
   that changes to the target get reviewed and steers the overall effort.
 
 * There must be an active community behind the target. This community
   will help maintain the target by providing buildbots, fixing
   bugs, answering the LLVM community's questions and making sure the new
   target doesn't break any of the other targets, or generic code. This
   behavior is expected to continue throughout the lifetime of the
   target's code.
 
 * The code must be free of contentious issues, for example, large