Update references to the mailing list to reference Discourse. Also update references to LLVM Bugzilla as we have moved to GitHub issues.

Reviewed By: lattner

Differential Revision: https://reviews.llvm.org/D120833
This commit is contained in:
Tanya Lattner 2022-03-04 14:27:07 -08:00
parent 210bdc651b
commit ca8432f1ee
1 changed files with 20 additions and 26 deletions

View File

@ -46,12 +46,8 @@ quality.
Stay Informed
-------------
Developers should stay informed by reading at least the "dev" mailing list for
the projects you are interested in, such as `llvm-dev
<http://lists.llvm.org/mailman/listinfo/llvm-dev>`_ for LLVM, `cfe-dev
<http://lists.llvm.org/mailman/listinfo/cfe-dev>`_ for Clang, or `lldb-dev
<http://lists.llvm.org/mailman/listinfo/lldb-dev>`_ for LLDB. If you are
doing anything more than just casual work on LLVM, it is suggested that you also
Developers should stay informed by reading the `LLVM Discourse forums`_.
If you are doing anything more than just casual work on LLVM, it is suggested that you also
subscribe to the "commits" mailing list for the subproject you're interested in,
such as `llvm-commits
<http://lists.llvm.org/mailman/listinfo/llvm-commits>`_, `cfe-commits
@ -61,14 +57,13 @@ such as `llvm-commits
way to see what other people are interested in and watching the flow of the
project as a whole.
We recommend that active developers register an email account with `LLVM
Bugzilla <https://bugs.llvm.org/>`_ and preferably subscribe to the `llvm-bugs
We recommend that active developers monitor incoming issues to our `GitHub issue tracker <https://github.com/llvm/llvm-project/issues>`_ and preferably subscribe to the `llvm-bugs
<http://lists.llvm.org/mailman/listinfo/llvm-bugs>`_ email list to keep track
of bugs and enhancements occurring in LLVM. We really appreciate people who are
proactive at catching incoming bugs in their components and dealing with them
promptly.
Please be aware that all public LLVM mailing lists are public and archived, and
Please be aware that all public LLVM mailing lists and discourse forums are public and archived, and
that notices of confidentiality or non-disclosure cannot be respected.
.. _patch:
@ -219,7 +214,7 @@ the future that the change is responsible for. For example:
* The changes should not cause performance or correctness regressions in code
compiled by LLVM on all applicable targets.
* You are expected to address any `Bugzilla bugs <https://bugs.llvm.org/>`_ that
* You are expected to address any `GitHub Issues <https://github.com/llvm/llvm-project/issues>`_ that
result from your change.
We prefer for this to be handled before submission but understand that it isn't
@ -281,7 +276,7 @@ Below are some guidelines about the format of the message itself:
code snippets and gory details should be left to bug comments, web
review or the mailing list.
* If the patch fixes a bug in bugzilla, please include the PR# in the message.
* If the patch fixes a bug in GitHub Issues, please include the PR# in the message.
* Text formatting and spelling should follow the same rules as documentation
and in-code comments, ex. capitalization, full stop, etc.
@ -435,8 +430,7 @@ Making a Major Change
---------------------
When a developer begins a major new project with the aim of contributing it back
to LLVM, they should inform the community with an email to the `llvm-dev
<http://lists.llvm.org/mailman/listinfo/llvm-dev>`_ email list, to the extent
to LLVM, they should inform the community with a post to the `LLVM Discourse forums`_, to the extent
possible. The reason for this is to:
#. keep the community informed about future changes to LLVM,
@ -593,7 +587,7 @@ C API Changes
* Including new things into the API: If an LLVM subcomponent has a C API already
included, then expanding that C API is acceptable. Adding C API for
subcomponents that don't currently have one needs to be discussed on the
mailing list for design and maintainability feedback prior to implementation.
`LLVM Discourse forums`_ for design and maintainability feedback prior to implementation.
* Documentation: Any changes to the C API are required to be documented in the
release notes so that it's clear to external users who do not follow the
@ -613,7 +607,7 @@ will only be done through the following process:
at a minimum. This time-based guideline is not strict: we may support much
older compilers, or decide to support fewer versions.
* An RFC is sent to the `llvm-dev mailing list`_
* An RFC is sent to the `LLVM Discourse forums`_
- Detail upsides of the version increase (e.g. which newer C++ language or
library features LLVM should use; avoid miscompiles in particular compiler
@ -625,7 +619,7 @@ will only be done through the following process:
softer transition path for developers compiling LLVM, because the
error can be turned into a warning using a CMake flag. This is an important
step: LLVM still doesn't have code which requires the new toolchains, but it
soon will. If you compile LLVM but don't read the mailing list, we should
soon will. If you compile LLVM but don't read the forums, we should
tell you!
* Ensure that at least one LLVM release has had this soft-error. Not all
@ -640,7 +634,7 @@ will only be done through the following process:
* 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
<https://discourse.llvm.org/t/rfc-migrating-past-c-11/50943>`_ and the
`corresponding change <https://reviews.llvm.org/D57264>`_.
.. _ci-usage:
@ -707,7 +701,7 @@ 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`_.
`LLVM Discourse forums`_.
Adding a New Target
-------------------
@ -802,7 +796,7 @@ Those wishing to add a new target to LLVM must follow the procedure below:
1. Read this section and make sure your target follows all requirements. For
minor issues, your community will be responsible for making all necessary
adjustments soon after the initial merge.
2. Send a request for comment (RFC) to the llvm-dev@ mailing list, describing
2. Send a request for comment (RFC) to the `LLVM Discourse forums`_ describing
your target and how it follows all the requirements and what work has been
done and will need to be done to accommodate the official target requirements.
Make sure to expose any and all controversial issues, changes needed in the
@ -825,7 +819,7 @@ Those wishing to add a new target to LLVM must follow the procedure below:
sure the progress is still consistent.
7. Once all official requirements have been fulfilled (as above), the code owner
should request the target to be enabled by default by sending another RFC to
the llvm-dev@ mailing list.
the `LLVM Discourse forums`_.
Adding an Established Project To the LLVM Monorepo
--------------------------------------------------
@ -860,7 +854,7 @@ components to a high bar similar to "official targets", they:
"should" concerns above.
If you have a project that you think would make sense to add to the LLVM
monorepo, please start an RFC thread on the `llvm-dev mailing list`_ to kick off
monorepo, please start an RFC topic on the `LLVM Discourse forums`_ to kick off
the discussion. This process can take some time and iteration - please dont
be discouraged or intimidated by that!
@ -919,10 +913,10 @@ When approved, the llvm-admin group can grant the new project:
Graduation to the mono-repo would follow existing processes and standards for
becoming a first-class part of the monorepo. Similarly, an incubating project
may be eventually retired, but no process has been established for that yet. If
and when this comes up, please start an RFC discussion on llvm-dev.
and when this comes up, please start an RFC discussion on the `LLVM Discourse forums`_.
This process is very new - please expect the details to change, it is always
safe to ask on the `llvm-dev mailing list`_ about this.
safe to ask on the `LLVM Discourse forums`_ about this.
Suggested disclaimer for the project README and the main project web page:
@ -957,8 +951,8 @@ process to take at least 4-6 weeks. If you would like to contribute code
under a different license, please create a Phabricator review with the code
you want to contribute and email board@llvm.org requesting a review.
If you have questions or comments about these topics, please contact the
`LLVM Developer's Mailing List <mailto:llvm-dev@lists.llvm.org>`_. However,
If you have questions or comments about these topics, please ask on the
`LLVM Discourse forums`_. However,
please realize that most compiler developers are not lawyers, and therefore you
will not be getting official legal advice.
@ -1202,4 +1196,4 @@ to move code from (e.g.) libc++ to the LLVM core without concern, but that code
cannot be moved from the LLVM core to libc++ without the copyright owner's
permission.
.. _llvm-dev mailing list: http://lists.llvm.org/mailman/listinfo/llvm-dev
.. _LLVM Discourse forums: https://discourse.llvm.org