See
https://discourse.llvm.org/t/hidden-emails-on-github-should-we-do-something-about-it/74223
for details about why this is important to the community.
Note, we currently have soft enforcement for this requirement in the
form of a bot which posts comments letting patch authors know their
email is private, so we're already setting expectations in practice;
this PR is documenting those expectations for clarity.
This replaces the previous Code Owners section of our developer policy
with a new section for Maintainers. It also updates most of the places
we mention "code owner" in the documentation (it does not update the
files named `Code Owners.rst` or similar because those should be updated
when the subprojects add their `Maintainers.rst` file).
The wording was taken from what was proposed in the RFC (including all
suggested amendments from folks on the thread).
Please see the RFC for more details:
https://discourse.llvm.org/t/rfc-proposing-changes-to-the-community-code-ownership-policy/80714/
Governments around the world are starting to require labelling for
AI-generated content, and some LLVM stakeholders have asked if LLVM
contains AI-generated content. Defining a policy on the use of AI tools
allows us to answer that question affirmatively, one way of the other.
The policy proposed here allows the use of AI tools in LLVM
contributions, flowing from the idea that any contribution is fine
regardless of how it is made, as long as the contributor has the right
to license it under the project license.
I gathered input from the community in this RFC and incorporated it into the policy:
https://discourse.llvm.org/t/rfc-define-policy-on-ai-tool-usage-in-contributions/78758
We have been discussing changes to our commit access polices recently
and based on some feedback from clattner here:
https://discourse.llvm.org/t/rfc-new-criteria-for-commit-access/76290/81
We need to update our Developer Policy so that it matches what we are
actually doing in this project. We currently grant commit access to
anyone with a valid justification, not just contributors who have
submitted high-quality patches in the past.
---------
Co-authored-by: Shilei Tian <i@tianshilei.me>
The very beginning already talks about how to git clone the repo. The
section about checking out specific versions doesn't really belong in
GettingStarted and seems unnecessary.
I've not tried to change the purpose or style of the doc, just edited
for clarity and removed any Phabricator related language in favour of
GitHub terms.
Where possible, I've swapped direct links to LLVM's website with RST
links to the local documents. Which should be a bit more resilient.
Also it's less confusing if you're editing multiple pages locally, you
don't accidentally end up on the live site.
This adds first version of a GitHub workflow in the documentation and marks some
sections as deprecated. We should clean up these sections ASAP. I was
just keen to get something on the documentation site as soon as
possible.
This addresses further post-review feedback
(https://reviews.llvm.org/D155081) with commit
677326999f270395ecaec026178fe7ed148a0068 by rearranging some of the
text into separate bullets and adding a clarifying statement.
677326999f270395ecaec026178fe7ed148a0068 changed the developer policy
but dropped a documentation link telling folks to add a link to the
Phabricator page where review occurred. This restores that link and
wording, thanks to post-review feedback for catching the regression.
This specifies the developer policy on adding links in source & test
files and commit messages, related to discussion at:
https://discourse.llvm.org/t/code-review-reminder-about-links-in-code-commit-messages/71847
The intent is to discourage adding links to resources that are not
available to the community as a whole (dead links, links to internal
documentation, links to internal bug trackers, etc) from source and
test files, while still allowing such links to appear in other contexts
as needed. It suggests to instead add sufficient context in the
surrounding comments to make such links unnecessary.
It also clarifies that these links can appear in commit messages as
metadata (similar to how we already have Differential Revision and
Fixes metadata with links).
Differential Revision: https://reviews.llvm.org/D155081
We've recently had issues appropriately notifying users and
stakeholders of changes to projects that may be potentially disruptive
when upgrading. This led to discussion on Discourse about how to
improve the situation, which can be found at:
https://discourse.llvm.org/t/rfc-add-new-discourse-channel-for-potentially-breaking-disruptive-changes-for-clang/65251
Ultimately, it sounds like we want to encourage three things:
* Alert vendors during the code review so they can provide early
feedback on potentially breaking changes that would be unacceptable
for them.
* Alert vendors and users after committing the changes so they can
perform pre-release testing on a completed change to determine if it
causes unreasonable problems for them.
* Alert users more clearly through the release notes so that it's
easier to determine how disruptive an upgrade might be.
This updates the developer policy accordingly.
Differential Revision: https://reviews.llvm.org/D134878
We are already using the Co-author-by git tag, but don't have documentation in
our developer policy about it. Fix that.
Differential Revision: https://reviews.llvm.org/D134740
Specifically:
- Diffs are not passed around on mailing lists any more.
- Diffs should be `-U999999`.
- Clarify part about automated emails.
Differential review: https://reviews.llvm.org/D128645
In some case, GitHub will not send notification for commit access invitation. Add invitation link for people don't get notification from GitHub.
Reviewed By: lattner
Differential Revision: https://reviews.llvm.org/D124191
Plenty of new targets nowadays and I found myself repeating the same
thing over and over, so this is more or less what we said over the last
few years, but condensed in an ordered fashion and easy to digest.
This does not change any of the recommendations, only documents what we
have been saying for years.
This has come up a few times recently, and I was surprised to notice that we don't have anything in the docs.
This patch deliberately sticks to stuff that is uncontroversial in the community. Everything herein is thought to be widely agreed to by a large majority of the community. A few things were noted and removed in review which failed this standard, if you spot anything else, please point it out.
Differential Revision: https://reviews.llvm.org/D99305
Before, the first mention of LLVM's license on the developer policy page stated
that LLVM's license is Apache 2. This patch makes that more accurate by
mentioning the LLVM exception this first time the LLVM license is discussed on
that page, i.e. Apache-2.0 with LLVM-exception.
Technically, the correct SPDX identifier for LLVM's license is 'Apache-2.0 WITH
LLVM-exception', but I thought that writing the 'WITH' in lower case made the
paragraph easier to read without reducing clarity.
Differential Revision: https://reviews.llvm.org/D96482
Adding new paragraphs under "Introducing New Components" section to
check the different levels of support we have, to help introduction of
smaller set of changes without overwhelming new collaborators and
potentially losing the contribution.
Differential Revision: D91013
Summary:
Fixes two minor issues in the docs present under `ninja docs-llvm-html`:
1 - A header is too small:
```
Warning, treated as error:
llvm/llvm/docs/Passes.rst:70:Title underline too short.
``-basic-aa``: Basic Alias Analysis (stateless AA impl)
------------------------------------------------------
```
2 - Multiple definitions on a non-anonymous target (llvm-dev mailing list):
```
Warning, treated as error:
llvm/llvm/docs/DeveloperPolicy.rst:3:Duplicate explicit target name: "llvm-dev mailing list".
```
Reviewers: lattner
Reviewed By: lattner
Subscribers: llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D83416
Uploading output from `git format-patch` fails when version has
more than 2 dots, e.g. git version 2.24.1.windows.2 which is
currently recommended by e.g. GitExtensions or 2.24.1.rc on Linux.
Differential Revision: https://reviews.llvm.org/D72374
This is an update to the documentation of our community code-review process.
Based on the RFC: High-Level Code-Review Documentation Update
(http://lists.llvm.org/pipermail/llvm-dev/2019-November/136808.html).
In this patch, I've pulled out the documentation into a separate file, and
broken it into a number of subsections. This is, of course, just one further
step in better documenting our community processes. I expect we'll continue to
improve this over time. Thank you to everyone who provided feedback!
Differential Revision: https://reviews.llvm.org/D71916
Experimental targets are meant to be maintained by the community behind
the target. They are not monitored by the primary build bots. This
change clarifies that it is this communities responsibility for things
like test fixes related to the target caused by changes unrelated to
that target.
See http://lists.llvm.org/pipermail/llvm-dev/2020-February/139115.html
for a full discussion.
Reviewed by: rupprecht, lattner, MaskRay
Differential Revision: https://reviews.llvm.org/D74538
Summary:
The older method of adding 'Patch by John Doe' is documented in the
`Attribution of Changes` section to support correct attribution of commits
that pre-date the adoption of git.
Reviewers: hfinkel, aaron.ballman, mehdi_amini
Subscribers: llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D72468
