Clarify lots of existing practice. Expand on the "major change" section,
which is the closest thing we have on how to run an RFC.
---------
Co-authored-by: Oleksandr "Alex" Zinenko <azinenko@amd.com>
Co-authored-by: Aaron Ballman <aaron@aaronballman.com>
There should be no substantial policy change here.
I reordered the breaking change docs after the major change docs, since
that flow made sense to me. I smoothed out some of the incremental
development policy wording to be a bit less black and white, and talk
about "preferred" and "discouraged" approaches.
This makes it more clear what you the author must do, and what reviewers
can expect you to do, before an approved PR can be merged. Spliting out
the email bit into a section also means we can link directly to it in
discussions.
This relies on one of those parties actually reading this, but I plan to
tackle the case where they don't with some new automation.
This updates the developer policy to align with established community
norms for copyright notices in source code contributed to LLVM.
The updates clearly state that we do not accept code contianing explicit
copyright notices in source except where such code is a pre-existing
part of an external dependency that is being vendored into LLVM.
Explicit copyright notices in source add no value to the project since
copyright ownership is well tracked through git. Our policy already
requires that contributions made not by the original author have
appropriate attribution in git commit messsages or metadata.
Further, explicit copyright notices in code can easily get out of date
as the code is refactored, updated by additional authors or otherwise
changed over time. This leads to misleading out-of-date copyright
notices which do more harm than good.
This change should be viewed as a clarification and statement of
existing established policy, not a change in policy since it represents
the way the project has been operating.
This updates the auto-labeler to match a specific issue title that is
going to be used for requesting commit access and then add the
infrastructure:commit-access-request label.
This will notify the admin team who will be able to handle the request.
See
https://discourse.llvm.org/t/rfc-change-the-process-for-requesting-commit-access/80184
---------
Co-authored-by: Vlad Serebrennikov <serebrennikov.vladislav@gmail.com>
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
